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

эм а вы уверены что видели синтаксис Си/Си++ и Лиспа? Ну просто если видели то таких вопросов бы не было у вас :)

Конечный результат работы каждого наверное всё-таки наверное не время разработки и не объём испарённого каждым программистом пота, если мы измеряем производительность и целесообразность бенчмарков как по мне весьма популистская вещь, т.к. как правило если мы сравниваем языки по работе именно программ которые на нём работают, это прямой признак того, что такого программиста нужно либо уволить, либо получить обоснование того, что он не понимает как устроен и как приблизительно преобразуется его язык программирования, когда бывает появляются «гении» которые говорят что питон работает быстрее или сопоставимо Си сравнивая при этом программу из вызовов обёртки на Си, это признак несостоятельности товарища и просто банальной поверхности его знаний, аналогичное можно отнести и к данной теме, если человек не понимает что Си спроектирован(«by design»)так, чтобы быть ближе к ассемблеру и что трансформаций кода при трансляции кода производится на порядки меньше, то ответ на вопрос того, на чём мы можем написать наиболее близкую к эталонной(по критерию скорости) ассемблерной версии резко становится очевидным, остальные разговоры и споры о дополнительных условиях отпадают, за их несодержательностью. Единственное что как писал один товарищ ранее открытым остаётся вопрос эквивалентной трансляции программы с одного языка на другой(лисп -> Си), но он приблизительно того же порядка как споры о эквивалентности задач разрешимости в логике их комбинаторным собратам.

Хотелось бы узнать. И желательно то что активно используется/разрабатывается, а не «last commit 5 years ago».

цель каждого выжать максимум из своего языка в его родной среде

Так и я про то же. Если взять задание типа: дана произвольная формула в виде строки, содержащая операции умножения, деления,сложения,вычитания и список рациональных чисел. Получить список точных результатов вычисления по этой формуле. Лисп выиграет со значительным отрывом (компиляция формул и работа с рациональными числами встроены).

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

Бинго! Метапрограммирование в 2020 году очень интенсивно используется, только вместо абстракций лиспа, которые понимает полтора программиста, прогер пишет на очень хорошо знакомом всем языке, будь то JS, Java, C, C++, Rust, или другой. По этой же причине Питон победил Лисп.

Это как раз легко. (defun compose (f g) (lambda (x) (f (g x)))) Кроме того, есть много алгоритмов, которые оказываются быстрее на лиспе при

что означает эта мощная строка? хотелось бы попробовать ее на си написать

что означает эта мощная строка

Что ты делаешь в этом треде, если не знаком с азбучной композицией функций?

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

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

Т.е. имеется ввиду «Плюсы заняли некий оптимум, золотую середину между сложностью написания кода и скоростью работы получившейся программы»? А где провести эту золотую середину? Как это вообще оценивать, по каким метрикам?

И вообще, я несогласен. Почему не Fortran? На нем много сложных численных алгоритмов реализовано. Почему не Julia, почему не Rust, почему не D?

Что ты делаешь в этом треде, если не знаком с азбучной композицией функций?

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

Так я же сказал, это функция которая возвращает функцию которая является композицией двух исходных функций.

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

А бывают ли в природе нормальные, не поехавшие лисперы?

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

Fail. Машина Тьюринга - эталонная императивщина, появилась сами знаете когда.

Т.е. имеется ввиду «Плюсы заняли некий оптимум, золотую середину между сложностью написания кода и скоростью работы получившейся программы»?

да.

А где провести эту золотую середину?

ее жизнь уже провела.

Как это вообще оценивать, по каким метрикам?

Зачем?

И вообще, я несогласен. Почему не Fortran? На нем много сложных численных алгоритмов реализовано.

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

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

вопрос того, на чём мы можем написать наиболее близкую к эталонной(по критерию скорости) ассемблерной версии

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

Кто-то даже предлагал на Haskell микроядро написать

Возьмите Forth.

