Выбор ЯП.

От этого ЛNСП будет волшебным образом жрать памяти на порядок меньше, чем JVM? Дооооо.

Память жрут программы, а не системы управлением памятью. В Gensym писали программы на общелиспе, которые мусор не плодили.

Кстати, не надо забывать, что все приличные лиспы (не огрызки вроде ECL) тянут за собой в ОЗУ весь компайлер с потрохами. Не знаю, будет ли ТС счастлив от лишних 100 мегабайт рантайма.

Ну, не сто, а меньше. К тому же, наличие полноценного конпелятора в рантайме - это далеко не обуза, как только вы научитесь писать на лиспе. К тому же, state of the art конпеляторы общелиспа умеют делать shake tree, когда из бинарника выкидывается всё, не имеющее отношение к работе основной программы. В том числе и конпелятор.

И вообще, вы в курсе, как в Common Lisp сегодня обстоят дела с многозадачностью? Начинать надо с этого.

Великолепно. В LW, CCL проблем нет, обычный позикс тредс с лиспоспецифичными плюшками.

Кроме того, мой личный опыт показал, что использовать низкоуровневые биндинги через FFI — не самй оптимальный путь, т.к. скачки туда-сюда крайне напряжны для мозгов программиста и аппаратуры компьютера.

Пиши лучше про монады %)

Также пробовал миграцию на CCL, но тоже не сложилось, почему то он дико тормозил на IO. Опять же может починили, но я уже в их сторону не смотрел довольно долгое время.

умным людям в SUN - маркетологи помогали , по Ораклу задумайся за что получают админы(которые DBA и выше) свой хлеб и отчего .

Я на самом деле пока остановился на CL, по мере изучение и написания, посмотрим, что получится.

А можно я вам помогу в плане лиспового multithreading?

Начнём с того, что в стандарте Common Lisp этого нету. За пятьдесят лет как-то не удосужились. Поэтому то, что в современных мейнстримных языках доступно «искаропки», в лиспе представлено набором vendor-specific костылей (для каждой реализации CL) и несколькими попытками их объединить. Самой популярной из них является Bordeaux-Threads.

Но дело даже не в костылях. Попробуйте смеха ради написать следующую простенькую программку: создать 1000 тредов, которые бы висели на мьютексе. Напишите один вариант на С++, с использованием boost::thread или нового std::thread. Другой - на Common Lisp, при помощи SBCL и его расширений sb-thread. Замерьте потребляемую память. Результаты вас ошеломят, я гарантирую это!

Для справки. В моём варианте программа на С++ отработала успешно, затратив 71МБ памяти. Программа на Common Lisp вывалилась в дебаггер с сообщением «mmap: Невозможно выделить память», отожрав БОЛЬШЕ 3 ГИГАБАЙТ оперативки и уперевшись в предел виртуальной памяти.

Выводы сделаете сами?

Только Clojure.

Начнём с того, что в стандарте Common Lisp этого нету. За пятьдесят лет как-то не удосужились.

В сишечке тоже нету. В крестах вчера буквально появились.

Но дело даже не в костылях. Попробуйте смеха ради написать следующую простенькую программку: создать 1000 тредов, которые бы висели на мьютексе.

1000 тредов в одной программе, если они не зелёные, не имеет смысла даже на C++.

Напишите один вариант на С++, с использованием boost::thread или нового std::thread. Другой - на Common Lisp, при помощи SBCL и его расширений sb-thread. Замерьте потребляемую память. Результаты вас ошеломят, я гарантирую это!

С каким это пор долдоедизм стал ошеломительным?

У Ocaml с многопоточностью не очень. Что-то фатальное со сборщиком мусора.

А что можешь сказать про Jocaml (вроде как раз для параллельности и распределенности пилится)?

Для справки. В моём варианте программа на С++ отработала успешно, затратив 71МБ памяти. Программа на Common Lisp вывалилась в дебаггер с сообщением «mmap: Невозможно выделить память», отожрав БОЛЬШЕ 3 ГИГАБАЙТ оперативки и уперевшись в предел виртуальной памяти.

Чет я очень сомневаюсь, что есть такие проблемы с памятью.

Если вы так против CL, что тогда используете сами?

Можно еще Racket попробовать.

LispWorks конечно ;)

А теперь озвучь, пожалуйста, для ТС стоимость лицензии. :)

А что можешь сказать про Jocaml

OCaml - по-своему неплохой язык, но его постигла бы судьба остальных ML-подобных если бы не а) Coq, ради которого он и живет; б) наличие исследовательской группы в INRIA; в) сотрудничество с M$ Research Cambridge в области F#; г) остаточный интерес, возникший в эпоху когда языки группы SML были «уже не», а Haskell был «еще не».

За последние лет 5 хаскель прошел громадный путь. Про окамл, к сожалению, этого не скажешь.

если оно будет необходимо, цена не проблема.

