LINUX.ORG.RU

почему положение Common Lisp в «Computer Benchmark Game» ухудшилось?

 ,


0

3

Раньше CL был в 2.5 раза медленее C, а теперь чуть ли не в 10. Что, команда SBCL в такой степени «преуспела» в оптимизации или это козни спонсоров сайта? Надо сказать, я этому сайту перестал верить после того, как они выкинули LuaJit, да и вообще много жалоб на него. Но не помешало бы исключить вариант с реальным ухудшением производительности SBCL.

★★★★★

Последнее исправление: den73 (всего исправлений: 1)

Раньше CL был в 2.5 раза медленее C, а теперь чуть ли не в 10.

В чём?

panzerito
()

Раньше CL был в 2.5 раза медленее C, а теперь чуть ли не в 10

Потому что в Си стали лепить интринсики. Неудивительно, что CL с generic-+ и generic-* сливает Си с _mm256_fmadd_pd.

no-such-file ★★★★★
()

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

anonymous
()

Похоже на то, что я раньше смотрел на 1-ядерные 32 разряда, а теперь на 4-ядерные 64. На 4 ядрах и 64 разрядах SBCL выступает хуже. Некоторые программы вообще не распараллелены.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Однако новость всё равно неприятна.

Кому как. Мне вот приятна.

anonymous
()

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

noconformism
()
Ответ на: комментарий от no-such-file

generic+ ещё и различает между собой все виды чисел. Но ничто не мешает объявить типы, а хорошему компилятору лиспа ничто не мешает убрать здесь call (если я правильно понял смысл intrinsic-ов). Также я помню, что fixnum меньше разрядности платформы из-за тега типа. Здесь тоже SBCL раньше перескакивает на bignum - эта проблема была и раньше, хотя может SBCL-щики что-то допилили на эту тему.

В некоторых случаях причина всё же в отсутствии параллельности.

Именно: reverse-complement, k-nucleotide, fasta в лиспе загружают только одно ядро, а binary-trees грузит только два ядра.

den73 ★★★★★
() автор топика

По той же причине, почему rust сейчас самый быстрый - людям влом писать бенчи. Выигрывает тот, кто сильнее вложился.

RazrFalcon ★★★★★
()
Ответ на: комментарий от den73

Интерсинки не особо влияют. В коде на rust их нет, ибо в rust ещё не завезли их в stable. Поэтому вся надежда только на автовекторизацию.

RazrFalcon ★★★★★
()
Ответ на: комментарий от den73

Но ничто не мешает объявить типы

Объявить не мешает, но если посмотреть лог работы тестов, то видно, что во многих случаях sbcl кидает ворнинги где шлёт объявляльщиков лесом. Может можно это побороть, только всем начхать.

no-such-file ★★★★★
()

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

Также в реальной жизни всё это хозяйство абсолютно нормально работало на атоме с 2 гигами памяти 8 лет назад. Быстрее не надо было.

Плюс компилятор у SBCL реально застрял в 90-х. SSA ведь до сих пор нет, да?

Но всё это не имеет значения, т.к. программисты на байтоперекладывающих языках совершенно не стесняясь фигачат маллоки в fast path, и там всё тормозит так, как никакому сборщику мусора не снилось.

mv ★★★★★
()

Что, команда SBCL в такой степени «преуспела» в оптимизации … ?

А его разве вообще развивают, кроме минорных багфиксов?

Virtuos86 ★★★★★
()

А там есть численные вычисления? Если да, то в некоторых случаях происходит боксинг, и тогда нагрузка на сборщик мусора. При боксинге потеря в производительности в раз 6 вполне нормальное дело

dave ★★★★★
()
Ответ на: комментарий от Virtuos86

Ну, если SBCL уже не развивают, то какой компилятор лиспа тогда вообще развивают?

rupert ★★★★★
()
Ответ на: комментарий от dave

Да, их там много. Нагрузка на сборщик мусора от многих вещей, в т.ч. от хеш-таблиц. И кстати, я понял, что интринсики - это define-compiler-macro - сишники освоили ещё одну фишку Common Lisp.

den73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.