LINUX.ORG.RU

Выбор ЯП.

 


0

2

Привет.

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

В данный момент, хочется изучить что-то новое.

Полистал форум, после прошелся по вики, почитал про языки, которые более «симпотизируют», если так можно выразиться, собственно список:

  • OCaml, честно говоря, не знаю, что сказать, мнение не однозначное, очень мало библиотек, многое надо будет самому.
  • Go, очень напомнил python, с беглого просмотра исходных кодов, готового проекта. На первый взгляд понравился. Вроде активно развивается.
  • Scheme, и так потихоньку изучаю, по мере чтения sicp, но что-то писать на нем, думаю, только если для себя.
  • Erlang, думаю, это пока совсем не для меня, но ваше мнение хотелось бы услышать.
  • CL, так же как и со схемой, не обычно, не могу точно сказать, подойдет ли мне он.
  • Haskell, читаю очень поверхностно, но пока обхожу стороной.

Да, языки описал, а задачу собственно нет.

Как таковой конкретной задачи нет, она появляется через некоторый промежуток времени. Например, надо будет реализовывать планировщик(думаю это правильное название), который будет принимать много «заданий», создавать для них очередь и постепенно ее выполнять. Да, все это можно написать на питоне, что сейчас успешно и делается, но хочется попробовать что-то новое.

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

Извиняюсь, если все сумбурно и не внятно описал.

Заранее, огромное спасибо.

★★★
Ответ на: комментарий от yyk

возможно, но есть тесты сравнения именно работы gc?

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

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

qnikst ★★★★★
()
Ответ на: комментарий от quasimoto

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

ок. А с SMP как дела обстоят, просто в старых статьях отмечалось, что проблем куча и пока не ясно как их правильно решать. (а до новых ещё не дошёл).

qnikst ★★★★★
()
Ответ на: комментарий от anonymous

Выделяем память => запускается сборщик

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

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

Т.е. разрабы ACL, жабки и хаскеля нагло врут?

yyk ★★★★★
()
Ответ на: комментарий от anonymous

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

Оооо, это всё тесты именно gc? Ты потише - вод всех океанов не хватит на столько газа

yyk ★★★★★
()
Ответ на: комментарий от qnikst

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

да я не то чтобы сомневался, просто думал может есть точная инфа ;)

yyk ★★★★★
()
Ответ на: комментарий от yyk

просто я с жабкой давно (>года) не сталкивался подробно, когда сталкивался тогда искал и инфу по gc и особенности реализации. К сожалению, чтобы найти ту инфу и бенчмарки потребуется много времени. Тем более, если будет сравнение с CL, то его там точно не было. Так что про жабку это сложившееся впечатление, опровержения которого я пока не встречал.

qnikst ★★★★★
()
Ответ на: комментарий от yyk

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

Тут уже зависит, ясное дело, от конкретного сборщика и конкретного алгоритма, но если сборщик generational, а алгоритм традиционный для ФП - то есть с массовым выделением мелких объектов, то minor gc будет дергаться постоянно.

Т.е. разрабы ACL, жабки и хаскеля нагло врут?

Ну или у них треды не слишком зеленые, либо параллельность не слишком параллельная :)

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

anonymous
()
Ответ на: комментарий от yyk

Т.е. разрабы ACL, жабки и хаскеля нагло врут?

Они не врут, они тупят. Умные люди в такое дело не полезут, а с дураков по любому взятки-гладки.

anonymous
()
Ответ на: комментарий от anonymous

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

Существуют non-blocking parallel GC. Они есть и для Java, и для .NET. Естественно, для какацкелей такого не предусмотрено, разработчикам какацкеля умишка не хватит.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо.

Прототип уже пишется пишется ан Python, и половина уже сделана и работает.

Не хочется использовать C++, если честно, начал его изучать, писал маленькие программки - не мое.

SAA ★★★
() автор топика
Ответ на: комментарий от anonymous

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

Не совсем понятно, почему не подойдут?

SAA ★★★
() автор топика
Ответ на: комментарий от anonymous

Существуют non-blocking parallel GC.

Но они же тормозные и их все равно никто не применяет на практике.

