LINUX.ORG.RU

Вызов лисперам.

 


2

5

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

Я часто вижу на ЛОРе утверждения наподобие такого: «Лисп-макросы дают возможность создавать DSL под задачу, а саму задачу решать на языке предметной области». Дальше обычно следуют выводы: благодаря этому лиспер во много раз производительнее программиста на С, С++, Java, Python и прочих non-Lisp языках. Сразу disclaimer: я тут ни на чьей стороне, мне самому интересно посмотреть, как работает этот подход. В частных беседах добиться особо ничего не удалось, разве что «я тут писал DSL для разбора лисповых DSL, чтобы можно было DSLить, пока DSL разбирается; а eDSLей так вообще было не счесть». Поэтому предлагаю решить предельно конкретную задачу, в которой, кстати, есть острая нужда.

Есть такой замечательный дистрибутив Gentoo, наверняка многие им пользуются. У него прекрасная концепция, но есть большая проблема с пакетным менеджером portage. Он — «невыносимо тормозной», а его разработчики "не хотят лезть в это адское спагетти из пистона и баша". Перевожу на профессиональный язык: portage имеет проблемы с производительностью и поддерживаемостью. Вероятно, отчасти из-за неудачного выбора языков реализации.

ЛОРовцы уже кинули клич на предмет переписывания portage на С/С++, но как мне показалось, делишки идут неважно. Давайте поможем общему делу? Мне кажется, задача просто идеальная:

1. Не «Hello, World», но и не система управления ядрёным реактором. Судя по утверждениям лисперов, такое должно занять от одного вечера до нескольких дней. Таким образом, проверяем claim о производительности лиспера;
2. Исходный продукт испытывает проблемы с перфомансом. Проверяем claim о том, что лисп не тормознее сишечки, а также claim, что на лиспе проще реализовать правильные алгоритмы и структуры данных;
3. Предметная область — пакеты, метаданные, содержимое, зависимости, сборка и установка. Предельно ясная и самодостаточная. Проверяем claim о DSL и решении задачи на языке предметной области.

Итак, ТЗ — реализовать Gentoo portage на лиспе вашей мечты, The Right Way(TM). Приз — всенародное признание, сотни нефти и гарем из 99 девственниц подросшая репутация лиспа :) Впрочем, пацаны вроде даже собирались скидываться на условную «бутылку Жигуля». Кстати, призываю Chaser_Andrey в свидетели.

Ну, что? Challenge accepted?


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

намекаешь на то, что gcl, который конпелирует через gcc — оптимизирует лучче?

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

А на сколько порядков sbcl медленнее чем Си?

http://benchmarksgame.alioth.debian.org/u64/code-used-time-used-shapes.php — в ~три раза?

Ну и какой смысл после этого всякую лажу про «native compiler» нести?

Тем не менее оно там рядом с OCaml, GHC, Go, C# mono, Scala и Java валяется.

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

ага, то ли cygwin, то ли SUA. в любом случае, и то, и другое — костыль. а вот кросссборка через mingw из-под линакса немного имеет смысл, но всё равно нужно делать свой профиль и тестировать. а если мингв нужен чтобы собрать свою софтинку под оффтопиком, то хватит и какого-нибудь IMcross или mxe.org и вручную навелосипеденного скрипта, вместо ебыдлов.

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

The project was started in 2006, and is currently (2013) not under active development anymore.

уже не пилят, кажется

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

с двумя звёздочками: подумать, как можно на Guix реализовать MULTISLOT фичу из ебилдов.

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

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: Воу, воу, палехчи от BYHYRT

Задача неинтересная и нудная, никто не будет в такой челендж

anonymous
()

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

pseudo-cat ★★★
()
Ответ на: комментарий от vurdalak

Представил бодибилдера в кресле с пледом.

Зачем представлять когда хаскелисты поголовно штангисты?

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

А дальше нужность неочевидна.

Нужность клиспа для тебя неочевидна? Беда просто.

так ещё и возьмём не лучшую реализацию этого языка %)

Порой она единственная. Не было бы clisp'а - не было бы sbcl для моей стрекозы

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

Что ты, кому надо пинать убогих? Зачем срамить и без того обосравшихся? Лисперы своей жизнью доказали, чего их лисп стоит. Один в макдональдсе работает в 35 лет, причем не менеджером, другой с велосипедов падает и гордится этим, третий и вовсе фашист и шизик. И все поголовно при этом лживые, чванливые ублюдки.

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

Лиспер-фашист? Даже не знаю, кого он больше позорит. То ли лисперов фашизмом, то ли фашистов лиспом.

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

Нужность клиспа для тебя неочевидна?

Вообще я про сабж на лиспе вообще и на клиспе (тем более) в частности.

Хотя допускаю, что последний может быть полезен как скриптовый _портабельный_ вариант CL.

А так

http://maxima.sourceforge.net/lisp.html

CMUCL is a fast option for Maxima on platforms where it is available.

