SBCL уделывает C++(и шланг, и G++) по производительности

Zig отъел всего 100кБ :)

Там написаны разные программы и алгоритмы.

На этом тред можно закончить.

sbcl 2.1.8
peak-mem 42.3MB

Это позор.

Вы предлагаете здесь переключиться на обсуждение теоретической нагруженности наблюдений? Какую форму обсудим сперва: семантическую или воспроятия?

Заголовок неверен, вы вообще способны понять, что один тест не говорить ни о чём.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/sbcl-gpp.html

Назовите теперь хоть одну причину использовать плюсы вообще?

В шараге другому не учили

Это накладняк на lisp os. В прекрасном виндоусе будущего его не будет.

Именно. Даже раст есть гораздо меньше.

Ты с луны упал? 43.2 мегабайта это весь образ лисп системы, включая встроенные в SBCL компилятор, интерпретатор, парсер, инструменты для отладки, профайлер, дополнительные либы и биндинги ко всяким позиксам и прочему. Реализации Common Lisp, как правило, не «линкуются» и «стрипаются», а просто скидывают весь образ работающей лисп системы на диск, чтобы создать исполняемый бинарник.

Если взять приложение на .Net Core, в которое запихнут весь дотнет, там так то например даже больше получается.

Гораздо интереснее воччо:

javascript 	6.js   	3634ms 	52ms  	58.3MB  	6793ms  	43ms  	node 16.9.0
vlang      	1.v    	3854ms 	107ms 	3.1MB   	3843ms  	0ms   	vlang 0.2.4
julia      	3.jl   	4105ms 	103ms 	192.4MB 	4083ms  	130ms 	julia 1.6.2
wasm       	2.rs   	4113ms 	15ms  	21.5MB  	4097ms  	0ms   	wasmer/LLVM 2.0.0
wasm       	2.rs   	4139ms 	12ms  	13.6MB  	4127ms  	0ms   	wasmedgec 0.8.2
fortran    	2.f90  	4163ms 	31ms  	1.1MB   	4153ms  	0ms   	gfortran 10.3.0-1ubuntu1
csharp     	3.cs   	4375ms 	938ms 	33.0MB  	5543ms  	20ms  	dotnet 5.0.400
zig        	1.zig  	4631ms 	53ms  	0.1MB   	4620ms  	0ms   	zig 0.9.0-dev.951+9e2472706
csharp     	3.cs   	4674ms 	524ms 	28.7MB  	5540ms  	27ms  	dotnet 6.0.100-preview.7.21379.14
wasm       	2.rs   	4793ms 	7.8ms 	11.1MB  	4780ms  	0ms   	wasmtime 0.29.0
wasm       	2.rs   	4827ms 	3.7ms 	22.3MB  	4817ms  	0ms   	wasmer/Cranelift 2.0.0
fortran    	2.f90  	5162ms 	3.3ms 	1.4MB   	5150ms  	0ms   	flang 7.0.1
typescript 	7.ts   	5292ms 	174ms 	29.7MB  	5217ms  	7ms   	deno 1.13.2
java       	2.java 	5366ms 	22ms  	103.8MB 	10193ms 	60ms  	graal/jvm 11.0.12
wasm       	2.rs   	5488ms 	35ms  	37.9MB  	5570ms  	17ms  	deno 1.13.2
wasm       	2.rs   	5849ms 	6.6ms 	43.4MB  	5883ms  	0ms   	node 14.17.6
java       	2.java 	5853ms 	45ms  	43.5MB  	11357ms 	23ms  	adoptopenjdk 16.0.2
ocaml      	2.ml   	6392ms 	67ms  	3.6MB   	6377ms  	0ms   	ocamlc 4.12.0

Остальные тесты там неидиоматичные и неоптимизированные.

Просто лень их писать. Но если сделать как вот в этом тесте у автора, получим то же самое.

встроенные в SBCL компилятор, интерпретатор, парсер, инструменты для отладки, профайлер

Это всё нужно на этапе разработки. Зачем весь этот хлам в релизной сборке?

Если взять приложение на .Net Core

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

Остальные тесты там неидиоматичные и неоптимизированные.

Они опровергают ваш тезис, поэтому их не надо учитывать, верно?

Просто лень их писать. Но если сделать как вот в этом тесте у автора, получим то же самое.

А сделайте, штуки три,если, конечно, хотите хоть как-то подтвердить тему. Иначе это лишь пустой звук.

Я как-то писал, по-моему, pidigits, который точно так же уделывал C++, но не дописал до конца, лень было.

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

Для стороннего наблюдателя это всё пустые слова.

Дот нет не подгружает отладчик в память во время работы.

Почему нет, если соответствующая библиотека подгружена, забыл точно как называется сама assembly.

