Цитата(Void @ 15.1.2006, 21:39 )

длина массивов в OCaml ограничена ~4M, а строк - 16M для 32-разрядных машин.

4Мб или 4.Е6 элементов? В принципе в 4Мб много ссылок и примитивов влезет, но это сильное ограничение...
У себя со строками хорошо провернул, не мутируемые, созданные из блоков и связанных списков "указателей" на части блоков. Это помогает не транжирить память при многих строковых операциях, например "test: " + 90 +"Mb" или "[pad]" * 3 (создать новую строку как сложив "[pad]" три раза), также подстроки и другое. Цена этому накладные расходы при чтении строк, например выбирать посимвольно charAt(индекс) будет жутко не эффективно, но решением будет открыть stream на строке и читать её как поток символов (текущую позицию сохраняет "драйвер" потока для строк и не прыгает по блокам). Xотя это всё overkill для простого шаблонизатора вебстраничек для вебинтерфейса мудрёной железки

Цитата(Void @ 15.1.2006, 21:39 )

P.S. Как-то скачкообразно дискуссия движется smile Может посты сугубо про OCaml выделить из темы?

Не думаю, ведь серьёзно Fortress пока не обсуждаем, только гадаем что вкусного у него есть + просто свои мысли, полезно читая спецификацию врубаться как же оно реализовываеться

Цитата(Void @ 15.1.2006, 22:27 )

Двух фреймворков скорее всего не будет, Intel и другие получат возможность встраивать собственные кодогенераторы.

Это я имел в виду. Конечно .Net та же будет одна. Но все равно, как пользователю выбирать и настраивать кодогенератор. Сейчас по оптимизации много фич накрутили: можно даже автопрофилирование делать -- прога запускается и во время своей "стандартной работы" кидает "какую-то" хитрую инфу в отдеьный файл. Потом компилируешь снова, указываешь использовать наработанный файл. На основе него он делает оптимизацию, и при стандартной работе твоя прога ведет себя довольно шустро.
Компиляция в MSIL -- вещь не благодарная. Там же все в простых терминах написано, на псевдо ассемблере, а про саму библиотеку .Net я вообще молчу -- она же вообще не должна компилиться, на сколько я знаю, стоит себе и стоит под Виндой.
Заботливый компилятор показывает, какие циклы векторизовались, какие нет, почему так и т.д. А тут у него один MSIL. А ведь векторизация -- это грубо увеличение скорости работы цикла со стандартными операциями во столько раз, сколько АЛУ по плавающей точе установлено на проце. У камней с SSE3 их, кажись, 4. Актуально, не правда ли?
Про управляемый код -- можешь обозвать любой язык .Net'ом (например, MC++) и использовать для него соотв. компилятор, но, объясняя все в терминах MSIL, особо не разгонишься, никакой специфики проца. А выполнять его будет только CLR, на к. покушаться третьим лицам не разрешено вообще-то.

Цитата(Sardar @ 15.1.2006, 23:29 )

malloc/free для "обычной" памяти

Да мне бы матрицу или массив освободить самому через какой-нить deallocate -- так ведь и этого не дают.

Цитата(Sardar @ 16.1.2006, 00:58 )

Не думаю, ведь серьёзно Fortress пока не обсуждаем, только гадаем что вкусного у него есть + просто свои мысли, полезно читая спецификацию врубаться как же оно реализовываеться

Sun этим серьехно занилась. Слышал тестирования и разработка и в Питере проходит.

Цитата(Sardar @ 16.1.2006, 01:58 )

4Мб или 4.Е6 элементов?

4 миллиона элементов (ну и соответственно 16 Мб). Для float array - только 2 млн., потому что компилятор трактует массив вещественных чисел особым образом, храня их сразу в unboxed виде.

Цитата(Sardar @ 16.1.2006, 01:58 )

У себя со строками хорошо провернул, не мутируемые, созданные из блоков и связанных списков "указателей" на части блоков. Это помогает не транжирить память при многих строковых операциях, например "test: " + 90 +"Mb" или "[pad]" * 3 (создать новую строку как сложив "[pad]" три раза), также подстроки и другое. Цена этому накладные расходы при чтении строк, например выбирать посимвольно charAt(индекс) будет жутко не эффективно

Кстати, вот в этом документе описывается интересная структура данных VList, с амортизированным временем конкатенации и произвольного доступа к элементу в O(1), при некоторой избыточности по памяти.

Цитата(Cr@$h @ 16.1.2006, 07:06 )

А тут у него один MSIL. А ведь векторизация -- это грубо увеличение скорости работы цикла со стандартными операциями во столько раз, сколько АЛУ по плавающей точе установлено на проце. У камней с SSE3 их, кажись, 4.

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

Будет 8 АЛУ с регистрами длиною в 8 байт -- будет в восемь раз прирост, грубо, конечно.
Но мы отошли. Так или иначе от управляемого кода никто уходить не собирается, и незачем, поэтому обязательно что-то придумают и для аппаратной специфики...

Занятно: хотя название предполагает родство с Фортраном, язык значительно больше напоминает APL. Также собственный набор символов, близость к нормальной математической нотации, мощная матричная алгебра и пр. Но идея может быть и неплохая.