anonymous
()
Ответ на: комментарий от SAA

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

gensym ★★
()
Ответ на: комментарий от anonymous

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

Тогда зелёные треды ничего общего с параллельным исполнением не имеют (в общем), а на одноядерном проце - и системные треды тоже. Хватит срать терминологическими кирпичами

yyk ★★★★★
()
Ответ на: комментарий от anonymous

Они не врут, они тупят. Умные люди в такое дело не полезут, а с дураков по любому взятки-гладки.

А, месье д'Артаньян, вас сразу не признать...

yyk ★★★★★
()
Ответ на: комментарий от yyk

Тогда зелёные треды ничего общего с параллельным исполнением не имеют (в общем), а на одноядерном проце - и системные треды тоже.

Ну естественно.

anonymous
()
Ответ на: комментарий от anonymous

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

(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. Судя по потреблению памяти, экстраполируется потолок где-то на тридцать тысяч блокировок, но я не проверял, и это еще без учета свопа. А с сотней тысяч блокировок толком не справилась даже java - ушла в непрерывный своп. В общем, надо смотреть, каков реальный сценарий задачи.

dave ★★★★★
()
Ответ на: комментарий от anonymous

ничего общего с параллельным исполнением не имеет

А ничего, что потоки могут останавливаться ИЧСХ совершенно недетерминированно из-за того, что другой процесс/поток захотел что-то записать/прочитать на диск, в память, с удаленного ресурса?

Хотя действительно, «зеленые» потоки к параллельным вычислениям относятся слабо: как бы предполагается что их ЗНАЧИТЕЛЬНО больше, чем доступной вычислительной аппаратуры. «Зеленые» потоки имеют отношение к конкурентности.

В том же хаскеле есть Data Parallel Haskell, DPH сиречь. Построен слегка на других принципах. Может быть не обеспечивает максимальной эффективности, но обладает серьезным достоинством: простотой использования.

Macil ★★★★★
()
Ответ на: комментарий от yyk

Таких, как я, миллионы. Любой средний кодер на Java на порядок умнее любого функциональщика.

anonymous
()
Ответ на: комментарий от anonymous

Я. Жду рассказа о параллельном исполнении на одноядерном процессоре.

Каждый волен решать сам что ему делать :) Хочешь ждать - жди.

А пока будешь ждать, можешь помедитировать и представить себе приставку «псевдо».

Или все твои задачи требуют исключительно монопольного непрерывного исполнения на ядре?

yyk ★★★★★
()
Ответ на: комментарий от gensym

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

Да, я такого варианта и придерживаюсь.

SAA ★★★
() автор топика
Ответ на: комментарий от SAA

Прототип уже пишется пишется ан Python, и половина уже сделана и работает.

Интересно, а питон сколько выдерживает одновременных блокировок по одному мьютексу? GIL не будет мешать?

dave ★★★★★
()
Ответ на: комментарий от dave

Интересно, а питон сколько выдерживает одновременных блокировок по одному мьютексу? GIL не будет мешать?

Это всего-лишь прототип, пока тестов не проводил, но думается, что в этом можно будет легко упереться.

SAA ★★★
() автор топика
Ответ на: комментарий от qnikst

А с SMP как дела обстоят, просто в старых статьях отмечалось, что проблем куча и пока не ясно как их правильно решать

В старых статьях SPJ про инкрементальный сборщик? В GHC не он, там суть изменений в том, что после остановки мира сборка просто выполняется параллельно.

quasimoto ★★★★
()
Ответ на: комментарий от anonymous

но если сборщик generational, а алгоритм традиционный для ФП - то есть с массовым выделением мелких объектов, то minor gc будет дергаться постоянно

Вот GHC в момент такого дёрганья и переключает с одного лёгкого треда на другой.

quasimoto ★★★★
()
Ответ на: комментарий от anonymous

То есть речь шла о конкурентности, а не о параллельности?

А что - jvm отслеживает разнесла она свои треды по системным или нет, или 2 своих треда попали в данный момент в один системный или нет? И обрабатывает такие треды по разному? И если мы говорим о тредах, в том числе и о зелёных, а не о системных процессах, то мы должны забыть о конкурентности и говорить только о параллельности? Наверное интересно обсуждать влияние индийских муссонов на численность слонов в целом на планете, но мне не как-то не хочется.

