LINUX.ORG.RU
ФорумTalks

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

 , , ,


0

5

https://programming-language-benchmarks.vercel.app/problem/spectral-norm

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

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

Перемещено xaizek из development

Ответ на: комментарий от fsb4000

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

anonymous ()

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

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

pingvinek ()
Ответ на: комментарий от ox55ff

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

anonymous ()
Ответ на: комментарий от ox55ff

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

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

lovesan ★★ ()

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

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
Princesska ★★★ ()
Последнее исправление: Princesska (всего исправлений: 3)
Ответ на: комментарий от fernandos

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

lovesan ★★ ()

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

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

anonymous ()
Ответ на: комментарий от lovesan

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

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

anonymous ()

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

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

i-rinat ★★★★★ ()

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

Reset ★★★★★ ()

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

anonymous ()

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

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

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

saufesma ()
Ответ на: комментарий от Siborgium

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

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

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

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

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

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

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

anonymous ()

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

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

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

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

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

turtle_bazon ★★★★★ ()

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

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

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

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

42.3MB

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

А у C++ 3.3MB

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

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от turtle_bazon

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

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

Шоб нэ пыл, нэ курыл, ...   
anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)