Clisp is compiled to bytecodes, so Maxima running on Clisp is substantially slower than on Lisps compiled to machine instructions. Clisp computes floating-point operations in software, so floating-point operations in Clisp are much slower than in Lisps which make use of hardware instructions for floating-point operations.

http://www.cliki.net/performance benchmarks, http://www.cliki.net/Performance Benchmarks2.

Именно в связке GNU/Linux/SLIME/CLisp вообще не вижу смысла — оно будет с той стороны торчать, выполняя единственно что роль тормоза, CCL или SBCL явно лучше же.

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

Пщщщ.

А бигнумы якобы быстрее в clisp'е и чё?

скриптовый _портабельный_ вариант CL.

Как это «скриптовый вариант CL»?

lisp computes floating-point operations in software, so floating-point operations in Clisp are much slower than in Lisps which make use of hardware instructions for floating-point operations.

Можно подумать, что конёк максимы это именно floating point operations.

CMUCL

Вот что не нужно, когда есть sbcl.

А всякая фигня типа hunchentoot будет одинаково медленно работать, что на clisp, что на sbcl.

Вобщем, не обижай мой клиспик :)

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

А бигнумы якобы быстрее в clisp'е и чё?

Если и «быстрее» (вот уж не знаю), то за счёт GMP, у SBCL про это тоже есть sb-gmp.

Как это «скриптовый вариант CL»?

Интерпретируемый (-> переносимый) диалект/реализация CL (а всякая реализация — диалект, что требует сглаживания всякими trivial-foo и т.п.).

Можно подумать, что конёк максимы это именно floating point operations.

Вот что не нужно, когда есть sbcl.

Ты не понял — там CMUCL характеризуется как «fast», а SBCL — «тот же CMUCL». Так что, да, предпочтительно пускать её на SBCL, чтобы не «substantially slower».

А всякая фигня типа hunchentoot будет одинаково медленно работать, что на clisp, что на sbcl.

Точно?

Вобщем, не обижай мой клиспик :)

GNU/Linux

И да, в этом я тоже не вижу смысла

Ну видимо бытие определяет сознание^W^W^W бздя склоняет к клиспофажеству :)

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

Точно?

Абсолютно. Там 80% времени отправляются/принимаются данные из сокетов и городятся потоки (там схема одно соединение - один поток, что уже, как мне объяснили, не гуд).

Ты не понял — там CMUCL характеризуется как «fast», а SBCL — «тот же CMUCL». Так что, да, предпочтительно пускать её на SBCL, чтобы не «substantially slower».

В sbcl нет readline, поэтому надо использовать обертку. Но это не суть. А суть в том, что для 90% задач, которые решает maxima, надо что-то кроме работы с числами с плавающей запятой, и вряд ли это что-то сильно хуже в clisp.

бздя склоняет к клиспофажеству :)

Да я сам тоже sbcl пользую, просто clisp ну супер-пупер. Его единственный минус - медленота, что не всегда критично.

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

Абсолютно

http://archimag.lisper.ru/2009/09/21/ClozureCL_и_lisper.ru, и это clozure. Хотя это не голый как-его-там, конечно.

В sbcl нет readline

Ну у максимы есть wxMaxima. Вообще для CL — SLIME предпочтительней (так что даже не важно кто там на сокете слушает). Или alias sb="rlwrap sbcl" в крайнем случае.

вряд ли это что-то сильно хуже в clisp

При расчётах оно всё равно CPU кушает, вне зависимости. Например:

$ \time maxima --lisp=clisp --batch-string="run_testsuite();" < /dev/null

...

No unexpected errors found out of 9,699 tests.
Real time: 1149.2266f0 sec.
Run time: 1142.0214f0 sec.
Space: 27643386952 Bytes
GC: 7378, GC time: 129.91527f0 sec.
(%o0)                                done
1104.77user 37.37system 19:09.35elapsed 99%CPU (0avgtext+0avgdata 100000maxresident)k
0inputs+0outputs (0major+8940096minor)pagefaults 0swaps

$ \time maxima --lisp=sbcl --batch-string="run_testsuite();" < /dev/null

...

No unexpected errors found out of 9,699 tests.
Evaluation took:
  211.233 seconds of real time
  209.341175 seconds of total run time (208.092365 user, 1.248810 system)
  [ Run times consist of 5.906 seconds GC time, and 203.436 seconds non-GC time. ]
  99.10% CPU
  14,960 forms interpreted
  8,816 lambdas converted
  421,507,998,452 processor cycles
  5 page faults
  30,903,766,368 bytes consed
  
(%o0)                                done
208.16user 1.30system 3:31.38elapsed 99%CPU (0avgtext+0avgdata 593152maxresident)k
720inputs+0outputs (6major+192290minor)pagefaults 0swaps

Его единственный минус - медленота, что не всегда критично.

Ок. Но товарисч утверждает, что «Исходный продукт испытывает проблемы с перфомансом. Проверяем claim о том, что лисп не тормознее сишечки» :)

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

