LINUX.ORG.RU

Clasp, одна из новых реализаций CL, всего лишь в четыре раза медленнее, чем C++

 , , , ,


3

3

Новая реализация компилятора CClasp, базирующегося на Cleavir от Robert Strandh, без оптимизаций, всего лишь в четыре раза медленнее, чем C++. Ожидается, что с добавлением вывода типов производительность генерируемого кода с CClasp, должнo еще прибавить в скорости выполнения.

В приведенной таблице, также есть сравнение производительности генерируемого кода с SBCL (еще одна из активных реализаций CL) и Python.

Основной особенностью Clasp, среди других реализаций Common Lisp, является тесная интеграция с C++ и использование LLVM.

Подробности: https://drmeister.wordpress.com/2015/07/30/timing-data-comparing-cclasp-to-c-...

NOTE: this test is a specific test of an algorithm that uses FIXNUM arithmetic. I have inlined simple FIXNUM arithmetic (+, -, <, =, >, and fixnump) and so these operations are fast. Code that uses other functions will run a lot slower until inlining is implemented more broadly.

Расходимся, посоны.

Gvidon ★★★★ ()

Основной особенностью Clasp, среди других реализаций Common Lisp, является тесная интеграция с C++ и использование LLVM.

Ура! Два самых прекрасных языка в мире теперь могут взаимодействовать друг с другом! И теперь на основе CL и C++ можно будет создавать такие же шедевры, как Abuse, Crash Bandicoot и The Last Of Us, но только без всяких самописных интерпретаторов-костылей. Возрадуемся этому!

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

Будет значит более-менее юзабельный DSL. А в чем пафос темы?

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

То, что это результат, показанный в одном специфическом тесте, да и то под этот тест компилятор пришлось дотачивать, и автор прямым текстом пишет, что работает это пока только с целочисленной арифметикой. Результатище, чё.

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

что работает это пока только с целочисленной арифметикой. Результатище, чё.

И чо? Это бенчмарк хелловолда же. На более комплексных и сложных приложениях Clasp вполне может порвать C++ по продуктивности разработки и результату выполнения.

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

А в чем пафос темы?

В том, что C++ становится все более ненужным, не?

Oxdeadbeef ★★★ ()
Последнее исправление: Oxdeadbeef (всего исправлений: 1)
Ответ на: комментарий от Oxdeadbeef

может порвать C++
может

Ага. А на лисп-машине вообще обретёт разум и победит человечество. Слышали уже.

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

Ага. А на лисп-машине вообще обретёт разум и победит человечество. Слышали уже.

Я этот бред не слышал. У вас скорее фантазии разыгрались на почве разогрева.

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

ути-пути, лиспеныши пытаются выжить :)

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

В том, что C++ оказывается еще более ненужным, не?

На самом деле было наоборот: сначала был лисп, потом C, а потом C++ и лисп оказался не нужен.

На более комплексных и сложных приложениях Clasp вполне может порвать C++ по продуктивности разработки и результату выполнения.

Вот как раз на сложных и комплексных задачах ни один подобный язычок C++ никогда порвать не сможет. Просто потому, что не содержит адекватных средств борьбы со сложностью, коими являются статическая типизация и ООП.

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

лисп оказался не нужен

лисп был слишком дорог для того времени да и железки были слабоваты

адекватных средств борьбы со сложностью, коими являются статическая типизация и ООП

4.2

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

Не мешайте мальчику. Он отыгрывает mv.

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

лисп был слишком дорог для того времени да и железки были слабоваты

Там, где пр делу используется C и C++, лисп всегда будет слишком дорог. Т.к. с ростом мощности железок и их числа, растут аппетиты бизнеса по фичам и хотелкам, растут и объёмы данных, с которыми приходится работать.

anonymous ()

Первый же пост раскрыл тему.

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

растут и объёмы данных, с которыми приходится работать

man Allegro CL

man AllegroCache

man AllegroGraph

