Математика в SBCL: бенчмарк

После проведения некоторых оптимизаций кода sb-math решил провести тест производительности функций умножения матрицы на матрицу и матрицы на вектор. Для сравнения взял GSLL и простым сишным кодом. Таким образом, сравнивался чистый вызов функций cblas_sgemv и cblas_sgemm из библиотеки GSL CBLAS и два интерфейса к ним.

Код бенчмарков тут:
* bench.lisp - код для gsll и sb-math, а также вызова скомпилированного сишного кода, обработки результатов и отрисовки графиков.
* gemm_bench.c, gemv_bench.c - сам сишный код
* там же графики зависимостей (png)

Итак, умножение матрицы на вектор. Для упрощения умножалась квадратная матрица NxN на вектор длиной N.

На графике показана зависимость времени единичного вычисления от размености N. на больших размерностях GSLL дает существенное отставание. Причина этого неожиданного факта не совсем понятна. Более того, полгода назад на похожем тесте для больших размерностей GSLL шла рядом с сишным кодом, а вот для малых давала из рук вон плохие результаты. Вероятно, это связано с тем, что автор GSLL (Liam Healy) недавно перекроил все матричное api для нее.

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

Тут не очень интересно, поэтому чуть увеличим размерность:

Так все более-менее ясно.

Теперь умножение матрицы на матрицу. Простоты ради все матрицы квадратные, с одинаковой размерностью.

Начиная с N=200 GSLL резко уходит уходит в отрыв, sb-math продолжает преследовать gcc :)

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

Подводя итог, можно сказать, что sb-math смотрится достаточно неплохо даже на  фоне gcc, хотя на матрицах малых размерностей относительное отставание от сишного кода велико. Но там еще есть возможности для оптимизации, и это вселяет надежду :)

GSLL ведет себя достаточно странно, причем это поведение стабильно воспроизводится. Тем не менее, с новым foreign array api там все стало существенно лучше.

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

Ну и это самое. В отличие от GSLL sb-math не привязана к какой-то одной библиотеке CBLAS. Подключение ее к функциям из ATLAS дает существенный рост производительности по сравнению с GSLL. Тем не менее, я не стал включать в бенчмарк тесты на атласе, потому что целью было посмотреть оверхед на вызов функций. Да и не совсем честно это, что sb-math будет обгонять сишный код.

Ну вы поняли :)

UPD: В связи с глобальной переписью кода этот бенчмарк стал неактуальным. Оверхед на малых размерностях стал еще меньше.

Идеологически правильный оконный менеджер

Присоединился к недавнему флешмобу и заменил свой оконный менеджер для X11 на StumpWM. Настроил управление в духе fluxbox, конфиг на github, если кому вдруг интересно.
StumpWM запускается в виде образа sbcl, поэтому для работы в sbcl нет смысла запускать новый процесс, если можно приконнектиться к старому.

В моем случае окончание файла xinitrc выглядит так:

stumpwm &
exec emacs

В конфиге stumpwm запускается swank, а в емаксе, в свою очередь, выполняется
(slime-connect "127.0.0.1" 4005 'utf-8-unix)

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

Но пост не об этом, на самом деле, а об одном забавном моменте.

StumpWM имеет тенденцию иногда падать, особенно, когда sbcl, в котором он работает, кто-то загрузил на 100%. И вот, значит, он упал, окошки не переключаются, хоткеи не работают и т.д., но X-сервер исправно пашет, и последнее активное окно по-прежнему доступно. Перезапускать иксы не хочется, особенно, когда открыто много окон.

Решение найдено!

Alt-Ctrl-F2     # переключаемся в консоль

killall stumpwm # убиваем повисший процесс

stumpwm         # запускаем новый

Alt-Ctrl-F7     # возвращаемся в иксы

Все окна целы, несохраненные данные не потеряны. Не знаю, может быть, это вполне естественно, но меня порадовало :)