Вышел новый релиз функционального языка программирования Objective Caml 3.04

> OCaml линкует к той-же самой libc

А может он все-таки кое-чего делает в обход libc, подменяя своими функциями?
Иначе как объяснить? Желательно бы еще провести более длительный тест.
0.1 - 0.2 секунды исполнения слишком мало, чтобы исключить погрешности.

Сколько уже было хороших языков.... Одна Modula-2 (для своего времени - до ООП) чего стоит. А следующее творение Вирта - oberon, думаю, еще лучше оказался. Но это oberon я даже смотреть не стал (чтобы не расстраиваться). Все равно распространения не получил. А пишем на гораздо худших (IMHO, конечно) языках C/C++. Потому, что дорога ложка к обеду. Занята была ниша. Боюсь, что и с caml то же самое произойдет.

2all А знает ли кто - есть ли для C/C++ сайт подобный CPAN для перла? Т.е. просто нужны всякие уже готовые библиотеки для работы с сетью, почтой, конфигурационными файлами и т.д.

Олег.

Ты упился, или где? Отличие от императивщины ФУНДАМЕНТАЛЬНОЕ: нет вектора состояний, нет атомарных операций над ним, а есть лишь ФУНКЦИИ, в строго математическом смысле. И плюшки от этого просто немерянные: возможность автоматического преобразования кода, вывода свойств из реализации (что есть основная часть задачи доказательства кода), возможность распараллеливания (в силу неспецифицированности порядка вычисления аргументов и отсутствия сайд-эффектов), ну и на закуску high-order functions, что практически во всех случаях многократно упрощает реализацию алгоритмов. То, для чего во всяких Лиспах используется конструирование cons-ами вычислимых списков, а в C++ - гробообразные темплейты плодятся, в языках вроде ML делается совершенно естественным образом. Ты функцию типа a -> b -> c -> d ... можешь разрезать в любом месте.

А скорость, эффективность, гибкость, расширяемость - это особенности конкретной реализации. Есть всё тот же ML, ничем подобным не обладающий (e.g. SML/NJ, MLton, MLkit), при чём все из них имеют другие, не менее интересные (в том числе и для чистой практики аспекты).

Кстати, ты упустил ещё одну особенность: когда появилась Альфа, Caml был в числе первых на неё портирован. Когда были опубликованы спеки IA64, Ксавье Лерой меньше чем за неделю написал и для него нейтивный кодогенератор. Вот это - действительно впечатляет, куда больше, чем эффективная раздача памяти (выделение тупла - несколько инструкций без всяких там call-ов) и конкурентный GC.

Ну и про некоторые крайне интересные особенности функциональных языков, не реализуемые в императивной парадигме, советую взглянуть на такую фишку, как Adate - генетическая генерация алгоритмов по заданной спецификации. Так же советую озаботиться мыслью, почему все CAS в потрохах у себя имеют именно функциональные языки.

Олегу: Ну как же - у Страуструпа можно посмотреть: http://www.research.att.com/~bs/C++.html

И еще разумеется www.linuxlinks.com - там дальше легко найти...

А я тут уже говорил, что именно в Caml Light реализован самый лучший из известных алгоритмов сборки мусора.

Читать сюда: http://pauillac.inria.fr/~xleroy/publi/concurrent-gc.ps.gz

Так же, по поводу реализации Caml в частности, и компиляторов вообще, читать здесь: http://pauillac.inria.fr/~xleroy/publi/ZINC.ps.gz

Ну и ещё, одна важная особенность Caml, которую тут все упустили: система типов Хиндли-Милнера. Читать тут:

Milner, R. (1978). A theory of type polymorphism in programming. Journal of Computer and Systems Sciences, 17, 348-375.

Так же много ценного можно вычитать здесь: http://www.ssh.tepkom.ru/msk/Types.html

В общем, просвещайтесь, товарищи. Учите математику. Тогда, может, поймёте, насколько фундаментальна разница между подходами Черча и Тьюринга.

Объясняется всё предельно просто: OCaml разворачивает в цикл хвостовые рекурсии, более того, даже просто вызов функции у него несколько дешевле, чем в Си. Ну а операции с целыми числами и не могут быть медленнее, чем в Си, поскольку они по большей части при компиляции unbox-ятся.

