Life

Над портом SBCL на win32 сейчас работает Антон Коваленко ( akovalenko ).

Вот здесь можно посмотреть подробности, узнать текущий статус форка, и, естественно, скачать новые версии, в т.ч. в виде msi-инсталлятора: http://www.siftsoft.com/inprogress/forknews.html

Обсуждение тут: http://akovalenko.livejournal.com/35889.html

Я настоятельно рекомендую использовать именно эту версию SBCL при работе под Windows - там добалена многопоточность(спасибо dmitry_vk), добавлена поддержка stdcall-коллбэков, коллбэков в сторонние треды(грубо говоря, можно, например, лисповые коллбэки поставлять в CreateThread), пофиксены многие баги в подсистеме ввода/вывода, и так далее - ну по первой ссылке можно посмотреть подробности.

Для работы stdcall-коллбэков в CFFI необходимо применить мой патч, вот он:
http://cloud.github.com/downloads/Lovesan/virgil/cffi-sbcl-stdcall.patch

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

Не перестают меня удивлять и заявления о том, что де, раз в C++ есть boost, с его shared_ptr и прочим, то проблема сборки мусора для C++ фактически решена.

Ладно уж, не будем о том, что счетчики ссылок неспособны разрешить циклические зависимости, просто сравним ту самую производительность, за которую писатели на C++ так трясутся.

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

Заключается он в следующем:
Создаем вектор на 'length' элементов, заполняем его указателями на структуры, подобные лисповым cons-ячейкам, и 'n' раз прогоняем цикл, в котором создаем копию этого вектора, а старый удаляем(элементы при этом мы не копируем, а копируем только указатели на них). Указатели, в C++, естественно, используем "умные".
В качестве противника C++, то есть в качестве языка, в реализациях которого присутствует нормальный GC, я взял Common Lisp, если конкретно - SBCL.

( Read more... )

Я тут подумал - неплохо бы приделать к 32битному SBCL SSE.

Но, тут все не так просто.
( Read more... )

http://dl.dropbox.com/u/5521262/sbcl-1.0.38-x86-windows-binary.msi

ну и тут обновилось:
http://github.com/Lovesan/sbcl-win32-binaries

свежие бинарники sbcl под винду я буду выкладывать вот тут:
http://github.com/Lovesan/sbcl-win32-binaries

там две ветки; "dev" - "промежуточные" релизы

(по ходу дела разбираюсь с git и github, так что если что вдруг криво - сильно не пинать)

upd.
вот еще ссылка, на всякий случай:
http://dl.dropbox.com/u/5521262/sbcl-1.0.36-x86-windows-binary.msi

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

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

Finished running tests.
Status:
 Failure:             interface.pure.lisp / WITH-TIMEOUT-FORMS
 Failure:             stream.pure.lisp / (STREAM LISTEN-VS-SELECT)
 Unhandled error      alien.impure.lisp
 Unhandled error      clos-interrupts.impure.lisp
 Unhandled error      deadline.impure.lisp
 Expected failure:    debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
 Failure:             debug.impure.lisp / (THROW NO-SUCH-TAG)
 Invalid exit status: exhaust.impure.lisp
 Failure:             external-format.impure.lisp / (CHARACTER-DECODE-LARGE
                                                     ATTEMPT-RESYNC)
 Unhandled error      foreign-stack-alignment.impure.lisp
 Unhandled error      load.impure.lisp
 Expected failure:    packages.impure.lisp / USE-PACKAGE-CONFLICT-SET
 Expected failure:    packages.impure.lisp / IMPORT-SINGLE-CONFLICT
 Unhandled error      pathnames.impure.lisp
 Unhandled error      print.impure.lisp
 Failure:             run-program.impure.lisp / RUN-PROGRAM-CAT-1
 Failure:             signals.impure.lisp / (ASYNC-UNWIND SPECIALS)
 Failure:             signals.impure.lisp / (SIGNAL ERRNO)
 Unhandled error      stream.impure.lisp
 Unhandled error      swap-lispobjs.impure.lisp
 Unhandled error      threads.impure.lisp
 Failure:             timer.impure.lisp / (TIMER DEREFERRABLES-BLOCKED)
                                          ;btw, тест DEREFERRABLES-UNBLOCKED
                                          ;просто виснет, приходится его закомменчивать
 Failure:             timer.impure.lisp / (TIMER RELATIVE)
 Failure:             timer.impure.lisp / (TIMER ABSOLUTE)
 Failure:             timer.impure.lisp / (TIMER REPEAT-AND-UNSCHEDULE)
 Failure:             timer.impure.lisp / (TIMER RESCHEDULE)
 Failure:             timer.impure.lisp / (TIMER STRESS)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT TIMEOUT)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT NESTED-TIMEOUT-SMALLER)
 Failure:             timer.impure.lisp / (WITH-TIMEOUT NESTED-TIMEOUT-BIGGER)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              OPTIONAL-SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RESTART-FRAME
                                                              NORMAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              OPTIONAL-SPECIAL)
 Failure:             unwind-to-frame-and-call.impure.lisp / (RETURN-FROM-FRAME
                                                              NORMAL)
 Unhandled error      unwind-to-frame-and-call.impure.lisp
test failed, expected 104 return code, got 1

Набор ошибок в тестах уже которую версию примерно одинаковый. На линуксе же, судя по всему, тесты проходятся полностью.
Ну и, плюс, испокон веков не компилируется contrib модуль sb-simple-streams.

Плюс, еще вот тут указаны противные windows-специфичные баги:
https://bugs.launchpad.net/sbcl/+bugs?field.tag=os-windows
Баг с READ-CHAR-NO-HANG, в частности, мешает корректной работе SLIME.

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

Это довольно грустно, потому что SBCL - лучший открытый компилятор CL, а Windows как платформа - занимает огромную часть рынка, игнорировать ее нельзя.