yyk ★★★★★
()
Ответ на: комментарий от yyk

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

anonymous
()
Ответ на: комментарий от anonymous

Я хотел сказать «переключает/планирует в момент аллокации очередного мелкого объекта» - это триггер планировщика (в Эрланге - достижение определённого числа функциональных редукций).

Если GC дергается, то все треды встают.

Все (виртуальные) хаскельные треды - да. Треды ОС в параллельном GC при этом дружно начинают убирать мусор. Т.е. смысл конкурентного GC в pause-time reduction.

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

Про инкрементальность и отсутствие остановок вообще ничего сказать не могу.

quasimoto ★★★★
()
Ответ на: комментарий от anonymous

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

Как между собой связаны стандарт языка и библиотека операционной системы?

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

Задача висения на мьютексе-то? Я 3 года назад проводил такой эксперимент, SBCL сделал 32278 тредов (т.е. выбрал весь лимит процессов в системе), на память не ругался. А было её в ноутбуке 4гб тогда. CMUCL выбрал весь доступный для него heap 1632 Мб, создав при этом 683214 зелёных тредов.

mv ★★★★★
()
Ответ на: комментарий от anonymous

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

4.2

mv ★★★★★
()
Ответ на: комментарий от anonymous

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

И всё равно там необходима блокировка всех процессов.

mv ★★★★★
()
Ответ на: комментарий от anonymous

Тут уже зависит, ясное дело, от конкретного сборщика и конкретного алгоритма, но если сборщик generational, а алгоритм традиционный для ФП - то есть с массовым выделением мелких объектов, то

То у мелких объектов будет dynamic extent, и они будут автомагически самоудаляться как только frame pointer откатится.

mv ★★★★★
()
Ответ на: комментарий от mv

На правах треда. Посоветуйте годную литературу по многопоточности зеленым тредам и т.д.

anonymous
()
Ответ на: комментарий от mv

SBCL сделал 32278 тредов (т.е. выбрал весь лимит процессов в системе), на память не ругался. А было её в ноутбуке 4гб тогда. CMUCL выбрал весь доступный для него heap 1632 Мб, создав при этом 683214 зелёных тредов.

А тем временем в так ненавидимой лисперами жабке (http://blog.typesafe.com/akka-20-pre-release-milestone-1):

...currently the overhead is around 350 bytes per instance, which translates to about 2.7 million actors per GB in heap size...

...current benchmarks yield 24 million messages processed per second on a standard quad-core MacBook Pro...

Ну и т.д.

ovk48 ★★★
()
Ответ на: комментарий от anonymous

а почему сравниваются треды с какими-то там АКТОРАМИ?

Так каждый актор запускается в отдельном зеленом треде.

ovk48 ★★★
()
Ответ на: комментарий от dave

Если у вас нет ГУИ, то вполне можно обойтись свободными, читай, бесплатными реализациями

А хороший ГУИ - только за деньги.

Это как-то совсем уж все черной краской. Я как раз на CL только GUI и пишу. И tk-шные просто работают.

antares0 ★★★★
()
Ответ на: комментарий от ovk48

Вот у нас есть тест, который показывает скорость передачи сообщений в жабо-тредах:

http://shootout.alioth.debian.org/u64/benchmark.php?test=threadring&lang=...

чуть больше 200000 сообщений в секунду. Если предположить, чт оверхед по памяти тоже ирл больше в 1000 раз, то на гигабайт оперативки мы получим не более 2700 тредов. Не густо. Впрочем, от жабы иного и не ожидалось.

anonymous
()
Ответ на: комментарий от antares0

Я как раз на CL только GUI и пишу. И tk-шные просто работают.

А об этом опыте где-нибудь написано? С удовольствием бы прочитал.

Да, и я больше имел в виду переносимый ГУИ. Например, может быть, cl-gtk2 и хорош, но он только для GTK. На мой взгляд интереснее вещи типа CAPI, которое на винде использует WinAPI, на линуксе - Gtk, а на OS X - кокоа.

dave ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.