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

То есть, если я в SBCL поймал сигнал (через handler-bind), то я не могу программно посмотреть обратную трассировку, позицию ошибки в файле и т.д

Не знаю, насколько в полной мере и для любой платформы, но вообще стек, позицию ошибки в файле ты посмотреть можешь, с использованием SWANK. Просто надо написать для этого клиент SWANK на CL и такие клиенты даже есть (в какой-то степени готовности).

Блин, вот эту бы энергию в мирных целях. Чем меряться бенчмарками, лучше бы перенесли мой дебаггер с лиспворкса на SBCL и допилили. Был бы настоящий нативный пошаговый дебаггер. Код здесь:

https://bitbucket.org/budden/budden-tools/src/default/experiments/hack-debugg...

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

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

Концепт, к-рый я написал для лиспворкса, в этом отношении уникален. Перейти в пошаговый режим можно прямо из (break), без перезапуска фрейма. Но его надо ещё допиливать - он пока понимает только именованные функции, а лямбды не понимает. Всё, что сделано в нём, сделано в закрытой системе методом тыка. Перенос на SBCL должен быть простым для того, кто сможет разобраться.

ну в 5 раз тоже не фонтан

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

А можно все-таки перечислить?

в SBCL на данный момент нет нативного пошагового дебаггера

sb-impl:enable-stepping не то?

но вообще стек, позицию ошибки в файле ты посмотреть можешь, с использованием SWANK

Посмотрел для SBCL. Обилие кода через :: поражает. Там половину компилятора наружу вытаскивают, чтобы обеспечить нужный интерфейс.

без оптимизации

LispWorks - 11.184
SBCL - 0.350

с оптимизацией

LispWorks - 11.012
SBCL - 0.339

ммммм... эээээ.... ????? прям, нет слов. чё-т тут не то! может надо с лупой искать разницу?

Сделал третий вариант: с (declaim (optimize (speed 0) (safety 3)))

* (time (main 1000))
1.274224148
Evaluation took:
  5.097 seconds of real time
  5.084000 seconds of total run time (5.028000 user, 0.056000 system)
  [ Run times consist of 0.348 seconds GC time, and 4.736 seconds non-GC time. ]
  99.74% CPU
  9,153,539,340 processor cycles
  4,480,164,160 bytes consed

CL-USER 1 > (time (main 1000))
Timing the evaluation of (MAIN 1000)
1.274224148

User time    =       11.296
System time  =        0.044
Elapsed time =       11.269
Allocation   = 3840327680 bytes
0 Page faults

Зарегистрируйся.

Не знаю. Думаю, что нет. Возможно, интерпретатор задействован. Посмотрю - отпишусь.

Посмотрел для SBCL. Обилие кода через :: поражает.

Смысл в том, что SWANK есть для многих платформ, т.е. это слой переносимости поверх кишок. Наверное, наилучший в природе.

ну в 5 раз тоже не фонтан

Фигня все эти тесты. Если бы нужна была серьезная числодробильня, я бы обертку написал к фортрановой/сишной библиотеке. А для более простых случаев — достаточно того, что есть.

http://lispnik.livejournal.com/262800.html

исчо чудесатее :)

возникают подозрения

1. ЛВ персональный ничего не оптимизирует

2. СБЦЛ малая разница между простым и оптимизированным вариантом - где то не хватает деклараций, или они не срабатывают должным образом

Конечно фигня. Сравнивать надо реальные системы. Например, про elPrep доподлинно известно: «Please use the LispWorks version when running and reporting benchmarks, since the SBCL version is in general slower.» :-)

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

Например, про elPrep доподлинно известно: «Please use the LispWorks version when running and reporting benchmarks, since the SBCL version is in general slower.»

Возможно, лиспворкс - интерпретатор. Тогда результаты вполне понятны - в 99% случаев будет огромный проигрыш в производительности и в 1% (когда используются как раз фичи интерпретатора, возможно это и есть случай elPrep) начинает выигрывать.

Возможно, лиспворкс - интерпретатор.

Не позорься. LispWorks - компилятор.

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

Да ладно тебе, Антон, к терминам придираться.

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

с чего ты взял, собственно?

Человек утверждает

Возможно

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

с чего ты взял, собственно?

Лентяй и балабол, специально для тебя LispWorks Compiler

Откуда ты знаешь что он не компилирует в эквивалентный интерпретатору control-flow?

Откуда ты знаешь что он не компилирует в эквивалентный интерпретатору control-flow?

