Существует ли язык высокого уровня, который устойчиво быстрее C?

Нет

А как-же хорошенько разогретая JVM!

Да, Z. Но в этой ветке времени его еще не изобрели.

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

Только если компилятор этого языка будет содержать ИИ

Только если компилятор этого языка будет содержать ИИ

Дай определение ИИ. GCC содержит ИИ?

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

В принципе, некоторые утверждают, что компиляторы Фортран могут выдать неплохой код. Я сам не сравнивал, на Фортране не писал ничего с 1992-1993 года. Разузнай.

ATS Но это такой DSL который все равно компилируется в С пусть и нечитаемый. Staln Схема которая пытается прожевать все доступные исходники включая стандартную библиотеку. Лиспы имеющие на борту компилятор вобще могут сгенерерировать код более лучший чем C вобще для частногох набора входных данных. Выиграш как правило все равно не превышает 10% так что на статистику не очень влияет.

Вот определение с википедии

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

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

Или вот представь что у тебя есть некий высокоуровневый язык с jit eval-ом. Ты сделал консольный калькулятор. Пользователь вводит

> f1(x) = x^3;

> f1(3);
< 27

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

Вот в ядре Linux кстати есть особый JIT для BPF https://lwn.net/Articles/437981/ и никто в здравом уме не будет в ядро тащить рантайм JIT от какого-нибудь лиспа например

GCC содержит ИИ?

Учитывая баги, которые я в нем нахожу, там его нет даже близко

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

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

Но это такой DSL который все равно компилируется в С пусть и нечитаемый.

Значит он уже заведомо не может быть быстрее C

язык высокого уровня, который устойчиво быстрее C?
я говорю о языке высокого уровня, который полностью абстрагируется от машины, так чтобы программа на нём могла быть скомпилирована на любой машине и для любой ОС.

да это же C с прямыми руками!

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

Но тут возникает сложность - надо для этого тащить целый компилятор в рантайм.

А почему бы и нет? Компилятор можно сделать модульным, чтобы для частных задач использовать только нужные функции, например только парсер.

да это же C с прямыми руками!

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

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

Может быть, но уже поздно.

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

А, так ты просто потрепаться о том, в чем не смыслишь!.. Предупреждать надо.

Значит он уже заведомо не может быть быстрее C

Что не мешает(ло) ему висеть на строчку выше. То бишь задача сделать чистый С-шный код настолько же быстрым была нетривиальна. Поэтому я и упомянул о нем.

оптимально написанной программы на C

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

Что не мешает(ло) ему висеть на строчку выше. То бишь задача сделать чистый С-шный код настолько же быстрым была нетривиальна. Поэтому я и упомянул о нем.

А что ты скажешь об Idris? Тоже компилируется в C, тоже поддерживает зависимые типы, например.

Не смотрел, ничего не скажу.

Java </thread>

Работает общее правило: «выигрывая в малом, проигрываем в большом». Трактовать это можно по-разному.

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

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

Не смотрел, ничего не скажу.

А может посмотреть стоит? Говорят, что он годный.

А на ATS писал что-нибудь крупнее хелловордов или задачи о восьми ферзях? Я его как-то смотрел, но примеры кода что-то не впечатлили.

По Идрис мне в отличае ATS вобще ничего не попадлось, почему-то. На ATS не писал, я все таки лиспер на 99%. С всеми вытекающими. Держу в памяти на случай необходимости переписать что-нибудь безрантаймовое.

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

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

А причём тут исходный код? Речь идёт о том, чтобы посчитать что-нибудь настолько быстро, насколько это возможно. Например решето Эратосфена до 10 млрд не более чем за одну минуту. Если это будет не компилятор, а jit-интерпретатор, я не против. Но только чтобы скорость была не меньше чем у сишников.

притом, чтобы выжать из целевого железа все возможности, нужно приложение собрать на нем

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

давайте вспомним суперкомпиляцию и то что Си и Си++ устойчиво сливает Java. Кстати доказанно русскими физи^Wматематиками.

НЕТ. </thread>

Forth

За такое наглое 4.2 хорошо было бы шпицрутенами!

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

Оба вопроса почти бессмысленны, но ответ на первый - «нет».

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

Open SPHiNX C-- © был быстрый, маленький, но мёртвый.

OpenEuphoria © (Multi-platform, an optimizing Euphoria To C Translator) пока живой, но маргинальный.

+1

«Выигрываешь в скорости — теряешь в выразительности.»

Фортран?

c with profile guided optimization

Есть некий C-- https://www.wikiwand.com/en/C--

Понятно что существует ассемблер

Понятно что это должен быть такой .NET но только чтоб сверху т.е. для человека в нем была высокоуровневая/простая/понятная ерундень а снизу всё тот-же всемогущий asm. Вот тогда можно будет и корованы грабить и волосы останутся мяяяяягкими и шелковистыми.

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

Ну, в v8 это решили двумя jit-компиляторами: обычным и оптимизированным. Вон Hola устраивает конкурсы аля «разогнать strftime в 50 раз», где как раз способности jit-а используют.

Обрерон, Forth, Java с JVM

Так вот, возможно ли сделать такой язык? Если да, то в каком направлении копать?

Русский, например, чем не такой язык? Рассказываешь разумному инженеру что хочешь видеть в конечном счёте, а он реализует всё со всеми особенностями конкретной платформы. Язык определённо должен быть декларативным и компилятор к нему с адовой логикой внутри.

lisp на lisp машине

оптимально написанной программы на C

А что это такое? Если это чистый С код, то он далеко не факт что будет самым быстрым на каждой платформе. Если это лапша из прагм, ифдефов и ассемблерных вставок, то это уже не совсем платформонезависимый код.

Си, как язык, не абстрагирует все платформы, он абстрагирует линейный однопоточный PDP-11 с локальной памятью. То, что код на нем продолжает быть быстрым на современных платформах с множественными ядрами, суперскалярностью, GPU, векторизацией — это заслуга компиляторов, а не языка. Сам язык предоставляет очень ограниченные возможности для описания программ с учетом всех этих новых возможностей.

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

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

SystemVerilog

Существует ли язык высокого уровня, который устойчиво быстрее C?

Быстрее - нет. GCC и Clang и так генерируют наиболее оптимальный код в большинстве случаев. За ними стоят годы разработки.

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

Да.

Если да, то в каком направлении копать?

LLVM.

Есть ли что-то быстрее Си?
НЕТ. </thread>
Eddy_Em

Кто бы мог подумать?

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

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