что означает эта мощная строка? хотелось бы попробовать ее на си написать

Функция принимает два аргумента, каждый из которых является указателем на некую функцию, которая принимает один аргумент и возвращает один аргумент. Возвращает функцию от одного аргумента, которая при выполнении применяет к своему аргументу фторую функци, зачтем к результату первую и возвращает то, что получится. На сишном псевдокоде должно быть так:

сompose(f, g)(x) == f(g(x))

для любых f и g, для которых имеет смысл f(g(x))

А где провести эту золотую середину?

ее жизнь уже провела.

Нет. Это из серии «миллионы мух не могут ошибаться».

Как это вообще оценивать, по каким метрикам?

Зачем?

А почему вы отвечаете вопросом на вопрос? А почему нет? Надо же как-то выяснить, какой язык действительно лучше использовать? Или пофиг вообще, берем то место, где «миллионы мух» увидели золотую середину и пользуемся этим? Ну это Argumentum ad populum (с лат. — «аргумент к народу») — вид заведомо логически ошибочной аргументации, основанной на мнении, что большинство всегда право.

Общество часто ошибалось в вопросах того, какие вещи вообще эффективны, например когда-то многие болезни на полном серьезе лечились кровопусканием.

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

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

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

Необоснованное утвеждение.

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

Необоснованное утвеждение.

И да, совсем забыл

Потому что плюсы гораздо выразительнее фортрана

Я упоминал не только фортран, но еще и Rust, Julia, D. По поводу них я ответа не получил.

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

Надо же как-то выяснить, какой язык действительно лучше использовать?

Для этого надо сначала определить, что значит «лучше». Скорость работы программы, скорость написания, среднее количество ошибок, гибкость, возможность изменения синтаксиса, …? Это если брать сам язык в вакууме.

Или пофиг вообще, берем то место, где «миллионы мух» увидели золотую середину и пользуемся этим?

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

суть критерия приблизительно как в соответствии мерных ёмкостей при готовке по рецепту.

Афигенная аналогия! И какой же рецепт лучше, тот куда идет литр молока или тот куда идет 200 гр муки? Вот и Ваш критерий примерно того же качества.

Нет. Это из серии «миллионы мух не могут ошибаться».

Аналогия не является аргументом или доказательством. Программисты не мухи.

Надо же как-то выяснить, какой язык действительно лучше использовать?

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

Общество часто ошибалось в вопросах того, какие вещи вообще эффективны, например когда-то многие болезни на полном серьезе лечились кровопусканием.

Опять Вы во флейм скатываетесь. В чем то ошибалось, в чем оказывалось право.

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

Объективно это объем кода.

Необоснованное утвеждение. (2 раза)

Простите, а Вы сколько HPC кодов написали, для каких задач и на каких ЯП? Я мог бы сказать, что самые быстрые в мире коды для целого ряда задач (объективно, по числу ячеек на шаг на секунду) пишутся на связке плюсы и питон. Или что я знаю библиотеки для плюсов которые делают плюсы не хуже фортрана. Но я не очень понимаю хочу ли я перед Вами обосновывать свои утверждения - хотите верьте, не хотите не верьте, мне как то вообще пофик.

упоминал не только фортран, но еще и Rust, Julia, D. По поводу них я ответа не получил.

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

Аналогия не является аргументом или доказательством. Программисты не мухи.

Аргументом является не аналогия. Аргументом является то, что «ее жизнь уже провела.» - это Argumentum ad populum. Ну и конкретно про программистов я не написал что они мухи, тут скорее надо сравнивать с мухами всю эту индустрию (подготовка кадров в вузах, менеджеры всякие и пр.), которая зачем-то решила что C++ это хорошо, и что вот надо делать так, а что-то другое лучше не пробовать, ведь у нас тут уже столько библиотек наплодилось, столько специалистов на крестах навыпускали с ВУЗов, а мы будем какой-нибудь непонятный язык типа Rust или Julia использовать, наверняка ничего не выйдет. Трудно преодолеть этот потенциальный барьер.

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