Лиспер-фашист

Кстати, он при этом еще и запутинец. Такое вот причудливое сочетание, да: запутинец, фашист и лиспер.

И, кстати, он не единственный лиспер-фашик, здешний ugoday тоже из этих. Еще раз подтверждается гипотеза, что одна шиза липнет к другой.

anonymous
()

emulek, C++-программист — наркоман!

pihter, PHP-программист — наркоман!

Борще-архитектор, Java-программист — наркоман!

Откажись от наркотиков — выбери Lisp!

anonymous
()

Творцы мейнстрима

Бьёрн Страуструп. C++. Психически болен.
Александр Степанов. C++. Наркотическое отравление.
Андрей Александреску. C++. Психически болен.
Гради Буч. ООП. Психически болен. Шизофазия.
Банда четырех. ООП. Организованная преступность. Диверсанты.
Джеймс Гослинг. Java. Диверсант.
Андерс Хейлсберг. C#. Главный архитектор Delphi. Диверсант.
Расмус Лердорф. PHP. Умственно отсталый.
Гвидо ван Россум. Python. Умственно отсталый.

Довольно!

Just Lisp. Since 1958.

anonymous
()

Вызов лисперам

уже прислали? Они таки едут?

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

Ок. Но товарисч утверждает, что «Исходный продукт испытывает проблемы с перфомансом. Проверяем claim о том, что лисп не тормознее сишечки» :)

Тут дело как раз не в суперпроизводительности, а в том, что надо правильно спроектировать менеджер, и всё будет OK. Я думаю, у BSD make вряд ли «суперпроизводительность», но порты на нём не тормозят.

Да и clisp уж никак не хуже CPython, так что тормознее написать уже никак не выйдет :)

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

У дефолтного portage проблема в задержках после вызовов emerge — порядка секунды для atom, десятка секунд с изменёнными USE, @set — вообще дофига (следующий порядок) и т.п. Размер strace от выполнения emerge на @world — миллион вызовов, представляющих собой муки с /var/db/pkg, /etc/portage и деревом ебилдов (ну и питончик, конечно). При этом во время расчёта зависимостей emerge таки съедает 100% ядра, то есть нельзя сказать, что он совсем в IO упирается.

Мне видится, что нужно вытащить все данные из дерева ебилдов, /var/db/pkg и /etc/portage в подходящие для быстрых запросов структуры данных (пусть blob-ы, типа как у eix), сами запросы — алгоритмы которым производительность всё-таки важна (хотя структуры данных тут и решают). Так что это скорее всего C++.

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

Ох, вот это бомбануло так бомбануло. MMMMMAXIMUM BUTTHURT!!!

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

Как они копипастят целыми топиками. Как пытаются плеснуть тем же «борщом» в ответ. Как передирают самые удачные и красноречивые дискуссионные обороты у оппонентов.

И в этом вся суть лиспа. Весь лисп-мирок вторичен; удел лиспера — плестись в хвосте IT-прогресса, кое-как копируя у других, чтобы доказать, что лиспу на самом деле есть место в поезде, в последнем вагончике, под шконкой.

Но даже этого места у него нет. Since 1958.

anonymous
()

Уголовные дела преступного IT-мира

Подсудимый: Бьёрн Страуструп.
Преступление: C++.
Мотив преступления: Психическая болезнь.
Приговор: Принудительное лечение в психиатрической больнице.

Подсудимый: Александр Степанов.
Преступление: STL.
Мотив преступления: Состояние наркотического опьянения.
Приговор: Три года исправительных работ.

Подсудимый: Андрей Александреску.
Преступление: Шаблоны.
Мотив преступления: Психическая болезнь.
Приговор: Принудительное лечение в психиатрической больнице.

Подсудимый: Гради Буч.
Преступление: Главарь секты ООП.
Мотив преступления: Психическая болезнь. Шизофазия.
Приговор: Принудительное лечение в психиатрической больнице с конфискацией имущества.

Подсудимые: Банда четырех.
Преступление: Паттерны.
Мотив преступления: Фанатики секты ООП.
Приговор: 35 лет лишения свободы строгого режима с конфискацией имущества.

Подсудимый: Джеймс Гослинг.
Преступление: Java, наемник.
Мотив преступления: Нажива.
Приговор: Два пожизненных заключения без права досрочного освобождения.

Подсудимый: Андерс Хейлсберг.
Преступление: Delphi, C#, наемник.
Мотив преступления: Нажива.
Приговор: Смертная казнь.

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

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

в математику можно только верить.

а значит можно и не верить :)

Bad_ptr ★★★★★
()

06.12.2013 18:56:51

не хочу читать срач, просто скастуй, если взлетит. Хотя-бы на сантиметр.

Спасибо.

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

теперь я знаю, что представляют лисперы, когда фапают...

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

Теорема Геделя о неполноте как бы говорит нам, что в математику можно только верить.

если неосилил, то какие ещё варианты?

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