Ещё одна забавная особенность компилятора: он умеет инлайны делать даже между раздельно скомпилёнными модулями, но в данном случае это рояли не играло.

> OCaml линкует к той-же самой libc

>А может он все-таки кое-чего делает в обход libc, подменяя своими >функциями?
>Иначе как объяснить? Желательно бы еще провести более длительный >тест.
>0.1 - 0.2 секунды исполнения слишком мало, чтобы исключить >погрешности.

Тест был на вычисление чисел Фиббоначи = две функци без использования libc, syscalls, you name it, в теле бенчмаркируемой программы, так что нет твое первое утверждение не верно.

Сходи на страницу shootout-a и посмотри другие тесты.

>Желательно бы еще провести более длительный тест.
>0.1 - 0.2 секунды исполнения слишком мало,
>чтобы исключить погрешности.

kamil$ time ./fib_c 40 && time ./fib_ml 40
165580141

real 0m30.548s
user 0m30.500s
sys 0m0.040s
165580141

real 0m16.879s
user 0m16.880s
sys 0m0.000s

А ещё одни вопрос:

Кто-нибудь сравнивал компиляцию в натив код и в байт код?

Что лучше/хуже/быстрее ?

Где-то я читал, что компилятор в натив код в Ocaml
иногда косит ...

>Кто-нибудь сравнивал компиляцию в натив код и в байт код?


kamil$ time ./fib_c 35 && time ./fib_mlb 35
14930352

real 0m2.759s
user 0m2.750s
sys 0m0.010s
14930352

real 0m20.715s
user 0m20.690s
sys 0m0.010s

>Кто-нибудь сравнивал компиляцию в натив код и в байт код?
>Что лучше/хуже/быстрее ?

В мане написано что байт-код может работать
раз в десять медленнее. Я так понимаю в десять
раз, это в некотором гипотетическом наихудшем случае.
По по моим тестам, выходит не больше двух-четырех раз.

ну вот как всегда, столь замечательныю вещь похоронили за вратами университетов и угробили на военные разработки. А Linux пишут на каком-то галимом C....

Смотря для чего. Числодробильные задачи - ажно до 20 раз промеж нейтив и байткодом на Альфе разница. На x86 чуть меньше.

Ну а нейтив косячит, когда все рантайм проверки поотрубать. Тогда заместо ексёпшына будет segfault, чего и следовало ожидать.

А никто не пробовал ихний .src.rpm на красном головном уборе 7.2 с 2.4.16 ядром перебирать ? У меня `rpm --rebuild' в одном и том же месте падает: ... make EXTRAFLAGS=-nolabels RUNTIME=../boot/ocamlrun COMPILER=../ocamlc arrayLabels.cmo listLabels.cmo stringLabels.cmo moreLabels.cmo make[2]: Вход в каталог `/usr/src/redhat/BUILD/ocaml-3.04/stdlib' ../boot/ocamlrun ../ocamlc -g -nolabels -c arrayLabels.mli ../boot/ocamlrun ../ocamlc -g -nolabels -c arrayLabels.ml ../boot/ocamlrun ../ocamlc -g -nolabels -c listLabels.mli make[2]: *** [listLabels.cmi] Segmentation fault make[2]: *** Deleting file `listLabels.cmi' make[2]: Выход из каталог `/usr/src/redhat/BUILD/ocaml-3.04/stdlib' make[1]: *** [labelled.cmo] Ошибка 2 make[1]: Выход из каталог `/usr/src/redhat/BUILD/ocaml-3.04/stdlib' make: *** [library] Ошибка 2 ошибка: Неверный код возврата из /var/tmp/rpm-tmp.7216 (%build)

Захожу туда, говорю make руками - все ок. Несколько раз пробовал. М.б. это железные глюки какие ?

>Ну а нейтив косячит, когда все рантайм проверки поотрубать. Тогда >заместо ексёпшына будет segfault, чего и следовало ожидать.

Перевожу с Антихристово на русский.