Объективно это объем кода.

А читаемость? А типизация? А необходимость (или отсутствие необходимости) руками освобождать память? Лично мне вот совершенно не очевидно. Например по-моему лучше уж многосновный, но зато легкочитаемый язык.

Простите, а Вы сколько HPC кодов написали, для каких задач и на каких ЯП?

Ну во-первых это Argumentum ad Hominem. Совершенно не важно, что лично я написал для HPC. Если это действительно важно - я для микроконтроллеров пишу прошивки на Си - там производительность тоже важна, и язык C++ туда в чистом виде не подходит, приходится отрубать RTTI, исключения и прочий такой шлак. https://bitbashing.io/embedded-cpp.html вот кстати статья про это, с флагами для компилятора.

Я мог бы сказать, что самые быстрые в мире коды для целого ряда задач (объективно, по числу ячеек на шаг на секунду) пишутся на связке плюсы и питон.

Потому что что? Потому что кто-то заплатил людям, чтобы они писали именно на связке плюсы и питон? А есть ли сравнение с другими языками, ну чтобы те же самые алгоритмы реализовали например на Julia? А если на ассемблере начать переписывать, переплюнуть можно наверняка!

Или что я знаю библиотеки для плюсов которые делают плюсы не хуже фортрана.

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

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

Вы не привели обоснований. Вы сказали, что самые быстрые коды пишутся на связке плюсы и питон (без пруфов, но ок, допустим это так). Но значит ли это, что именно такая связка является неким оптимумом? Я так не думаю.

Для этого надо сначала определить, что значит «лучше». Скорость работы программы, скорость написания, среднее количество ошибок, гибкость, возможность изменения синтаксиса, …? Это если брать сам язык в вакууме.

Совершенно верно, нужно начать с того, чтобы четко выработать критерии. Вернемся к цитате AntonI Как заставить Lisp работать быстрее, чем C (комментарий) :

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

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

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

Это да, один из потенциальных барьеров на пути у новых языков. Так и будут какие-то кресты обрастать новыми слоями костылей, с сохранением обратной совместимости

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

А что лучше - яблочный пирог, гуляш или бутылка вина?

хм браузеры?

американский пирог, бутылка (игристого) вина ( с полицейскими)

Но причём тут гуляш?

Но причём тут гуляш?

Просто я люблю гуляш;-)

Давайте сразу проясним - я не воспринимаю этот тред как научную дискуссию, к спорами на ЛОРе какой ЯП лучше я охладел лет дцать назад. Я просто высказываю свое мнение, Вы вольны его воспринимать или игнорировать. Поскольку я числодробилками занимаюсь овер 20 лет, то мои оценки в некотором смысле можно считать экспертными - не в том смысле что я мегагуру, а в том смысле что я в этой области понимаю несколько больше чем какой нить бьюти-блогер;-).

Поэтому я не обязан обосновывать каждое свое высказывание, у меня нет целей убедить Вас в чем либо (перейти на плюсы/дать мне денег), я просто делюсь опытом. В области HPC (раз у ж мы о нем) у меня опыта значительно больше чем у Вас. У Вас значительно больше опыта в области микроконтроллеров. Но было огромной ошибкой пытаться на основе моего или Вашего опыта делать радикальные выводы о всем программировании в целом;-)

надо сравнивать с мухами всю эту индустрию (подготовка кадров в вузах, менеджеры всякие и пр.), которая зачем-то решила что C++ это хорошо

Кроме плюсов мэйнстримами являются как минимум ява, шарпы (ну были) и питон. У индустрии подготовки кадров есть цель - выкинуть на рынок достаточное число молодых специалистов широкого профиля. Индустрия разработки так или иначе ориентируется на индустрию подготовки кадров. Допустим завтра появится экзистенциальный ЯП ускоряющий разработку любых задач на порядок, с производительностью на уровне асма и порогом вхождения как у питона. Но по нему нет специалистов (он только вышел), он станет популярным на уровне плюсов лет через пять +/- в лучшем случае, а вытеснит все остальные ЯП лет через дцать - есть огромная кодовая база которую надо таки поддерживать.