Забавно видеть как на всяких форумах подростки-прогрОмисты составляют предложения из слов на английском и русском языках, вставляя вместо русских «поток управления» взвяки типа «control-flow», но, при этом, не знать того самого английского языка, потому что даже первое предложение: «The compiler translates Lisp forms and source files into binary code for the host machine.», прочитать не в силах :-)

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

в SBCL на данный момент нет нативного пошагового дебаггера

sb-impl:enable-stepping не то?

Да, мил человек, наврал я. В SBCL очень похоже, что уже есть то, что надо. Значит, только в лиспворксе с этим всё плохо. И кстати, проблема не в инструментировании как таковом, а в сценарии использования и в том, как именно делается инструментирование. В лиспворксе инструментирование делается для исходного текста, который для пошагового прохода нужно _пересобрать_под_интерпретатор_ . Естественно, отлаживаешь ты при этом уже не тот код, который у тебя обычно работает, плюс замедление. Плюс невозможно из break продолжить работу в пошаговом режиме - нужен перезапуск кадра стека.

Ну и славненько!

но, при этом, не знать того самого английского языка, потому что даже первое предложение: «The compiler translates Lisp forms and source files into binary code for the host machine.», прочитать не в силах :-)

Ну так и с чего ты взял, что control-flow этого скомпиленного кода не соответствует интерпретатору?

Ну так и с чего ты взял, что control-flow этого скомпиленного кода не соответствует интерпретатору?

Теперь понятно. Слив засчитан. Вместо того, чтобы признать, что слажался насчёт «LispWorks - это интерпретатор» мы видим продолжение чванства и попытку извернуться, скосив под дурачка, мол «control-flow скомпиленного кода быть может соответствует интерпретатору». С тобой всё ясно, можешь не напрягаться. :-)

Вместо того, чтобы признать, что слажался насчёт «LispWorks - это интерпретатор»

«The compiler translates Lisp forms and source files into binary code for the host machine.» не всегда означает, что это реальная компиляция. Это может быть компиляция кода типа

#include "lisp.h"
char *prog = "(defun ...) (defun ...) ...";

int main()
{
    eval(prog);
}

Формально, компиляция такой программы даст «binary code for the host machine».

Формально, компиляция такой программы даст «binary code for the host machine».

Ты упоролся уже со своим любимым Рэкетом уже настолько, что перестал понимать английский язык. Тебе сказано прямым текстом «source files into binary code for the host machine». Вторым предложением идёт: «A compiled Lisp function, for instance, is a sequence of machine instructions that directly execute the actions the evaluator would perform in interpreting an application of the original source lambda expression.» Ты понимаешь что такое «sequence of machine instructions that directly execute the actions the evaluator»? Такой умный дядя, а читать не умеешь. Давайдосвидания. :-)

Формально, компиляция такой программы

Фактически, лиспворкс - это нормальный компилятор. Это легко доказывается просмотром disassemble. Постыдись, покайся и можно продолжить дальше :)

Это легко доказывается просмотром disassemble.

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

Ты понимаешь что такое «sequence of machine instructions that directly execute the actions the evaluator»?

Вот если ты этот код компилятором сишки компильнешь:

#include "lisp.h"
char *prog = "(defun ...) (defun ...) ...";

int main()
{
    eval(prog);
}

у тебя получится как раз sequence of machine instructions that directly execute the actions the evaluator

у тебя получится как раз sequence of machine instructions that directly execute the actions the evaluator

Продолжаешь сливать, уцепившись теперь за гипотетическую генерацию бредового C-кода? Ну-ну :-) Потому что только в бреду может прийти в голову реализовывать JIT-компиляцию Lisp-кода на C, чтобы потом из Lisp-кода генерировать код C, и вызывать eval(), реализующий JIT-компиляцию. Бугага :-) С огромной долей вероятности, разработчики LispWorks - здравомыслящие практики, а не изворотливые задроты-теоретики, и их компилятор, написанный на Common Lisp без всяких C, генерирует как раз последовательность машинных инструкций (а не бредовый C-код), которые напрямую исполняют действия исполнителя, как, собственно, и сказано «sequence of machine instructions that directly execute the actions the evaluator» :-)

Продолжаешь сливать, уцепившись теперь за гипотетическую генерацию бредового C-кода?

Причем тут си-код? У тебя реально проблемы с чтением. Речь не о си-коде, речь о том, что если вышеприведенную портянку скомпилировать в машкод - то она будет формально sequence of machine instructions that directly execute the actions the evaluator, но при этом ее исполнение ничем не будет отличаться от интерпретации. Тебе просто привели пример того, что компиляции в машкод не означает отсутствия интерпретации.

