Состояние экосистемы Common Lisp на 2015 год

Сейчас бы еще ассемблер SBCL и было бы вообще классно

Но это ведь ложь. Мы только что убедились, что commercial Lisp compiler сосет даже у интерпретаторов - медленнее его оказываются только совсем уж полные тормоза вроде пыхпыха и рубей.

Но ведь это ложь. Здесь не приводились сравнения с интерпретаторами, а также с полными тормозами вроде PHP и Ruby. :-)

Но ведь это ложь. Здесь не приводились сравнения с интерпретаторами, а также с полными тормозами вроде PHP и Ruby. :-)

Здесь приводились сравнения с SBCL, идем на шутаут: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm

SBCL справляется за 4 сек, лиспворкс (как мы видим из нашего треда) примерно в 6 раз дольше, 4*6=24, медленнее только пыхпых, руби, перл и питон

SBCL справляется за 4 сек, лиспворкс (как мы видим из нашего треда) примерно в 6 раз дольше

Ну задрочили в SBCL операции с плавающей точкой, в ущерб общей стабильности рантайма, дальше что? У меня LispWorks крутится 24/7 без остановок в продакшене без единых косяков. В моих программах нет операций с плавающей точкой. Все работает быстро и стабильно. Если мне понадобится серьезная числодробильня, я либо напишу биндинг к библиотеке на си или фортране, либо буду использовать RPC.

Ну задрочили в SBCL операции с плавающей точкой, в ущерб общей стабильности рантайма

Но как видно из этого треда, в лиспорксе рантайм еще и менее стабильный, монк вон приводил пример.

В моих программах нет операций с плавающей точкой. Все работает быстро и стабильно.

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

Но того факта,что лиспворкс - охренеть какой тормоз этого не отменяет. К слову, просер в 6 раз - это уже фикшенный вариант с аннотациями. Без аннотаций там все 40 раз.

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

кстати если уж говорить не о числодробилках а более релевантных программах - было бы интересно посмотреть в сравнении с SBCL на производительность гц (и потребление памяти), то есть тест binary-trees.

в лиспорксе рантайм еще и менее стабильный, монк вон приводил пример.

link?

Здесь приводились сравнения с SBCL, идем на шутаут: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=spectralnorm

Это ничего не доказывает. Вот если бы на этом сайтишке можно было бы выбрать LispWorks, тогда ещё ладно. А так результаты из разных источников. Не канает :-)

Сейчас бы еще ассемблер SBCL и было бы вообще классно