OCaml - по-своему неплохой язык, но его постигла бы судьба остальных ML-подобных если бы не а) Coq, ради которого он и живет; б) наличие исследовательской группы в INRIA; в) сотрудничество с M$ Research Cambridge в области F#; г) остаточный интерес, возникший в эпоху когда языки группы SML были «уже не», а Haskell был «еще не».

За последние лет 5 хаскель прошел громадный путь. Про окамл, к сожалению, этого не скажешь.

Это все понятно, но меня интересовало мнение общества про Jocaml ( http://jocaml.inria.fr/ ), использует его кто или нет и какие успехи?

Лично мне камл по душе, но больше в нише разного рода парсинга из-за ocaml4p, впрочем я бы не стал его рекомендовать как язык общего назначения.

1000 тредов в одной программе, если они не зелёные, не имеет смысла даже на C++.

Если мне не изменяет память, нормальных зелёных тредов (распихиваемых по системным тредам самим рантаймом) в свободных CL нет :(

(распихиваемых по системным тредам самим рантаймом)

Если распихать треды по системным, то они сразу перестанут быть зелеными.

если n-зелёных на 1 реальную, то вполне.

А что можешь сказать про Jocaml (вроде как раз для параллельности и распределенности пилится)?

Пока ничего.

если n-зелёных на 1 реальную, то вполне.

это и имелось в виду, сорри за «словесную скупость»

А теперь озвучь, пожалуйста, для ТС стоимость лицензии. :)

цена, если честно, не важна, если покупаемый инструмент позволяет решать задачу быстро и качественно. Нормальная компания заплатит за хороший инструмент разработчику. Что касается цены, для LW начиная $1500 за лицензию, так это вообще смешные деньги.

Гм. И где так можно?

Erlang, Haskell и в некоторых коммерческих релизациях CL.

Ну эрланг не считается, там другая модель исполнения, а вот на счет haskell и lisp интересно - каким образом на системные треды раскладывается сборщик мусора, который менеджит расшаренную память?

Чет я очень сомневаюсь, что есть такие проблемы с памятью.

Послушайте, зачем мне вам врать? Возьмите простенькую программку:

(defvar *N* 1000)
(defvar *a-mutex* (sb-thread:make-mutex :name "my lock"))

(sb-thread:grab-mutex *a-mutex*)

(loop for a from 1 to *N* do
 (sb-thread:make-thread
  (lambda () (sb-thread:grab-mutex *a-mutex*))))

Запустите её (sbcl --load foo.lisp). Варьируя *N*, поймайте момент, когда программа начнёт вываливаться в отладчик. Не выходя из отладчика, посмотрите, сколько памяти отъедено программой (при помощи top, htop, системного монитора и т.д.). Удивитесь.

Если вы так против CL

Я не против CL как такового. Я против слепого, бездумного выбора в пользу лиспа, хаскеля etc. только потому, что он «не такой, как все», что по нему угорают ЛОРовские «илитарии» и что их стараниями вокруг лиспа сложился ореол «небыдлоязыка».

Это обычный язык программирования, со своими особенностями, достоинствами и недостатками. Применять его нужно к месту. Мой опыт подсказывает, что реальные его достоинства (к слову, весьма немногочисленные) в вашем случае не выстрелят. А вот недостатки как раз вызовут кучу геморроя и в результате не позволят создать эффективное решение, удовлетворяющее вашему ТЗ.

что тогда используете сами?

В вашем случае я бы использовал для прототипирования Python или даже JavaScript (в реализации GJS или Seed плюс «батарейки» GLib через GIR). На этом этапе нужен лаконичный динамический язык с автоматическим управлением памятью. В принципе, я не исключал бы здесь использования CL или Scheme. Но учитывайте, что я одинаково хорошо владею и питонами, и лиспами, а вам (в случае выбора последних) придётся довольно долго вкуриваться в их инопланетную сущность.

На стадии прототипирования вам необходимо просто убедиться, что ваша модель работает и масштабируется. После этого речь зайдёт об удовлетворении нефункциональных требований (производительность, расход памяти и т.п.) А вот здесь лучше статических компилируемых языков человечество пока ничего не придумало. Поэтому мой выбор - новый С++11 (или старый плюс Boost) или, ещё лучше, Vala.

В сишечке тоже нету.

Ага, а pthread кагбэ и не существовал никогда.

С каким это пор долдоедизм стал ошеломительным?

Прошу прощения, я не владею вашим сленгом, так что не знаю, что вы имеете в виду под этим словом. Но 3 гигабайта против 71 мегабайт на одной и той же задаче - это ведь по крайней мере «весьма существенная разница», не так ли?

каким образом на системные треды раскладывается сборщик мусора, который менеджит расшаренную память

http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Scheduler (также http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#monads и http://stackoverflow.com/questions/3063652/whats-the-status-of-multicore-prog...).

Про коммерческие CL не знаю. В CMUCL был (есть) зелёный планировщик, но там, в отличии от Эрланга и GHС, в которых переключение осуществляется постольку, поскольку переключаемый код уже содержит нужные yield-ы, а всё блокирующее или невозможно (в Эрланге - асинхронные сообщения, никаких блокировок), либо как-то специально отделено, так вот, в CMUCL планировщик на time slicах работает. Интерфейс у него такой же как и у обычных тредов (make-thread и т.д.), но если, например, запустить hunchentoot с ним, то никакого масштабирования не получится (как это получается у Yaws и Snap) - блокирующее IO просто сломается.

Кстати, очень рекомендую прислушаться к замечанию mv (у него иногда бывают проблески):

1000 тредов в одной программе, если они не зелёные, не имеет смысла даже на C++.

Операции с нативными thread'ами (создание, переключение) весьма тяжеловесные. Поэтому, если вы собираетесь выполнять тысячи параллельных задач, то вам придётся задуматься о более масштабируемом решении. Языки с «зелёными нитями» (поясняю - с легковесными нитями, которые целиком управляются виртуальной машиной и не отображаются на системные нити) вам не подойдут, т.к. они все VM-based, и по большей части интерпретируемые (Python, Erlang).

haskell, же см. статьи SPJ.

То есть сборщик мусора по тредам ОС не раскидывается. Смысл тогда в этом всем, если как только мы начнем массово выделять память весь параллелизм сразу полетит к чертям?

Как мы только что выяснили хаскель так не умеет. То есть он да, раскидывает, но толку от этого нет, мог с тем же результатом и не раскидывать.

это только ты выяснил.

это только ты выяснил.

Когда физики заявляют об открытии новой элементарной частицы, ты им тоже так отвечаешь?

Ну почему фанбои хипстерских язычков такие упоротые? Так термоядерно только у вас пердак рвет от критики в адрес вашей религии.

Там в ссылке черным по белому, что сборщик мусора блокирует все треды, лечи глаза.

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

Кстати, в ненавидимой вами, хипстерами, Жабке уже десять (!) лет как имеется parallel & concurrent garbage collector.

ULTIMATE BUTTHURT!

То есть сборщик мусора по тредам ОС не раскидывается. Смысл тогда в этом всем, если как только мы начнем массово выделять память весь параллелизм сразу полетит к чертям?

Ну осталось написать параллельный сборщик мусора. Делов то.

цитату, а то тут рядом валяется статья, где черным по белому написано, что сборщик мусора распихивается по реальным ядрам, правда я не уверен, что это уже в апстриме.

батхёрт у анонимов только, которые из астрала параллельного мира вытаскивают инфу о собеседниках, и фактах (относящихся к параллельному миру) :)

stay calm... stay calm..

Ну осталось написать параллельный сборщик мусора. Делов то.

В жабке сделали 10 лет назад, ага. Но это всё, конечно, же, в маркетоидных целях!!!111

в ... Жабке уже десять (!) лет как имеется parallel & concurrent garbage collector.

Угу, и только с версии 1.6 JVM обрела более менее приличную скорострельность.

Угу, и только с версии 1.6 JVM обрела более менее приличную скорострельность.

Может, не будем передёргивать? Производительность JIT-компилированного кода и concurrency - вещи ортогональные.

Угу, и только с версии 1.6 JVM обрела более менее приличную скорострельность.

И все равно тормозит по черному. ;-)