Фактически, лиспворкс - это нормальный компилятор.

С этим утверждением не спорю.

Спорю с тем, что «translates Lisp forms and source files into binary code for the host machine» это доказывает. По крайней мере «компилятор» Clipper'а делал ровно то, что я показал (исходники+интерпретатор были зашиты в бинарник, но процесс создания этого бинарника разработчики Clipper'а тоже называли «компиляцией»).

Речь не о си-коде, речь о том, что если вышеприведенную портянку скомпилировать в машкод - то она будет формально sequence of machine instructions that directly execute the actions the evaluator

Проблемы с чтением у тебя, а не у меня. Если вышеприведённую портянку скомпилировать в машкод, то, скорее всего, вызов eval() будет означать вызов тормозного интерпретатора, т.е. «sequence of machine instructions that directly execute the evaluator», а не «sequence of machine instructions that directly execute the actions the evaluator».

, но при этом ее исполнение ничем не будет отличаться от интерпретации.

С т.з. логики выполнения - конечно не будет. Об этом же сказано в документации «directly execute the actions the evaluator would perform in interpreting an application of the original source lambda expression.» Это применимо к абсолютно любому исходному тексту на абсолютно любом языке программирования.

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

Бред сивой кобылы. Компиляция в машинный код означает то, что этот код будет выполняться непосредственно процессором. Ты хоть бы Википедию почитай, раз ничего другого не читал.

Интерпрета́ция — пооператорный (покомандный, построчный) анализ, обработка и тут же выполнение исходной программы или запроса (в отличие от компиляции, при которой программа транслируется без её выполнения)

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

Так о том и речь, лол. Программа может быть скомпилирована в машкод и быть sequence of machine instructions that directly execute the actions the evaluator, но при этом представлять вызов тормозного интерпретатора.

Бред сивой кобылы. Компиляция в машинный код означает то, что этот код будет выполняться непосредственно процессором.

Любой код выполняется непосредственно процессором, дурачок.

Короче вместо того чтобы шланговать лучше привел бы машкод в который компилируется какой-нибудь луп в SBCL и в лиспворксе..

Программа может быть скомпилирована в машкод и быть sequence of machine instructions that directly execute the actions the evaluator, но при этом представлять вызов тормозного интерпретатора.

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

Любой код выполняется непосредственно процессором, дурачок.

Понятно, понятно. В твоём колхозе так оно и есть :-)

Понятно, понятно. В твоём колхозе так оно и есть :-)

может сможешь привести пример где оно НЕ так?

А в LispWorks в машинный код компилируется сама программа на Common Lisp, т.е. actions. :-)

Пруфы можно?

Пруфы можно?

Собственно, пояснение, почему нужны пруфы - программы исполняемые лиспворксом ОЧЕНЬ СИЛЬНО тормозят. Настолько сильно, что некоторые интерпретаторы - и то быстрее. Логичным объяснением тормозов было бы то, что у них там не слишком оптимизированный интерпретатор (потому что представить себе компилятор, который тормозит НАСТОЛЬКО сильно - довольно сложно, достаточно посмотреть тот же шутаут - компилируемых языков с производительностью лиспворкса там просто нет, медленнее только эрланг, пехепе, руби, питон).

может сможешь привести пример где оно НЕ так?

А, понятно. В бурсе не научили в чём разница между интерпретатором и компилятором, зато научили позориться. :-) Слишком ты «толстый» и неискренний. Поэтому, кто же поверит в этот бред, кроме тебя самого? :-) Не удалась твоя попытка подменить понятия, впихнув вызов интерпретатора в жалкий C-код, а потом заявлять, что после компиляции в машинный код этого жалкого C-кода будет означать то, что формально код будет выполняться процессором. Особо упоротые колхозники полагают, что нет разницы между выполнением исходного кода программы скомпилированным в машинный код интерпретатором, и выполнением скомпилированного в машинных код исходного кода программы, потому что и в том, и в другом случае, вычисления выполняются процессором :-) Слив засчитан. :-)

Пруфы можно?

Если бы тебе нужны были доказательства, то давно бы уже нашёл из документации к компилятору LispWorks. Хотя как ты нашёл бы, если с чтением у тебя проблемы? :-) Для тех же, кто умеет читать a native-code compiler and an interpreter for an extended ANSI Common Lisp, The reality is that when all datatypes are appropriately declared, a typical commercial Lisp compiler produces native machine code that is comparable in speed with other languages., The compiler is in fact much more complex than this model might suggest. Machine specific optimizations, for example, can be included in any of the passes. :-)