* (disassemble 'eval-A-times-u)

; disassembly for EVAL-A-TIMES-U
; Size: 109 bytes. Origin: #x13ED77E9
; 7E9:       EB5C             JMP L3                          ; no-arg-parsing entry point
; 7EB: L0:   8BF1             MOV ESI, ECX
; 7ED:       31C0             XOR EAX, EAX
; 7EF:       DDD9             FSTPD FR1
; 7F1:       D9EE             FLDZ
; 7F3:       D9C9             FXCH FR1
; 7F5:       EB3E             JMP L2
; 7F7: L1:   8B55FC           MOV EDX, [EBP-4]
; 7FA:       DDDA             FSTPD FR2
; 7FC:       DD444201         FLDD [EDX+EAX*2+1]
; 800:       D9CA             FXCH FR2
; 802:       8D1401           LEA EDX, [ECX+EAX]
; 805:       8D5A04           LEA EBX, [EDX+4]
; 808:       C1FA02           SAR EDX, 2
; 80B:       0FAFD3           IMUL EDX, EBX
; 80E:       D1FA             SAR EDX, 1
; 810:       83E2FC           AND EDX, -4
; 813:       8D5904           LEA EBX, [ECX+4]
; 816:       01DA             ADD EDX, EBX
; 818:       C1FA02           SAR EDX, 2
; 81B:       8955F0           MOV [EBP-16], EDX
; 81E:       DDD8             FSTPD FR0
; 820:       DB45F0           FILD [EBP-16]
; 823:       DDDB             FSTPD FR3
; 825:       D9E8             FLD1
; 827:       D9CB             FXCH FR3
; 829:       D8FB             FDIVRD FR3
; 82B:       9B               WAIT
; 82C:       D8CA             FMULD FR2
; 82E:       9B               WAIT
; 82F:       DCC1             FADD-STI FR1
; 831:       9B               WAIT
; 832:       83C004           ADD EAX, 4
; 835: L2:   39F8             CMP EAX, EDI
; 837:       7CBE             JL L1
; 839:       8B45F8           MOV EAX, [EBP-8]
; 83C:       D9C9             FXCH FR1
; 83E:       DD547001         FSTD [EAX+ESI*2+1]
; 842:       D9C9             FXCH FR1
; 844:       83C104           ADD ECX, 4
; 847: L3:   3B4DF4           CMP ECX, [EBP-12]
; 84A:       7C9F             JL L0
; 84C:       BA0B001004       MOV EDX, 68157451
; 851:       8BE5             MOV ESP, EBP
; 853:       F8               CLC
; 854:       5D               POP EBP
; 855:       C3               RET
NIL

где-то выше по треду было, я не буду исктать

SBCL операции с плавающей точкой, в ущерб общей стабильности рантайма

А можно как-нибудь посмотреть на этот «ущерб»? Ну что бы наглядно и понятно было в чём он заключается.

У меня LispWorks крутится 24/7 без остановок в продакшене без единых косяков.

А есть ли какие-нибудь мысли по поводу того, почему SBCL не сможет крутится 24/7?

А можно как-нибудь посмотреть на этот «ущерб»?

Конкретно я не скажу, но у меня была проблема с SBCL (когда я на нем хотел писать для работы 24/7), точнее с его реализацией мультипроцессинга. Он просто валился в дебаггер с критической ошибкой, после которой невозможно было продолжать, нужно было перегружать образ. Потом, по памяти SBCL довольно прожорлив. Поэтому я попросил попробовать LispWorks, который на удивление работал без выше описанных проблем. Так на нем и остался. К тому же мне нужны были вызовы из нелиспового треда в обратно в лисп — SBCL так не умеет. Плюс SBCL на винде тоже не ахти.

SBCL не сможет крутится 24/7?

В моих задачах не может.

Why?

Состояние экосистемы Common Lisp на 2015 год (комментарий)

А есть ли какие-нибудь мысли по поводу того, почему SBCL не сможет крутится 24/7?

Он может крутиться 24x7, но время жизни у каждой отдельной среды выполнения, судя по заявлениям со стороны представителей сообщества, ограничено 1-2 месяцами. При определённых обстоятельствах, SBCL, время от времени, падает. См. выше по трэду пример использования SBCL+CL-SQL+Hunchentoot в многопоточном режиме. Там время жизни составило 1 день :-)

Ну детский сад же. Дайте ссылку на конкретную бажину в SBCL, которая валит всё. Кто сказал, что это не код приложения валит? Кто сказал что в LW этот код не будет валиться?

cудя по заявлениям со стороны представителей сообщества, ограничено 1-2 месяцами.

Ну может ссылку что-ли, парочку хотя бы на «заявления»? Исключая пост monk-а. Я так понял никто не разобрался что там у monk-а происходит, но уже спешат обвинить в этом SBCL.

Там время жизни составило 1 день :-)

Угу. Ну то есть если я напишу какой-нибудь web сервис на LW и в каком нибудь кейсе поделю на 0 и этот код будет срабатывать раз в день, то это мне даст право заявить что LW нестабильное говно?

Кто сказал, что это не код приложения валит?

Код приложения валить не может, лол.

Если при этом LW будет падать (а оно не будет) - то да, конечно, даст.

Прикол в том, что если бы LW было говном, его не покупали бы за довольно большие деньги, а пользовались доступными открытыми реализациями. Поддержка у LW тоже отличная, присылали патчи с максимум в день задержкой на все мои проблемы. Было бы у меня много свободного времени наверное предпочел бы копаться в кишках SBCL. :)

Ну детский сад же. Дайте ссылку на конкретную бажину в SBCL, которая валит всё.

Детский сад - это твои рассуждения и запросы. Никто тебе такую ссылку не даст, просто потому что никто толком не знает, включая текущих разработчиков. Потому что если бы знали, то давно бы исправили. Набери grep FIXME -R * корневом каталоге SBCL и вперёд в тернистый путь через более чем тысячи возможных проблем, разбирайся. Удачи :-)

