Хамелеончеги: возвращение

[swizard]

Итого, погнали по следам предыдущего поста.

• На двухъядерном линуксе у dmitry_vk моя лисповая реализация оказалась быстрее жабьей почти на 40% ( пруф)
• У меня на ноуте (Core Duo T6600) бенчмарк отработал еще быстрее: 2.956s (напомню: на десктопе Core Quad Q6600, результат 7.4s)
• Задачу зааппрувили на shootout, она ожидаемо неплохо выступила на x86 Core Quad и

Comments

Имхо...

[anonymous]

...ты убиваешь саму суть LISP'а и shootout'а подобными лоулевел оптимизациями.
1) протекающая абстракция - разные алгоритмы для разного количества ядер;
2) жёсткая оптимизация программ под конкретные тестовые данные. Соль теста не в оптимизациях, а в тестировании _обычного_ кода на разных языках. Как несложно заметить, объём кода тоже учитывается и показывается на графиках - и не просто так.

Re: Имхо...

[anonymous]

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

Re: Имхо...

[swizard]

Нет такого понятия, как "обычный код". А на таком языке как CL, одно и то же можно запрограммировать десятком разных способов. Непонятно что и где сравнивать (библиотеки? рантайм? возможности языка?). А производительность -- это отличный и объективный критерий.

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

Это хорошо, правильно и объективно, и есть место для смекалки. Например, в regex-dna один из победителей -- это програма на си, использующая встроенный TCL :)

Re: Имхо...

[swizard]

> протекающая абстракция - разные алгоритмы для разного количества ядер;

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

А люди, испорченные джавой, этого не понимают :)

[quasi_loop]

http://github.com/nikodemus/sb-cpu-affinity это случаем не оно?

Там на шутауте для других программ используются #+sb-threads, #-sb-thread - нужно у оргов спросить, возможно что версия SBCL для одноядерных машин просто собрана без поддержки потоков? И, вроде, никто не запрещает для бенчмарка на разных архитектурах коммитить разные программы.

[swizard]

> http://github.com/nikodemus/sb-cpu-affinity это случаем не оно?

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

> Там на шутауте для других программ используются #+sb-threads, #-sb-thread - нужно у оргов спросить, возможно что версия SBCL для одноядерных машин просто собрана без поддержки потоков?

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

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

Ну да, я так в итоге и поступил :(

[quasi_loop]

ставится на 1 проц через taskset == sched_setaffinity(0x1)

кол-во ядер получить - sched_getaffinity(mask), и посчитать сколько бит маски установлено в 1. Будет правильно определять.

это системные вызовы, как из лифпа вызывать - не знаю.

[anonymous]

> Есть ли какой-нибудь универсальный способ определить однопроцессорность рантайма, помимо распарсивания /proc/cpuinfo в луниксе и sysctl в bsd?

Вообще есть посиксный sysconf(_SC_NPROCESSORS_ONLN) и гнутое расширение get_nprocs, делающее то же самое. Это не "из коробки", но при необходимости прикрутить можно.

[swizard]

Отлично, класс, спасибо большое =)

Только всплыл другой вопрос: как из sbcl узнать значение _SC_NPROCESSORS_ONLN? Не парсить же .h-файл? На фряхе эта константа равна 58, а на дебиане, например, 84 :(

А так работает отлично:

(sb-alien:alien-funcall (sb-alien:extern-alien "sysconf" (sb-alien:function sb-alien:long sb-alien:int)) 58)

[anonymous]

> Только всплыл другой вопрос: как из sbcl узнать значение _SC_NPROCESSORS_ONLN? Не парсить же .h-файл? На фряхе эта константа равна 58, а на дебиане, например, 84 :(

Для этой цели есть cffi-grovel, только я им пользоваться не умею :) Можно посмотреть как это с его помощью делается в том же iolib.

Внутри себя cffi-grovel генерирует C-код, который, "зная" требуемые числовые константы, генерит лисп-код, определяющий значения всех этих констант.

[swizard]

На что?

[swizard]

Прямо на sb-thread:make-thread? :)