Один хрен, 43 мегабайта это мелочь вообще учитывая сколько там всего.

А отладчик в реальности очень полезен, чтобы подключаться к работающему образу CL и смотреть че там происходит, тыкать палочкой. В отличие от C++, наличие отладчика там не замедляет код.

Успокойся, области применения плюсцов и cl практически не пересекаются.

Компилятор в .Net Core кстати в рантайме очень часто используется. Это и System.Reflection.Emit, и лямбды всякие компилируемые.

Для ORM и вебни как минимум.

Область применения плюсов это поддерживать легаси-говняшки, написанные на плюсах, это известно.

SBCL уделывает C++(и шланг, и G++) по производительности

Категоричность настораживает.
Оптимизированный код конечно быстр.
А «обычный» код на SBCL сравним по производительности с C++?

Что такое «обычный код»? Это когда на каждом языке писать как на сяваскрипте?

Что такое «обычный код»? Это когда на каждом языке писать как на сяваскрипте?

«Обычный» - обычный алгоритм … /не нубовский конечно/

Назовите теперь хоть одну причину использовать плюсы вообще?

Если тебя заставляют писать код на плюсах, моргни два раза.

Самый понятный код в fortran варианте. Чем выше код в таблице тем он менее читабельный.

Меряются в скорости генерации 1.0 и вычислении по сгенерированному. Тут огромный простор по срезанию углов, в плоть до того, что можно сразу выдавать предвычисленный результат (мемоизация).

всего 100кБ :)

Как будто это что-то хорошее. Луче бы он отъел 100Мб но был первым.

Неожиданно. Как такой эксперт кастанул такого не эксперта как я.

Назовите теперь хоть одну причину использовать плюсы вообще?

Так CADы пишут на них.

Нет, правила теста запрещают.

Нет, правила теста запрещают.

Это васянский форк того проекта Debian: https://github.com/hanabi1224/Programming-Language-Benchmarks

Этих исходников нет на оригинальном сайте по какой-то причине. К тому же тестирование проводится на бесплатных машинах github actions, а не на выделенной машине, где можно было бы обеспечить хоть какой-то контроль…

https://github.com/hanabi1224/Programming-Language-Benchmarks/issues/98

Или не лучше...

Дай угадаю, видеокарты ты себе подбираешь по показаниям glxgears?

видеокарты ты себе подбираешь по…

… цене. И в последнее время это очень роскошно.

Это позор.

Это не позор. Он сам на старте ест, ещё до задачи. Точнее даже, это стандартный образ столько занимает.

SBCL уделывает C++

По скорости нет же. Но по общим характеристикам да.

Это всё нужно на этапе разработки. Зачем весь этот хлам в релизной сборке?

Когда аппарат полетит к марсу, поймёшь. :)

А «обычный» код на SBCL сравним по производительности с C++?

Как правило, где-то в 1.25-1.5 раза медленнее.

Глупый Лавсанчик.

Скачал себе 8.cpp, идущий сразу за лиспом, который якобы смог. У меня проц 4 ядра, 8 потоков. Выставил количество потоков равным четырём, а не восьми, как по умолчанию. Время выполнения уменьшилось примерно в 2 раза.

Гипертрединг - зло.

42.3MB

Вот это вот, когда у раста 2.1MB

А у C++ 3.3MB

Лишп туда не пустят. Там нужно ехать, а не шашечки.

Почему цпп на старте не ест?

Там нужно ехать, а не шашечки.

Лисп это про ехать. Жаль, что ты даже этого не знаешь. :)

Почему цпп на старте не ест?

Ну не хочет и не ест. Проблема то в чём?

Чёрное это белое. Я победил.

Проблема в чрезмерном потреблении памяти для этой задачи.

И чтобы с пользой употребить эту память, надо потратить время. Вопрос: как он еще умудряется обогнать более честных с zero-cost-abstraction? Жульничает?

Не получится как с мандельбротом где якобы лисп уделывал C, а потом выяснилось, что в C оптимизации не включили и с включением лисп отстал раза в полтора?

Как правило, где-то в 1.25-1.5 раза медленнее.

Нормально.
К тому, что железо сейчас хорошее и многие проекты шустро работают даже если бинарный код в пять раз медленнее C++ …
Но конечно лучше

Шоб нэ пыл, нэ курыл, ...   

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

Получится. Чудес не бывает. Идеально написанная программа на лиспе будет чуть медленнее, чем идеально написанная на си++ с таким же алгоритмом. Потому что абстракции не бесплатны.

Проблема этих тестов в том, что обрабатываемые данные генерируются самой программой. На входе лишь короткое число. При этом не проверяются, что получилось в результате. Можно например тупо на точности вычислений намухлевать.

Кстати, результат обновили https://programming-language-benchmarks.vercel.app/problem/spectral-norm