Кто сказал, что это не код приложения валит?

Это может быть, например, благодаря использованию хвалёных библиотек того самого японца, на которые ссылается автор оригинальной статьи. Он любит делать всякие (safety 0) дабы бить рекорды :-). Эти падения также могут быть из-за корявого FFI. Т.е., по идее, завалить среду выполнения может только низкоуровщина. Если же она падает при делении на 0, то она самое что ни на есть унылое говнище :-)

Кто сказал что в LW этот код не будет валиться?

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

Было бы у меня много свободного времени наверное предпочел бы копаться в кишках SBCL. :)

Никто не заставляет копаться в кишках SBCL. Если хочешь просто писать - просто пишешь и всё. Точно также как и в LW. Разговоры по поводу того, что в SBCL, якобы, ничего не работает, пока там что-нибудь не поправишь - сказки. Если и есть какие-то моменты, то они слишком специфичны и прикладного Lisp-ера не касаются никак.

Прикол в том, что если бы LW было говном, его не покупали бы за довольно большие деньги, а пользовались доступными открытыми реализациями.

Таки пользуются. SBCL в ходу по полной.

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

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

Эти падения также могут быть из-за корявого FFI.

Ну дай уже ссылку-то, где воспроизводится падение по причине «кривого» FFI.

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

Ну конечно. Если ты дёрнул сишную процедуру, а она всё распетушала, кто ж виноват. SBCL и «кривой» FFI что-ли?

Если же она падает при делении на 0, то она самое что ни на есть унылое говнище :-)

SBCL корректно сигнализирует ошибку. Мы пока только увидели, что LW валится при safety 0 на кривой декларации.

Набери grep FIXME -R *

И что, лол? Наличие комментария FIXME означает, что существуют фатальные баги делающие нестабильным runtime? Я не вижу ничего плохого в этом комменте, как признак того, что тут нужно что-то отрефакторить, например.

LispWorks идёт с довольно большой библиотекой

Этой действительно правда. Я полагаю, как раз из-за эксклюзивных батареек и используют LW. Единственная причина.

Он действительно кривой :-) Т.е., без кавычек :-) На вот, почитай и сдуй щёки :-) Calling Lisp functions from C is sometimes possible, but is extremely hackish and poorly supported as of SBCL 0.7.5.

SBCL корректно сигнализирует ошибку.

Мы все очень рады, что SBCL сигнализирует ошибку при делении на 0 :-) Гыгы.

Мы пока только увидели, что LW валится при safety 0 на кривой декларации.

Извини, я не понял что ты тут сказал :-)

И что, лол? Наличие комментария FIXME означает, что существуют фатальные баги делающие нестабильным runtime?

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

Я не вижу ничего плохого в этом комменте, как признак того, что тут нужно что-то отрефакторить, например.

Ну так отрефактори, вместо, как ты выразился, кудахтать :-) Удачи тебе в этом нелёгком труде за бесплатно :-)

Он действительно кривой :-) Т.е., без кавычек :-) На вот, почитай и сдуй щёки :-) Calling Lisp functions from C is sometimes possible, but is extremely hackish and poorly supported as of SBCL 0.7.5.

Так. Читаем.

Calling Lisp From C

Постой-ка, постой-ка! Ещё раз:

Calling Lisp functions from C...

Дёргать Lisp функции их C? Знаешь почему это «is extremely hackish», сопливый ты антон? Потому что это нафиг никому не нужно. Когда говорят о FFI, конечно же имеют ввиду С из Lisp. Есть конечно ecl, но мне кажется, он тоже никому не всрался. Встраивать Common Lisp - это то ещё непонятное извращение. Для этого есть более лёгкий известный Lisp и прочая специальная скриптота.

Ну так отрефактори, вместо, как ты выразился, кудахтать :-)

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

вместо, как ты выразился, кудахтать :-)

Ну я как бы на CL пишу достаточно много, в отличие от тебя. Ты же вообще не в теме. Просто кудахчешь.