Oxdeadbeef ★★★ ()
Последнее исправление: Oxdeadbeef (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Первый же пост раскрыл тему.

Сказали же, что используется почти референсный компилятор, и оптимизаций еще не было впилено.

Oxdeadbeef ★★★ ()
(defun fibn (reps num)
  (declare (optimize speed (safety 0) (debug 0)))
  (let ((z 0))
    (declare (type (unsigned-byte 53) reps num z))
    (dotimes (r reps)
      (let* ((p1 1)
             (p2 1))
        (dotimes (i (- num 2))
          (setf z (+ p1 p2)
                p2 p1
                p1 z))))
    z))

Отличная каша из каких-то прагм и императивного (?) кода. Wow, such readability, much declarativity.

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

Приведи бенчмарк того же самого на твоем любимом хаскеле.

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

Сказали же

Сказали, что «всего в 4 раза медленнее» - это на одном тесте с fixnum. И кстати, «в 4 раза медленнее» - это отстой.

tailgunner ★★★★★ ()

И кому теперь нужен си++?
Ахахахаха!!!

arturpub ★★ ()

clang++

ясно, понятно

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

Это бенчмарк хелловолда же.

Вот именно, то есть судить о производительности в общем по этому тесту нельзя.

И отвлечённый вопрос: как ты относишься к схеме/ракету?

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

Но ведь приведённый в статье пример на сишке выйдет короче и понятнее. И ведь это всего лишь числа Фибоначчи.

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

Но ведь приведённый в статье пример на сишке выйдет короче и понятнее.

Где короче то? Один в один только со скобками в лисп версии. На CL даже короче: на пару строк меньше (declare не считаем).

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

И отвлечённый вопрос: как ты относишься к схеме/ракету?

никак :) я их не использую в работе.

Oxdeadbeef ★★★ ()

Это очень хорошо. Но пока не будет работать так же, как и C++ - мне не интересно, увы.

Chaser_Andrey ★★★★★ ()

всего лишь

мне тут кстати некие анонимы втирали какую-то дичь о перформансе «некоторых реализаций» lisp. Это о этом речь шла, да?

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

некие анонимы

Вот у них и надо было спрашивать в контексте вашего разговора.

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

так где же мне взять их, анонимов этих?

А вопрос мой по теме такой:

Какие реализации CL являются высокопроизводительными?

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

Это бенчмарк хелловолда же. На более комплексных и сложных приложениях Clasp вполне может порвать C++ по продуктивности разработки и результату выполнения.

аналитика по бенчмаркам хеллоуворлдов - это то что даже libastral не умеет делать, склоняю голову перед Вашей мощью

shty ★★★★★ ()

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

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

аналитика по бенчмаркам хеллоуворлдов

не только. Еще есть некий экспириенс полученный в результате разработки на CL (LispWorks) и C++. Clasp был приведен как возможность легко интерфейсится с плюсовыми либами и выступать в виде ядра бизнес логики.

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

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

loz ★★★★★ ()

Еще бы хелловорлды замеряли, право. На простом цикле, однозначно компилируемым в бинарь, разницы, конечно, не будет. Разница будет, когда в дело вступит агрессивный инлайнинг, векторизация, lto, rvo, отсутствие лишних проверок в рантайме, мономорфизация, ручное управление памятью и прочие ништяки, которые в CL крайне ограничены ввиду его динамической природы.

Можно, конечно, пытаться - и SBCL тут достиг отличных результатов - но для получения сравнимого результата надо писать не на идеоматическом CL, а на неподдерживаемом C-со-скобочками, с кучей (declare) и императивщеной.

Вообще у CL какой-то identity crisis - вроде динамический язык, а зачем-то пытается с С++ по скорости соревноваться. Вон питону и руби тормоза совсем не мешают, и тот же го не комплексует по этому поводу.

nonimous ()

Тащить это на ЛОР и не упоминуть что в данном тесте SBCL обогнал C++ ?!!

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

Выигрыш тут исключительно из-за '}' на новой строке.

(declare не считаем)

Что так?

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

Что так?

Подсказка компилятору. Умный компилятор сможет соптимизировать и без них.

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

в данном тесте SBCL обогнал C++ ?!!

Уже давно не является чем-то новым.

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

Если за рулем болида идиот, то его обгонит любая бабка на коляске. Увлажняйтесь дальше.

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

LISP shills in a nutshell: "сравним реальный код и код из идеального мира скобочек и цветных лошадей"

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

Ну да, даже в тех тестах, где GC ухитряется обогнать ручное управление памятью аж на целых 4%, обычно оказывается, что автор теста специально забывает про то, что в приличных языках есть стек, на котором можно и нужно создавать временные переменные, а не только ссылки на них.

asaw ★★★★★ ()
Последнее исправление: asaw (всего исправлений: 1)
Ответ на: комментарий от Oxdeadbeef

никак :) я их не использую в работе.

Ну... я тоже много чего не использую, но мнение иметь это не мешает. (:

Но «никак» - это тоже отношение. Значит, как минимум, не интересно.

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

всего лишь в четыре раза медленнее, чем C++.
Основной особенностью Clasp является тесная интеграция с C++
Пафос темы в том, что C++ становится все более ненужным, не?

Сдается мне, где-то ты ошибаешься...

kravich ★★★★ ()
Последнее исправление: kravich (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.