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

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

В чём?

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

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

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

Просто разоблачили подтасовки лисперов http://lispnik.livejournal.com/262800.html?thread=908176#t908176

Да и усилия по автовекторизации не пропали даром.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Развивают.

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