Дёргать Lisp функции их C? Знаешь почему это «is extremely hackish», сопливый ты антон? Потому что это нафиг никому не нужно. Когда говорят о FFI, конечно же имеют ввиду С из Lisp.

Слив засчитан :-) Вызов Lisp кода из C - чрезвычайно важная возможность, без которой FFI - это не FFI, а жалкое подобие. Потому что огромное количество библиотек на C написаны с расчётом на применение обратных вызовов. Например, тот же libevent без этой возможности использовать нельзя. Но ты, судя по всему, никогда не использовал эти самые тонны C-библиотек, в которых вложены сотни тысяч человеко-часов. Значит опыта у тебя с гулькин нос. Поэтому сопливым выставил себя именно ты :-) Сдуй щеки, коли слил :-)

Есть конечно ecl, но мне кажется, он тоже никому не всрался. Встраивать Common Lisp - это то ещё непонятное извращение.

Пока такому чванливому существу что-то кажется, умные люди делают реально полезные вещи, как тот же ECL. :-)

Потому что огромное количество библиотек на C написаны с расчётом на применение обратных вызовов.

Конкретно callback-и реализованы, оттестированы и работают в cffi для всех используемых Lisp-ов. https://common-lisp.net/project/cffi/manual/html_node/defcallback.html Просто бери и используй.

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

Не отгадал. Как раз таки с cffi опыта работы у меня предостаточно.

Пока такому чванливому существу что-то кажется, умные люди делают реально полезные вещи, как тот же ECL. :-)

ecl никому не нужен. Это факт. Хорошая попытка сделать Common Lisp встраиваемым. Хорошая, но провальная.

Пока такому чванливому существу что-то кажется, умные люди делают реально полезные вещи, как тот же ECL. :-)

Ну давай, расскажи мне интересные истории. Сколько раз на дню встраиваешь CL? И будь бобр, подкинь ссылочки на свои исходники на ecl, пиздобол.

Конкретно callback-и реализованы, оттестированы и работают в cffi для всех используемых Lisp-ов. https://common-lisp.net/project/cffi/manual/html_node/defcallback.html Просто бери и используй.

Ты тут не заливай, а лучше погляди как CFFI реализует обратные вызовы для SBCL. Без слёз не взглянешь. :-) Тебе же в документации ясно дали понять, что, в частности, обратные вызовы из C - «extremely hackish and poorly supported as of SBCL 0.7.5». Так каким же образом CFFI может внушать доверие при использовании его с SBCL? У людей, не ищущих на задницу приключений, - никаким. Только у фонатиков. :-)

Не отгадал. Как раз таки с cffi опыта работы у меня предостаточно.

Отгадал, не отгадал, а твой взвяк про ненужность вызовов Lisp и C говорит об обратном. :-)

Ты тут не заливай, а лучше погляди как CFFI реализует обратные вызовы для SBCL. Без слёз не взглянешь. :-)

Поглядел: https://github.com/cffi/cffi/blob/master/src/cffi-sbcl.lisp#L326-L339. Даже не разу не всплакнул. Тебя смущает приватная alien-lambda в sb-alien? Меня не смущает. Какая разница, если код оттестирован и всё отлично работает. Поменяют в SBCL, изменят в cffi. Никаких проблем.

ни разу.

ecl никому не нужен. Это факт.

Мне нужен ECL. Это факт. :-)

Хорошая попытка сделать Common Lisp встраиваемым. Хорошая, но провальная.

Ха-ха, при всём уважении к Common Lisp, попытка сделать его нужным широкой публике провальная :-)

Так каким же образом CFFI может внушать доверие при использовании его с SBCL?

Да это у тебя, как у гадалки «внушает», «навеевает»... Может уж расскажешь о конкретных проблемах, питух? Если бы всё так было плохо, как ты пытаешься внушить себе и окружающим, SBCL не работал бы нормально с cl-async и wookie, например. Но всё иначе. SBCL прекрасно работает.

Тебя смущает приватная alien-lambda в sb-alien? Меня не смущает.

Меня смущает информация о «poorly supported as of SBCL 0.7.5» из первых рук. Меня предупредили, я кивнул гривой и намотал на ус, и сделал вывод, что мне не нужны какие-то хаки в системе, претендующей на надёжность эксплуатации.