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

очевидно же, нужно замедлить С

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

толсто

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

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

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

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

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

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

emacs ?

elisp не совсем Common Lisp.

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

Такие же сектанты задавили баллистическую теорию Вальтера Ритца и навязали всем жидомасонскую теорию Эйнштейна.

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

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

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

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

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

Вам бы к терапевту сходить, емаксовскому.

Ниасилили лисп.

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

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

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

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

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

Никак.

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

WAT???

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

лисп-машины в виде Python_машин убедительно одержали

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

Online publication: 12 November 2006

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

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

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

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

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

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

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

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

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

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

Ну вот касательно усилий к плюсам у меня много вопросов...

Зачем продолжают писать на C/C++…

Хороший вопрос.

не все же неосиляторы, есть и умные-талантливые люди )

https://i.redd.it/9ex196oqc9p41.jpg

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

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

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

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

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

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

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

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

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

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

А еще толще можешь?

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

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

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

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

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

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

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

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

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

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

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

Ну Вы же понимаете, что результат будет зависеть от критериев сравнения;-)

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

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

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

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

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

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

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

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

Язабан

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

Если ты про них не читал, то это не значит, что их нет.

Ты ещё забыл про js-машины