LINUX.ORG.RU

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

 ,


0

1

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

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

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

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

★★★★★

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

iu0v1
()

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

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

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

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

Valkeru ★★★★
()

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

Zubok ★★★★★
()

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

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

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

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

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

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

> f1(x) = x^3;
и у тебя в программе образовалась некая функция f1, принимающая x и считающая по формуле. Чтобы такое сделать, необходимо распарсить ввод пользователя, скомпилировать некую мини-функцию, и чтобы потом ее можно было вызывать, например так:
> f1(3);
< 27
Что тут можно сделать с высокоуровневым языком, чтобы это все быстро работало? Можно переводить f1(x) = x^3 в некий код на твоем высокоуровневом ЯП, потом компилировать его, и вызывать в случае надобности. Но тут возникает сложность - надо для этого тащить целый компилятор в рантайм. А это попросту глупо во многих случаях. И кроме того, целый компилятор будет слишком долго это компилировать т.к. он для более общих случаев предназначен, а не только для компиляции неких формул. А если взять тот же Си, я могу написать минималистичный JIT который бы непосредственно выдавал мне код функции в машинных кодах, и писать его в некую исполняемую область памяти. Потом вызывать в случае чего. Это будет значительно быстрее.

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

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

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

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

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

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

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

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

Xenius ★★★★★
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Xenius ★★★★★
() автор топика

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

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

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

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

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

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

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

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

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

antares0 ★★★★
()

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

MKuznetsov ★★★★★
()

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

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

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

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

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

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

anonymous
()

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

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

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

Eddy_Em ☆☆☆☆☆
()

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

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

tailgunner ★★★★★
()

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

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

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

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

+1

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

beastie ★★★★★
()

Фортран?

Deleted
()

c with profile guided optimization

anonymous
()

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

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

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

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

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

loyd
()

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

anonymous
()

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

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

mashina ★★★★★
()

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

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

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

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

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

unlog1c ★★★
()

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

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

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

Да.

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

LLVM.

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

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

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

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.