имхо у явы лучший сборщик мусора их всех mutable языков :)

То есть сборщик мусора по тредам ОС не раскидывается

in the current single-threaded GC, all activity has to stop in order to GC

Это устаревшая информация - http://donsbot.wordpress.com/2009/03/04/playing-with-ghcs-parallel-runtime, http://hackage.haskell.org/trac/ghc/blog/new-gc-preview.

Но при этом он всё ещё stop-the-world, так что какого-то очень значительного прорыва с -g (-q) вряд ли можно ожидать.

Смысл тогда в этом всем, если как только мы начнем массово выделять память весь параллелизм сразу полетит к чертям?

http://snapframework.com/blog/2010/11/17/snap-0.3-benchmarks, например. Это всё неплохо масштабируется. Можно форкать процессы ОС, вручную мультиплексировать IO события или форкать лёгкие процессы у которых есть только вычислительный контекст, а всё IO отправляется в IO manager в VM (где уже и мультиплексируется, но не вручную). У Эрланга есть преимущество в том, что у него кроме IO есть ещё time manager - можно расставлять процессам таймауты (c soft realtime гарантиями).

бабла в нее вбухано немеренно, вот и вылизали. Но все равно тормозит.

Как из того, что «сборщик мусора блокирует все треды» следует «как только мы начнем массово выделять память весь параллелизм сразу полетит к чертям»?

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

И все равно тормозит по черному. ;-)

Но ведь ЛИСП еще в два раза медленнее.

http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastes...

правда я не уверен, что это уже в апстриме

Это в апстриме начиная с 6.10 (2009 год, то есть).

имхо у явы лучший сборщик мусора их всех mutable языков :)

возможно, но есть тесты сравнения именно работы gc? И какой именно из тех 3-х или 4-х (сколько их в 7-ке?), вы имели в виду? :)