По умолчанию компиляция идет с режимом Safe, это значит что во
время выполнения программы будут осуществлятся всякие проверки( к примеру чтобы ты ненароком не попытался выйти за границы массива),
в случае если ты всетаки чего напортачишь в программе( в нашем
примере попытаешься выйти за границы масива), то при
выполнении ты получишь исключение, которое в лучшем случае сам и
обработаешь, а в худшем программа завершится с
сообщением о исключенн. Если же программа откомпилированна в режиме
-unsafe, то никакие проверки во время выполнения выполнятся не будут,
это приведет с одной стороны к незначительному росту производительнолсти твоей программы, а с другой что любая нештатная
ситуация, возникшая по _твоей вине_ сможет завалить
программу в core.

>Ты упился, или где? Отличие от императивщины ФУНДАМЕНТАЛЬНОЕ: нет >вектора состояний, нет атомарных операций над ним, а есть лишь >ФУНКЦИИ, в строго математическом смысле.

Скажем так, в Caml все немного подругому, в том плане что
в язык включены императивные возможности, изменяемые переменные,
присваивание, последовательность инструкций, циклы наконец.

>И плюшки от этого просто немерянные: возможность автоматического >преобразования кода, вывода свойств из реализации (что есть основная >часть задачи доказательства кода),
Если можно то здесь поподробней, насколько я знаю доказательсто
кода вещь довольно не тривиальная, и для доказательство кода
в 5 строк, может превратится в весьма грустную задачу.

>возможность распараллеливания (в силу неспецифицированности порядка >вычисления аргументов и отсутствия сайд-эффектов),
Опять для Caml порядок вычислений определен.

Хм... RPM-ы собирать никогда не пробовал. Вообще, советую ставить не отдельно ocaml, а CDK (ссылка есть в Hump) - там куча полезных библиотек сразу прикручена. Только вот CDK пока что с ocaml3.02 идёт, до 3.04 не обновили...

Ну, тут мы от темы немного отклонились - Caml действительно не чисто функциональный язык, но меня то спрашивали, чем же так сильно ФУНКЦИОНАЛЬНОЕ программирование от императивного отличается. На примере Caml это сразу можно и не увидеть, благодаря наличию переменных, циклов и исключений. Кстати, порядок вычислений хоть и определён, но не специфицирован и может меняться.

Дык вот, про доказательство: если есть представленная на некоем формальном языке спецификация (e.g. набор предикатов, описывающих требуемые свойства алгоритма), и есть реализация, то можно вывести все свойства из реализации автоматически (смешно, но для таких вот задач ML и создавался). Естественно, это можно и рукаим проделать, но тогда действительно развлекуха обеспечена по полной программе.

to Antichrist:
>Ну, тут мы от темы немного отклонились - Caml действительно не чисто

Как отклонились? А в subj что написано?

>Дык вот, про доказательство: если есть представленная на _некоем_ >формальном языке спецификация (e.g. набор предикатов, описывающих

_некий_ это какой? И есть более или не мение рабочее
решение для доказательства кода?
Проблема, по моему, еще и в том что зачастую записать требуемые свойства алгоритма на _формальном языке_ написать
сложенее чем сам алгоритм! Да и кто потом будет доказывать
правильность спецификации?

>требуемые свойства алгоритма), и есть реализация, то можно вывести
>все свойства из реализации автоматически (смешно, но для таких вот
>задач ML и создавался).
Там по моему про теоремы шла речь.

PS: Вообще у тебя есть нехорошее свойство народ пужать матами и
всякими про-научными терминами. И настроить народ негативным
образом.

Насчет CDK - мне не понравилось, объем большой,
много всего навалено, версии не всегда свежие.
Лучше из исходников сам Caml собирать, а потом какие пакеты
нужны, загружаем и ставим. Рекомендую приятную утилиту
ocmalfind - называется, для более удобной работы
с caml библиотеками. Искать на Hump.