А читаемость? А типизация? А необходимость (или отсутствие необходимости) руками освобождать память?

Это все субъективно, а вот объем кода объективен (это число). ПРИ ПРОЧИХ РАВНЫХ тот ЯП лучше на котором код короче.

пишу прошивки на Си - там производительность тоже важна, и язык C++ туда в чистом виде не подходит, приходится отрубать RTTI,

Плюсы большие, никто не мешает на них писать в С-стайле. Там много всего, это их благо и проклятие одновременно. Диалектика;-)

Я мог бы сказать, что самые быстрые в мире коды

Потому что что?

Потому что это был оптимальный инструмент для решения этих задач с т.з. этих людей. И на фортране/асме скажем это сделать бы не получилось по целому ряду объективных причин, одна из которых выразительность. Вы все время забываете что время и силы специалистов это ресурс ограниченный много больше чем вычислительные мощности. А если говорить про числодробилки, то в связи с острым дефицитом специалистов эта проблема вообще главная сейчас (в РФ).

А если на ассемблере начать переписывать, переплюнуть можно наверняка!

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

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

С учетом того как хорошо на фортране сделаны некоторые вещи - предмет.

Но значит ли это, что именно такая связка является неким оптимумом? Я так не думаю.

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

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

это тоже часть усилий.

что код непереносим на другие архитектуры.

Чем популярней ЯП тем лучше он переносим.

это сравнение уже уровня, что лучше ? Си, Фотошоп или дрова АМД ? Вы благополучно свели иллюстрацию к абсурду, благо мою иллюстрацию вы просто не поняли.

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

Всего хорошего.

Нет, сынок, это фантастика (с)

Давайте сразу проясним - я не воспринимаю этот тред как научную дискуссию ...

ОК.

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

Я тоже не бьюти-блогер и кое-что понимаю в обсуждаемой теме. Многопоточный код мне писать доводилось.

Еще раз - не надо использовать аргументы вида «я в этом специалист, значит я прав». Вы действительно можете быть в этом более компетентны, я с этим не спорю. Проблема в том, что ошибаться могут даже компетентные и опытные в своей области люди, притом вместе со всей индустрией. Никто не застрахован от ошибок. Я могу привести некоторые исторические примеры, но это будет сильный уход в сторону и разведение демагогии.

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

Хорошо, я вроде и не заставляю.

Кроме плюсов мэйнстримами являются как минимум ява, шарпы (ну были) и питон.

В области HPC или вообще?

Это все субъективно, а вот объем кода объективен (это число). ПРИ ПРОЧИХ РАВНЫХ тот ЯП лучше на котором код короче.

Да, с этим не поспоришь.

Плюсы большие, никто не мешает на них писать в С-стайле. Там много всего, это их благо и проклятие одновременно. Диалектика;-)