То есть не можешь. Окей.

Если бы тебе нужны были доказательства, то давно бы уже нашёл из документации к компилятору LispWorks.

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

The reality is that when all datatypes are appropriately declared, a typical commercial Lisp compiler produces native machine code that is comparable in speed with other languages

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

Узбагойся уже, а? Вот тебе ассемблер для LispWorks 32 bit для кода, который я публиковал выше:

CL-USER> (disassemble 'eval-A-times-u)
200CA27A:
       0:      55               push  ebp
       1:      89E5             move  ebp, esp
       3:      83EC10           sub   esp, 10
       6:      6886140000       push  1486
      11:      50               push  eax
      12:      50               push  eax
      13:      50               push  eax
      14:      50               push  eax
      15:      50               push  eax
      16:      50               push  eax
      17:      50               push  eax
      18:      50               push  eax
      19:      50               push  eax
      20:      50               push  eax
      21:      50               push  eax
      22:      50               push  eax
      23:      50               push  eax
      24:      50               push  eax
      25:      50               push  eax
      26:      50               push  eax
      27:      50               push  eax
      28:      50               push  eax
      29:      50               push  eax
      30:      50               push  eax
      31:      8B7508           move  esi, [ebp+8]
      34:      8975E0           move  [ebp-20], esi
      37:      8B75E0           move  esi, [ebp-20]
      40:      3B759C           cmp   esi, [ebp-64]
      43:      7C0A             jl    L2
L1:   45:      B856000000       move  eax, 56
      50:      FD               std   
      51:      C9               leave 
      52:      C21000           ret   10
L2:   55:      89E6             move  esi, esp
      57:      81CEFCFF0F00     or    esi, FFFFC
      63:      3966D0           cmp   [esi-30], esp
      66:      0F8398000000     jae   L6
L3:   72:      8B75E0           move  esi, [ebp-20]
      75:      8975A0           move  [ebp-60], esi
      78:      C745E800000000   move  [ebp-18], 0
      85:      DD05C0A40C20     fldl  [200CA4C0]       ; 0.0D0
      91:      DD5DF8           fstpl [ebp-8]
      94:      8B75E8           move  esi, [ebp-18]
      97:      3B7510           cmp   esi, [ebp+10]
     100:      0F8C8C000000     jl    L8
L4:  106:      660F1275F8       movlpd xmm6, [ebp-8]
     111:      83EC0C           sub   esp, C
     114:      C70424860C0000   move  [esp], C86
     121:      660F13742404     movlpd [esp+4], xmm6
     127:      B501             moveb ch, 1
     129:      FF1504731320     call  [20137304]       ; SYSTEM::RAW-FAST-BOX-DOUBLE
     135:      8945A8           move  [ebp-58], eax
     138:      8B750C           move  esi, [ebp+C]
     141:      8B5EFD           move  ebx, [esi-3]
     144:      89DE             move  esi, ebx
     146:      81E6E0000000     and   esi, E0
     152:      83FE60           cmp   esi, 60
     155:      754E             jne   L7
     157:      8B750C           move  esi, [ebp+C]
     160:      8975B0           move  [ebp-50], esi
L5:  163:      8B7DA8           move  edi, [ebp-58]
     166:      660F127705       movlpd xmm6, [edi+5]
     171:      8B7DA0           move  edi, [ebp-60]
     174:      C1E701           shl   edi, 1
     177:      8B75B0           move  esi, [ebp-50]
     180:      660F13743E05     movlpd [esi+5+edi], xmm6
     186:      8B75E0           move  esi, [ebp-20]
     189:      8975AC           move  [ebp-54], esi
     192:      8B75AC           move  esi, [ebp-54]
     195:      83C604           add   esi, 4
     198:      8975A4           move  [ebp-5C], esi
     201:      8B7DA4           move  edi, [ebp-5C]
     204:      897DE0           move  [ebp-20], edi
     207:      8B75E0           move  esi, [ebp-20]
     210:      3B759C           cmp   esi, [ebp-64]
     213:      0F8D52FFFFFF     jge   L1
     219:      E957FFFFFF       jmp   L2
L6:  224:      FF15BC081620     call  [201608BC]       ; SYSTEM::CHECK-FOR-INTERRUPTS
     230:      E95DFFFFFF       jmp   L3
L7:  235:      8B750C           move  esi, [ebp+C]
     238:      8B7605           move  esi, [esi+5]
     241:      8975B0           move  [ebp-50], esi
     244:      EBAD             jmp   L5
L8:  246:      89E6             move  esi, esp
     248:      81CEFCFF0F00     or    esi, FFFFC
     254:      3966D0           cmp   [esi-30], esp
     257:      0F83EC000000     jae   L11
L9:  263:      8B75E8           move  esi, [ebp-18]
     266:      8975D4           move  [ebp-2C], esi
     269:      8B7514           move  esi, [ebp+14]
     272:      8B5EFD           move  ebx, [esi-3]
     275:      89DE             move  esi, ebx
     277:      81E6E0000000     and   esi, E0
     283:      83FE60           cmp   esi, 60
     286:      0F85DA000000     jne   L12
     292:      8B7D14           move  edi, [ebp+14]
L10:  295:     8B5DD4           move  ebx, [ebp-2C]
     298:      C1E301           shl   ebx, 1
     301:      DD441F05         fldl  [edi+5+ebx]
     305:      DD5DF0           fstpl [ebp-10]
     308:      8B75E0           move  esi, [ebp-20]
     311:      8975C8           move  [ebp-38], esi
     314:      8B75E8           move  esi, [ebp-18]
     317:      8975B8           move  [ebp-48], esi
     320:      8B75C8           move  esi, [ebp-38]
     323:      0375B8           add   esi, [ebp-48]
     326:      8975E4           move  [ebp-1C], esi
     329:      8B75E4           move  esi, [ebp-1C]
     332:      83C604           add   esi, 4
     335:      8975B4           move  [ebp-4C], esi
     338:      8B7DB4           move  edi, [ebp-4C]
     341:      C1FF02           sar   edi, 2
     344:      89FE             move  esi, edi
     346:      0FAF75E4         imul  esi, [ebp-1C]
     350:      8975D8           move  [ebp-28], esi
     353:      8B7DD8           move  edi, [ebp-28]
     356:      C1FF01           sar   edi, 1
     359:      BEFCFFFFFF       move  esi, -4
     364:      23F7             and   esi, edi
     366:      8975CC           move  [ebp-34], esi
     369:      8B75E0           move  esi, [ebp-20]
     372:      8975DC           move  [ebp-24], esi
     375:      8B75DC           move  esi, [ebp-24]
     378:      83C604           add   esi, 4
     381:      8975C4           move  [ebp-3C], esi
     384:      8B75CC           move  esi, [ebp-34]
     387:      0375C4           add   esi, [ebp-3C]
     390:      8975C0           move  [ebp-40], esi
     393:      8B7DC0           move  edi, [ebp-40]
     396:      C1FF02           sar   edi, 2
     399:      F20F2AF7         cvtsi2sd xmm6, edi
     403:      6A04             pushb 4
     405:      83EC0C           sub   esp, C
     408:      C70424860C0000   move  [esp], C86
     415:      660F13742404     movlpd [esp+4], xmm6
     421:      B501             moveb ch, 1
     423:      FF1504731320     call  [20137304]       ; SYSTEM::RAW-FAST-BOX-DOUBLE
     429:      B502             moveb ch, 2
     431:      FF15449E1820     call  [20189E44]       ; SYSTEM::/2
     437:      660F126805       movlpd xmm5, [eax+5]
     442:      F20F596DF0       mulsd xmm5, [ebp-10]
     447:      660F1275F8       movlpd xmm6, [ebp-8]
     452:      F20F58F5         addsd xmm6, xmm5
     456:      660F1375F8       movlpd [ebp-8], xmm6
     461:      8B75E8           move  esi, [ebp-18]
     464:      8975D0           move  [ebp-30], esi
     467:      8B75D0           move  esi, [ebp-30]
     470:      83C604           add   esi, 4
     473:      8975BC           move  [ebp-44], esi
     476:      8B7DBC           move  edi, [ebp-44]
     479:      897DE8           move  [ebp-18], edi
     482:      8B75E8           move  esi, [ebp-18]
     485:      3B7510           cmp   esi, [ebp+10]
     488:      0F8D7CFEFFFF     jge   L4
     494:      E903FFFFFF       jmp   L8
L11:  499:     FF15BC081620     call  [201608BC]       ; SYSTEM::CHECK-FOR-INTERRUPTS
     505:      E909FFFFFF       jmp   L9
L12:  510:     8B7514           move  esi, [ebp+14]
     513:      8B7E05           move  edi, [esi+5]
     516:      E91EFFFFFF       jmp   L10
     521:      90               nop   
NIL

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

Популярные объяснения выпускников бурсы никак не отменяют возможность компиляции в LispWorks. :-)