>никто не пробовал ихний .src.rpm на красном головном уборе 7.2
>с 2.4.16 ядром перебирать ? У меня `rpm --rebuild' в одном
>и том же месте падает: ...

из списка рассылки:
...We've observed similar hard-to-reproduce segmentation faults on a
Linux RedHat 7.2 machine. After some tracking, it turns out to be a
bug in gcc version 2.96 20000731 -- the "unofficial" gcc that RH 7.2
uses; I don't know which version of gcc your Mandrake has...

Это я отклонился, заговорив про теретицьские основы ФП. Ну, меня типа вынудили. ;)

Про язык формулировки спеков: на это, к примеру, даже Пролог канает, если порезать. Всё, на чём можно красиво уписывать предикаты первого порядка. И, обычно, набор важных свойств получается весьма коротким - при чём, их формулировка обычно делается ДО собственно реализации. Так что тут я проблем не вижу. Однако же, сам я автоматическими тулзами для доказательства теорем не пользовался, и всегда всё делал руками - мне в основном численные методы доказывать надо, а это весьма просто. И, кстати, доказательство соответствия реализации спекам - и есть доказательство теоремы.

Ну и про P.S.: матюки у меня вполне справедливые, ибо направленны в адрес C++. ;)

Понятно, что религиозных фанатиков, которые на C++ молятся, это ну очень сильно задевает.

> Ещё одна забавная особенность компилятора: он умеет инлайны

Ага, значит все-таки фокусы известные...
to ska: А что если твою си-программу пересобрать с -О6 и снова прогнать тест?

Сорри за оффтопик - народ, кто-нить имеет рабочие обфускаторы для перла (или компиляторы в байт код)? А то без них гнило софт деплоить..

>А что если твою си-программу пересобрать с -О6 и снова прогнать тест?

kamil$ gcc -O6 -o fib_c -march=k6 -mcpu=k6 -fomit-frame-pointer fib.c
kamil$ ocamlopt -o fib_ml fib.ml
kamil$ time ./fib_c 40 && time ./fib_ml 40
165580141

real 0m27.096s
user 0m27.090s
sys 0m0.000s
165580141

real 0m17.166s
user 0m17.150s
sys 0m0.020s

По барабану... ;)

Я смотрю в си-программе sys time всегда 0, а у ocaml всегда отлично от нуля.
Что он там делает?
Предположение: компилятор ocaml умудряется создать код, перекладывающий часть работы на ядро.
Может здесь лежит ключик к секрету?

>Я смотрю в си-программе sys time всегда 0, а у
>ocaml всегда отлично от нуля. Что он там делает?

посмотри сообщение выше -> anonymous (*) (2001-12-20 03:15:27.0)

Я тут из любопытства собрал ocaml-3.04... и похоже, что те тесты из Language Shootout нужно переписывать...
ocaml оказался абсолютным победителем во всех тестах, из тех что я успел попробовать.
Причем даже на таком дерьме, как конкатенация строк! Да еще с таким отрывом...
Заметил одну тонкость: libm, которая прилинковывается автоматом ко всем бинарникам ocaml.
Да и еще размер бинарника ocaml ровно 20 раз больше сишного, однако. Следовательно, embedded
девайсы пока отдыхают. Для них это чудо теряет свои плюсы.

Еще одна возможная причина феномена скорости ocaml - неоптимально написанный код на С/С++.
Я например сильно удивился очень низким результатам php в тесте nestedloop.
Посмотрел его, переписал, и он вдруг волшебным образом стал в два раза быстрее.
Так что надо разбираться. Пока ничего не понятно ;(

Ну конечно, взгляните на код strcat.gcc. Сколько там realloc...
Переписал по-своему. Опять получил в два раза выше скорость... Короче фикция эти тесты.
Качество написания кода для различных языков слишком неравнозначное.
Кстати по ходу выловил баг толи в коде, толи в самом ocaml'e:

./strcat_ml 4000000
Fatal error: exception Invalid_argument("String.create")

Ни одна другая прога (gcc,perl,php) ошибок не выдает с таким параметром.
Что бы это значило? Buffer overflow скорее всего. Чего-то перестал он мне нравиться ;(

Объясните популярно, зачем нужен ocaml если есть Lisp,
Scheme ( и его воплощение - siod) ?

SJB

RTFM about Hindley-Milner type system and typed lambda calculus. See URL's below.

Once again for dummies: RTFM about proper tail recursion handling and Caml call conventions. Ядро тут абсолютно не при делах.

RTFM про String и Bigarray. Это плата за сверхбыстрый GC.

2Antichrist: Что такое "канает"?

Не флейма ради, а токмо волею пославшей мя тяги к знаниям:

1) Есть ли в языках семейства *ML аналоги лисповского (eval ...) и (compile ...)? Другими словами, можно ли там генерировать код "на лету"?

2) Поддерживает ли ОО-подсистема ocaml интроспекцию и рефлексию?

--

SVK

> RTFM про String и Bigarray. Это плата за сверхбыстрый GC.

Да ты гонишь. Обещал суперпупер вещь, где не надло думать про выделение памяти,
оптимизацию и т.д. И где оно? Почему прога заткнулась, в то время как на других языках все ОК?

И про крутую оптимизацию в ocaml'e прогон. Я могу сказать, что _реально_
делается в тестовой проге strcat.ml. Ничего он динамически не выделяет миллион раз.
Он видит конструкцию "N раз добавить строку S в буффер B" и создает этот буффер сразу - то есть один раз.
Аналог на perl выглядит так:
$str = "hello\n" x $N;

На php так:
$str = str_repeat("hello\n", $N);

И такая конструкция работает практически с той же скоростью, что ocaml.
А в gcc то же самое вдвое быстрее. На лицо обман от устроителей соревнования...
Заявленный алгоритм исполнения не гарантирован, хотя с виду кажется, что он должен
выполняться везде. Вот вам и разгадка "секрета". Боюсь, что с остальными прогами
такая же история.

Я потрудился уравнять тестовые программы для других языков и вот что получилось:

$ time php -f ./strcat.php 1000000
6000000

real 0m0.072s
user 0m0.070s
sys 0m0.000s

--------------------------------
$ time perl ./strcat.perl 1000000
6000000

real 0m0.075s
user 0m0.060s
sys 0m0.010s

--------------------------------

$ time python ./strcat.python 1000000
6000000

real 0m0.166s
user 0m0.160s
sys 0m0.010s

-------------------------------
$ time ./strcat_ml 1000000
6000000

real 0m0.141s
user 0m0.120s
sys 0m0.020s

--------------------------------

Почувствуйте разницу, господа анчихристы. Я чуть было не попался на эту лажу
со скоростью исполнения. Блин, Коперфильды хреновы!

факир не верил в бога и....фокус не удался

В этом случае потрудись пожалуйста опубликовать свой код.

Вот, что хочется добавить по поводу strcat, кокатенация строк в perl,python,php реализована извне и имеет достаточно серьёзную поддержку со стороны компилятора/интерпретатора.

В strcat.ocaml все происходит на базе модуля Buffer реализованного НА OCaml. Т.к. что юольще подходит сравнение с C.

$str = "hello\n" x $NUM; не эквивалентен методу примененному в strcat.ocaml, т.к. вышеуказаное может(и должно) быть оптимизированно.(lazy implementation, prealloc and blit etc).

Тут надо отметить что в OCaml _выше указанную_ конструкцию со всеми вытекающими, и совершенно очевидными, компилятору оптимизациями, реализовать столь-же элегантно нельзя. Так что credit to perl,python,php.

Обвинять автора TGCLS в предвзятости я бы повременил, особенно учитывпя то, что его код и алгоритмы улучшают представители соответсвующих языковых групю. (Особенно это не прет по поводу Perl, достаточно взглянуть на его home title page).

To Antichrist:
По придержи лошадей, тебе с твоим элитизмом уже раз дали один раз по по голове на c.l.f, не стоит повторять, выглядишь как /. linux zealot.

Ещё пара коментариев:

a) Да действительно в OCaml максимальная длина string и 'a array
ограничена, увы GC диктует свои условия. Это значит, что некий класс проблем не имет решения на базе этих базовых типов, это не очень весело, но и вселенской трагедией не является. И сравнения с языками
которые реализуют reference counting не уместно(apples and oranges).

b) OCaml разрабатывается с(если память не изменяет) 1984 года, но некоторые из постеров тут, ведут себя так, как будто им показали супер-пупер новейшую разработку с немерянными претензиями и вдруг оказывается, что бенчмарки все сплошь и рядом подпорчены, и реализация на языке который постер знает реализована не эффективно и т.д. Глупо это как-то.

> Ага, значит все-таки фокусы известные...
Фокусы то известные, но реализовать их у кого получается,
а у кого не очень.
> Да и еще размер бинарника ocaml ровно 20 раз больше сишного, однако.
> Следовательно,
> девайсы пока отдыхают. Для них это чудо теряет свои плюсы.
Не совсем так. Во первых ты можешь вместо стандартного
окружения, собрать свое из которого все лишнее повыкидываешь
и размер получиться гораздо меньше, это где то мелькало в маил-листе.

Во вторых, байткод пока никто не отменял, посмотри его размер,
он должен, по идее, быть меньше даже Си-шного. Дальше зашиваешь
интерпретатор байткода скажем во флэшку, и чуствуешь себя счасливо!

> ./strcat_ml 4000000 -> ошибка
Размер _стандартной_ Caml-овской строки на 32 разрядной архитектуре ~16МБ,
По моему вполне достаточно для большинства задач, если понадобиться
побольше используй расширения, вон есть модуль BigArray - для масивов
произвольной длинны. Вроде и для сторк такое имеется, хотя я и не уверен
на все 100%. Если и нет то это очень просто реализуется.
>Он видит конструкцию "N раз добавить строку S в буффер B" и создает этот буффер сразу - то
> есть один раз.
Нифига подобного все отрабатывается по чесному, строка добавляестя
в буфер заданное количество раз. Смотри buffer.ml, str.c!
>Почему прога заткнулась, в то время как на других языках все
> ОК?
Потому что иногда полезно и документацию почитать, а не визжать.
И никто тебе ничего не обещал, мозгов нехватает сиди в Perl/PHP,
и радуйся.

>a) Да действительно в OCaml максимальная длина string и 'a array
> ограничена, увы GC диктует свои условия. Это значит, что некий класс проблем не имет
> решения на базе этих базовых типов, это не очень весело, но и вселенской трагедией не
> является.
Добавлю.
Если нужно чего нестандартное, чего нельзя сделать в чистом Caml, это
делается с помощью внешних Си библиотек. Кстати где то процентов 30
стандартной Caml-овской библиотеки написано на Си. Так что проблем нет.

> байткод пока никто не отменял, посмотри его размер,
> он должен, по идее, быть меньше даже Си-шного.

байткод ровно в шесть раз больше сишного, к тому же скорость его исполнения
падает ниже уровня распространенных интерпретаторов, таких как perl и php. Так что
все расписанные преимущества ocaml расстаяли на глазах...

> Размер _стандартной_ Caml-овской строки на 32 разрядной архитектуре ~16МБ,
А вот это меня _не_должно_ волновать. Анчихрист много раз обливал грязью писателей
на С/С++ и других "язычках" именно на предмет того, что в ocaml'e типа можно
просто писать, неозабочиваясь техническими проблемами выделения памяти, типизации,
оптимизации. Я бью его именно по тому месту, которое это сказало.

> Потому что иногда полезно и документацию почитать,

И что, там объясняется почему дерьмо пахнет? Мы это и так знаем ;)

Короче, миф развеян. "The Great Computer Language Shootout" - ПОЛНАЯ ЛАЖА и НАЕБА^H^HДУВАЛОВКА
и подлежит немедленному уничтожению.

Товарищу антихристу предлагается публично съесть свой член,
приготовленный по его же собственному рецепту ;)

> падает ниже уровня распространенных интерпретаторов, таких как perl и php. Так что
Вот этого не надо. Или конкретный пример давай. Кстати заметь что
байткод выполняется на любой полатформе. А как насчет сишного бинарника?
>все расписанные преимущества ocaml расстаяли на глазах...
Солнце ты немножко забыл про типы, GC, модули, функции первого
порядка, функторы и еще о многих приятных вещах.
>А вот это меня _не_должно_ волновать.
Может ты хочешь чтоб оно тебе и задницу вытирало. Извини
но чудес не бывает. Нужно _знать_ ЧТО и для ЧЕГО использовать.
Ты ведь, к примеру, на автобусе в америку не поедешь, а воспользуешься
для этого пароходом или, если смелый очень, то самолетом.
>просто писать, неозабочиваясь техническими проблемами выделения памяти, типизации,
Про выделение памяти ты правильно сказал, можно не заботится,
а вот про типизацию - нет. Тебе компайлер по голове так настучит
если ты не дай бог с типами чего нахомутаешь, мало не покажется. Зато
потом будешь чувствовать себя "сухо и комфортно", процентов на
70-80% сократишь этап отладки.
> Потому что иногда полезно и документацию почитать,
>> И что, там объясняется почему дерьмо пахнет? Мы это и так знаем ;)
Нет, просто возможно после прочтения ума прибавится, хотя сомневаюсь.
>и подлежит немедленному уничтожению.
Ага, вот этим и займись.

И еще.
Самое главное, это то что язык _ТАКОГО ВЫСОКОГО УРОВНЯ_
вплотную приблизился к _С_. И тут не столь важны возможные
погрешности в измерениях, общая картина видна.
Хочется надеятся что это именно качественный переход через
некоторый рубеж. Помните раньше был ассемблер, народ
задолбался писать на нем начали думу думать, языки всякие придумывать,
из всего множества только Си и удержался, потому что предлагал
на тот момент очень неплохую альтернативу ассемблеру.
Сейчас, другое время, другие требования, и нужно искать
замену уже старичку Си, мыслительный процес продолжается,
языки появляются как грибы после дождя, и кто знает, какой из
них станет на замену старому доброму Си.
И Caml является неплохим претендентом на приемника Си.
Чего будет время покажет.

PS: Насчет ./strcat_ml 4000000 - то это мне напомнило анекдот
про японскую циркулярку и наших лесорубов.

> Насчет ./strcat_ml 4000000 - то это мне напомнило анекдот

Ты расскажи этот анекдот программе xml-парсеру или ее пользователю, у которого
4 Гига памяти на борту. Боюсь, что не поймут ;(
Настоящий анекдот в том, что увидев сногсшибательные фантастические результаты
бенчмарков, я первым делом подумал, как здорово будет использовать это чудо для
написания xml-парсера! Надо ж так обломали ;(

> Размер _стандартной_ Caml-овской строки на 32 разрядной архитектуре ~16МБ,
За что боролись... И этот недоязычек позиционируют для управления космической техникой!
И как прикажешь программеру поступать? Изначально выбросить и забыть _стандартные_ Caml-овские
строки и пользовать _нестандартные_ или ждать и надеяться, что ракета не упадет
от переполнения буфера? Это МАРАЗМ, который я вижу впервые, которого нет ни в одном
другом языке. Это крутейший баг и просмотр в реализации. Это огромная дыра в безопасности.

И пусть тестеры-бенчмаркеры сначала перепишут strcat.ocaml на нормальной строковой библиотеке,
а потом показывают свои результаты, на которые и так смотреть нечего. Маленький, компактный,
универсальный php-интерпретатор в двое быстрее окамловского "нейтив" бинарника. Я представляю,
что там получится, если использовать равноценную с php или perl строковую библиотеку.

>И пусть тестеры-бенчмаркеры сначала перепишут strcat.ocaml на нормальной строковой библиотеке,
У них там есть скрипт strcat.ocaml2. Это наверное и есть нормальный . Только лучше его не пробовать
с параметром 1000000, если у вас не настроен лимит на память. У меня он вылетел
через пару минут. Это при лимите в 300мег!

> Нифига подобного все отрабатывается по чесному, строка добавляестя
> в буфер заданное количество раз. Смотри buffer.ml, str.c!

А ты посмотри кто стоит за Buffer.add_string. Потом расскажи что делает unsafe_blit.

>> падает ниже уровня распространенных интерпретаторов, таких как perl и
>> php. Так что
> Вот этого не надо. Или конкретный пример давай. Кстати заметь что
> байткод выполняется на любой полатформе. А как насчет сишного
> бинарника?
Ну и интересно, а мои (или любые другие) подключенные C библиотеки тоже будут работать в этом байткоде под любой платформе? А если учесть, что исходников либ нет??? Свежо предание, да верится с трудом.

А я то думал грешным делом посмотреть на него. Мне и на TCL/TK не плохо живется :-)

Пока строки не сделают как у людей останется этот окамл лишь игрушкой-развлекушкой
для господ математиков.