Да, но я б лично предпочел писать под контроллеры на D в режиме better-C (https://dlang.org/spec/betterc.html), чем на крестах.

Потому что это был оптимальный инструмент для решения этих задач с т.з. этих людей.

А может их точка зрения обусловлена не тем, что инструмент реально лучше по всем параметрам всех прочих вариантов, а потому что так принято считать? Может быть нужно провести какое-то объективное сравнение?

А если на ассемблере начать переписывать, переплюнуть можно наверняка!

Нет. Есть понятие теоретического предела производительности - и на него почти удалось выйти.

Нет, не почти. Говорю вам как человек, репортивший баги в багзиллу GCC с ключевым словом «missed-optimisation» Вообще, там таких багов достаточно много, и не только от меня. Сами посмотрите: https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=missed-optimization&res...

Ну и с автовекторизацией все еще очень плохо, всякие интринсики приходится писать самому, не полагаясь на компилятор. Я уж не говорю о всяких полиэдральных моделях оптимизации циклов https://xeno-by.livejournal.com/28122.html - там вообще всё очень сложно, конца и краю этому не видно

С учетом того как хорошо на фортране сделаны некоторые вещи - предмет.

Ну ок, предмет так предмет.

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

Ну хорошо, расскажите мне о тех задачах. Или вам лень тратить на меня своё время?

Чем популярней ЯП тем лучше он переносим.

Нет. Тогда бы какой-нибудь JS был бы очень очень переносимым, но на деле это не так. В 8-битные микроконтроллеры он что-то не влезает. А Си - вполне.

Многопоточный код мне писать доводилось.

Это о-малое от навыков необходимых для написания НРС-кодов.

В области HPC или вообще?

Вообще. Хотя питон в HPC тоже как ни странно весьма востребован, но там свои погремушки - я бы еще отметил фортран и куду как минимум (которая те же плюсы но в профиль и со своими свистелками).

я б лично предпочел писать под контроллеры на D в режиме better-C

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

А может их точка зрения обусловлена не тем, что инструмент реально лучше по всем параметрам всех прочих вариантов, а потому что так принято считать? Может быть нужно провести какое-то объективное сравнение?

Я Вам который комментарий пытаюсь это сравнение в каком то виде провести, но Вы говорите - не верю, обоснуйте, вы все можете ошибаться.

Есть понятие теоретического предела производительности - и на него почти удалось выйти.

Нет, не почти.

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

Нет. Тогда бы какой-нибудь JS был бы очень очень переносимым, но на деле это не так. В 8-битные микроконтроллеры он что-то не влезает. А Си - вполне.

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

Ну хорошо, расскажите мне о тех задачах.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну и еще насчет выразительности - в плюсах например есть перегрузка операций и шаблоны. Это значит, что я могу сделать эффективный код для своей алгебры с каким то объектами, и это будет работать с минимумом накладных расходов. Причем этот код будет практически 1:1 та численная схема которая занимает несколько страниц мелким шрифтом - это очень дорогого стоит.

Я б лично тоже предпочел писать на чем то другом а не на крестах, но если не можешь делать то что хочешь - делай то что можешь.

Да. Но тут понимаете ли в чем дело - я со своей позиции, т.е. с позиции человека, который под контроллеры пишет код, вижу, что язык Си не является на данный момент лучшим вариантом (если именно смотреть с позиции, на чем бы мне было удобнее и приятнее писать). Мне просто говорят «Вот у нас работа, пиши на этом и получай за это деньги.». Если я скажу «Нет, это неоптимально, хочу на этом»... в общем, никто со мной особо торговаться не будет.

И их можно понять. Допустим, согласятся они чтоб я писал на D или Rust каком-нибудь, а кто еще будет на этом писать? А если я свалю из проекта, кто это будет дальше поддерживать? Где им искать кадров? Тут речь идет не о некоторой качественности или оптимальности самого языка как такового. Да, это тоже такой локально-оптимальный путь, пусть всё остается как есть, будем пользоваться теми языками, под которых проще найти кодеров, но это не критерий оптимальности самого языка в вакууме, это критерий его оптимальности при некоторых других факторах, таких как наличие кадров, стоимость этих кадров, наличие готовых библиотек, компиляторов и так далее. Это создает сильный потенциальный барьер. И если действительно есть какой-то очень хороший язык, который на голову выше всех прочих языков для конкретной области, далеко еще не факт, что он сможет в существующей экосистеме прорваться и стать популярным. Он может просто быть не настолько лучше, чтобы все кинулись на него переучиваться и переписывать весь свой код на него.

Пардонте, откуда Вы знаете что удалось а что нет? Вы телепат?

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Если вас интересуют конкретно мои багрепорты - ну например вот один из них https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574

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

А разве все решаемые в HPC задачи всегда упирается в FMA операции? А как быть с ветвлениями? А что насчет оптимизаций методом частичных вычислений (суперкомпиляция)? Может есть способ, путем хитрых оптимизаций, радикально снизить число FMA операций, которые требутся для конкретных вычислений? И что можете сказать про полиэдральную модель для оптимизации циклов, обходящих многомерные массивы? https://iconfs.net/infocom2016/sravnenye-effektyvnosty-avtomatycheskoj-optymy... вот можете почитать, я даже могу процитировать:

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

Там по-вашему достигнут предел?

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

Вот кстати совсем недавно обсуждал с одним человеком эту тему: был кусок кода на Си который написан на интринсиках, этот человек взял асмовыхлоп компилятора для этого кода, руками там попереставлял инструкции местами - получил выигрыш в производительности. Через интринсики получилось не самое оптимальное. Ну и можно еще вспомнить Intel MKL, в которой именно не интринсики, а руками написанные куски на ассемблере. Нужны доказательства - вот https://software.intel.com/en-us/forums/intel-fortran-compiler/topic/273636 - «MKL is hand-tuned assembly language for Intel CPUs, and also supports HyperThreading and multiprocessor systems.». Вряд ли в Intel стали бы просто так писать на асме, если бы это не давало какой-то выгоды.

Это будет много букв. Можете погуглить «LRnLA алгоритмы» для начала. Если сразу перейти в конец - «обычный» код (на фортране или сях) занял бы оочень много места, потому что там алгоритмически рекурсия, но все вызовы функций должны быть заинлайнены. Поэтому там плюсовые шаблоны (они позволяют делать относительно компактный код который эффективно развертывается компилятором) и все это генерится из питона (потому что учет гранусловий очень сильно усложняет даже этот шаблонный код).

А на саму реализацию этого LRnLA где можно посмотреть? Вообще, это мне напомнило то, что сделали в FFTW3 - http://www.fftw.org/fftw-paper-ieee.pdf - у них свой метаязык (DSL) на Ocaml синтезирует сишный код. Притом там даже система символьных вычислений есть над всем этим. Цитата:

Consequently, to generate code for a trigonometric transform, genfft first reduces it to a DFT and then it generates a dag for the DFT, imposing the necessary symmetries, setting the appropriate inputs to 0, and pruning the dag to the appropriate subset of the outputs. The symbolic simplications performed by genfft are powerful enough to eliminate all redundant computations, thus producing aspecialized DCT/DST algorithm. This strategy requires noprior knowledge of trigonometric-transform algorithms and is exceptionally easy to implement.

Может и для алгоритма LRnLA такой подход будет оптимальней.

Если питон еще можно было бы чем то заменить, то чем заменить в этой задаче плюсы я не знаю. Может предложите свой вариант? Требуется ЯП с аналогом плюсовых шаблонов, высокоуровневым ООП и низкоуровневой работой с памятью (голые пойнтеры и всякие игрища с адресами) + MPI + для этого ЯП должен быть хороший оптимизирующий компилятор + это все должно быть установлено на суперкомпьютерах и кластерах. Ну и этот ЯП должен быть достаточно популярен что бы можно было привлекать в проекты других людей/делится своими проектами с сообществом. Потому что суперкодом каком нить суперЯП который знает полтора гениальных инвалида никто кроме этих инвалидов все равно пользоваться не будет.

Ну если мы к списку требований добавляем популярность и возможность привлечения, то это уже не о качестве языка, я об этом выше уже написал. И в таком случае я уже вполне могу согласиться, что такой выбор оптимален. А так - ну можно взять OCaml и Си (где OCaml будет синтезировать код на Си из некоего DSL). В той статье про FFTW3 http://www.fftw.org/fftw-paper-ieee.pdf пишут про компилятор специального назначения, который на выходе дает код на Си. Вот такой подход можно использовать.

Можно еще взять еще OCaml и D в BetterC режиме. Можно взять LISP который генерит код на FORTRAN и так далее, вариантов вообще масса.

Ну и еще насчет выразительности - в плюсах например есть перегрузка операций и шаблоны. Это значит, что я могу сделать эффективный код для своей алгебры с каким то объектами, и это будет работать с минимумом накладных расходов. Причем этот код будет практически 1:1 та численная схема которая занимает несколько страниц мелким шрифтом - это очень дорогого стоит.

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

Ну и далеко не все задачи HPC это LRnLA алгоритмы. Например, применимы ли данные алгоритмы для решения задач МД моделирования(фолдинг белковых молекул)?

я думаю...что для этого нужны программисты

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

Разумеется. Но понятие «оптимальности» вообще то весьма размытое, у манагера одни критерии, у кодера другие, у производителя железа третьи и т.д.

Да я вроде сказал откуда я знаю. Я смотрел и сам отправлял багрепорты в багзиллу GCC с ключевым словом «missed-optimisation».

Нет, Вы не поняли. Есть чиселка - теоретический предел производительности. Он выводится на бумажке и не зависит от компиляторов и вообще реализации, это сферический конь в вакууме. Если я написал какой то код который скажем выдал 50% от этого предела (что ОООЧЕНЬ много, в реальности обычно в среднем получают первые проценты), это значит что этот код в принципе нельзя ускорить больше чем вдвое. Никак. Ошибки в оптимизации компилятора и пр. могут влиять на эти проценты - но не могут влиять на предел производительности.

А разве все решаемые в HPC задачи всегда упирается в FMA операции?

Задача расчетов - че то делать с числами, как правило их складывают и умножают. Спецфункции тоже к этом сводятся. Все остальное, включая конструкции принятия решения, обычно (если код написан грамотно) занимают гораздо меньше времени. Хотя всяко бывает… но в теоретическом пределе обычно учитывают только FMA, ну и еще выгрузки/загрузки. Если ветвлениями ломает конвейр - ССЗБ, думай, переделывай код.

Все задачи делятся на compute bound (и их ускорить считайте что нельзя если очень грубо - Вы уперлись в производительность процессора и сидите на том самом пределе) и memory bound (процессор недогружен, память не успевает поставлять данные). Оптимизации, в т.ч. полиэдральные компиляторные, как раз и призваны превратить memory bound в compute bound. Нормально сделанные задачи молдинамики кстати обычно compute bound, если не вдаваться в детали. Вообще погуглите про roofline model.

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

Может есть способ, путем хитрых оптимизаций, радикально снизить число FMA операций, которые требутся для конкретных вычислений?

Есть каноничнеская последовательность «математическая модель -> численная схема -> код». Уменьшить число операция не модифицируя числ.схему не получится (если и может получиться то это уже давно сделано). В любом случае это относится не к программированию. Чудес не бывает.

Насчет DSL - я пытался это сделать. Принципиально это возможно, но у меня не получилось по ряду причин. В любом случае, юзеру придется знать DSL и плюсы, потому что некоторые (служебные) задачи приходится все же писать на плюсах. Я вот сейчас с вьюверами вожусь, ну какой тут DSL… байтофилия сплошная.

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

Пардон а как же AutoCAD, или это по Вашему маленький проект? И не говорите что он на диалекте, а диалект это не Lisp, lol!!

Я ещё про Maxima забыл. AutoCAD не использовал, но судя по описанию AutoLISP – это DSL.

Ещё пару rowhammer и spectre дыр в процах и привет

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

P.S. Спойлер: нет.

Разделяемые библиотеки — зло. Ну или добро. Всё-таки из-за них множество людей получилили работу. С другой стороны, если бы не было вынужды плясать с зависимостями пакетов, возможно они бы занялись чем-нибудь полезным. Так что всё-таки зло.

Бутылка вина.

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

А без сишных библиотек на лиспе даже по HTTPS файл не скачать.