LINUX.ORG.RU

Как заставить Lisp работать быстрее, чем C

 , , ,


3

6

Зачем продолжают писать на C/C++, когда можно быстро все сделать на Lisp, а потом критические участки кода оптимизировать?

How to make Lisp go faster than C: http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf
Еще не известно, какая производительность будет у реального большого проекта.

Кто-то даже предлагал на Haskell микроядро написать: https://www.pdx.edu/computer-science/sites/www.pdx.edu.computer-science/files...

Зачем продолжают писать на C/C++, когда можно быстро все сделать на Lisp

толсто

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

Еще не известно, какая производительность будет у реального большого проекта.

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

троллейбус_из_хлеба.жпг

Artamudo ★★★ ()

Плюсую про замедление Си.

Если же по существу быстрее Си может быть только ассемблер и С– (+ всё зависит от кривизны рук), т.к. чем жирнее в опкодах средняя инструкция неасм языка и чем более общий характер имеют эти инструкции, тем медленнее становится лучшая версия проги на этом языке.

AKonia ()

Мне кажется, что это заговор сектантов. Эти сектанты задавили лисп-машины и навязали всем кросплатформенный ассемблер, который назвали Си. Зачем они это сделали?

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

Нет, заговор это C++, а задавили Delphi, чтобы потом на C++ сделать Qt.

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

Лисп машины не взлетели из-за их медленности. Сейчас для них было бы самое время, но к сожалению поздно сражаться с x86 и ARM.

monk лучше об этом расскажет.

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

по мне разница не сильно больше различий в стандартах Си++

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

Если же по существу быстрее Си может быть только ассемблер и С–

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

AntonI ()

Нужно наверное создавать отдельный раздел форума для шкобкофагов лисперов. Слишком много тем создаётся по нему.

UPD: есть ли большее русскоязычное сообщество лисперов чем на ЛОРе?

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

Я считаю, что мы воочию видим действия законов диалектики:

По закону отрицания отрицания императивные языки заняли место функциональных, но постепенно сами становятся функциональными. Противоречия накапливаются и появляется HASKELL.

Fast_Sloth ()

Как заставить Lisp работать быстрее, чем C

Никак.

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

По закону отрицания отрицания императивные языки заняли место функциональных, но постепенно сами становятся функциональными.

WAT???

Ну современный язык если он не будет поддерживать ВСЁ, то окажется в невыигрышном положении. Пример: Golang.

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

законы диалектики подтверждают отрицание законов диалектики.

qulinxao3 ()

Online publication: 12 November 2006

Тогда GCC 4.3 (или 4.4?) ещё не было.

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

По существу ускорения добиваются не сменой ЯП а оптимизацией алгоритмов

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

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

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

Каким образом это вдруг плюсы стали языком, где с минимальными усилиями и минимальными накладными расходами можно выразить выбранный алгоритм? По-моему тут что-то не то (говоря более прямо - по-моему тут написана какая-то глупость).

Минимальные усилия будут в каких-то скриптовых языках с автоматической сборкой мусора и прочими удобными программисту вещами. Минимальные накладные расходы - в пределе - будут у ассемблера. Или у какого-то сверхумного компилятора со встроенным ИИ для оптимизаци (и тогда вообще не важно, какой там язык, пусть хоть Ruby). Плюсы тут вообще каким боком?

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

написать компилятор Лисп-задачи с элементами ИИ не хуже образного и логического мышления кодера средней руки, который будет на выходе давать высокоэффективный код на языке низкого уровня :)

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

Ещё можно лисповый код исполнять на платиновом зионе, а сишный на третьем пеньке.

WitcherGeralt ★★ ()

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

вот это и нужно доказать авторам открытия.

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

вот видишь, через 10 лет мастерство приходит таки )

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

Лисп машины не взлетели из-за их медленности.

Из-за дороговизны. И UNIX’а.

Сейчас для них было бы самое время, но к сожалению поздно сражаться с x86 и ARM.

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

И с самим лиспом стало хуже. В современном C++ есть RAII, типизированные коллекции, специализация по шаблонам. В Common Lisp вместо RAII макросы with-* и финализаторы (которые во многих реализациях запускаются после уничтожения объекта, а не перед). Вместо произвольных типизированных коллекций только массивы. Нет указателей/итераторов (можно реализовать через замыкания, но компилятор не понимает и делает неэффективный код).

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

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

Это как раз легко.

(defun compose (f g) (lambda (x) (f (g x))))

Кроме того, есть много алгоритмов, которые оказываются быстрее на лиспе при прямолинейной трансляции. Вот у авторов статьи арифметика на float оказалась быстрее на лиспе. Я, думаю, что они сравнивали сишный float (который 32 бита) и лисповый float (который «любое число с плавающей точкой»). А работа с double на современных процессорах быстрее. Ещё можно strcat посравнивать со string-append, добавляя к строке по одному пробелу много раз. Думаю, тоже лисп окажется быстрее.

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

Плюсы позволяют реализовывать СЛОЖНЫЕ алгоритмы при помощи относительно малого числа букв. Всякие питоны требуют ещё меньшего числа букв, но накладные расходы слишком велики. АСМ и пр.низкоуровневые штуки будут чуть быстрее плюсов (на десятки процентов, если руки прямые) но для сложных алгоритмов число букв возрастёт кратно.

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

AntonI ()
Последнее исправление: AntonI (всего исправлений: 2)
Ответ на: комментарий от peregrine

Много раз уже обсуждали. Речь идёт об усилиях человека одинаково хорошо знающего плюсы и скажем и фортран и пишущего что то сложное (у как я толсто с утра набросил):-)

AntonI ()

а потом критические участки кода оптимизировать?

а что делать, когда нет критических участков кода? код тормозит, но равномерно?

а если они есть, но не очевидны?

next_time ★★★★★ ()

Зачем продолжают писать на C/C++, когда можно быстро все сделать на Lisp, а потом критические участки кода оптимизировать?

А на Lisp уже можно сделать разделяемую библиотеку или утилитку типа cat на пару килобайт?

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

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

Плюсы же популярны по двум открыто заявленным вещам это его Си совместимость и ООП, а также скрываемым типо сложности обращения двоичных программ, как форма защиты ПО(ввиду внутренней связности программ). В случае Си, когда стоит цель усложнить обращение как правило занимаются различным развратом, типо анонимизации имён и перемешивания инструкций(в целях уменьшения прямолинейности логики) ценой производительности в некоторых местах. Во многом эта цель породила такой продукт как denuvo в области развлечений и игр.

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

Это мой тред и я запрещаю заниматься тут натурфилософией.

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

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

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

на Lisp уже можно сделать разделяемую библиотеку или утилитку типа cat на пару килобайт?

Можно конечно, но это чит (кодогенерация из лиспа в си).

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

Если брать принципиально одинаковые алгоритмы, но первую реализацию сделать на Лиспе, то Си проиграет. Потому что реализация на коленке списков и замыканий почти наверняка проиграет встроенным лисповым.

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

Если в качестве сопоставимых условий брать сопоставимое время разработки (или расходов с учётом рынка доступных специалистов), то это тоже корректное сравнение.

Вы не сможете обосновать разработку на асме какой нить толстой гуйни тем что она будет на 10% быстрее.

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

обосновать разработку на асме какой нить толстой гуйни тем что она будет на 10% быстрее

Зависит от стоимости этих 10%. На десктопе это конечно ничего не стоит, но на какой-нибудь кофеварке это может быть go/nogo фактором.

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

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

AKonia ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей