LINUX.ORG.RU

Какие есть годные языки с производительностью на уровне C?

 ,


3

7

Какие есть языки, в которых производительности и потребление памяти близки к таковым для кода на C (разница не более чем в 2-3 раза, а не в десятки и сотни раз как на всяких питонах), но без извращений с ручным выделением памяти и поддержкой функций как значений переменной, оптимизации хвостовой рекурсии и тд?

Желательна строгая типизация.

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

★★★★★

Последнее исправление: Xenius (всего исправлений: 4)

Подписываюсь.

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

Anon
()

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

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

Они там тоже есть, просто их называют более мягко как «computation» или «workflow», чтобы не отпугнуть. Даже синтаксический сахарок очень хороший есть. Async - это самая настоящая монада. Seq/List/Array в F# определены как моноиды.

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

Norgat ★★★★★
()

Две страницы бреда, а единственный разумный вариант никто так и не назвал: C++!

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

Ну чего так сразу резко. Это можно понимать как «удобство написания программ на языке» :3

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

Это мне тоже нравится в F#. И я все больше обалдеваю от того, как, оказывается, удобно использовать F# на OS X. Еще раз убедился в том, что в моих задачах F# через Mono на совершенно аналогичном коде работает быстрее, чем Haskell Platform. Раница доходит до 8%.

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

Тут нечего понимать, это бессмысленное словосочетание.

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

Еще раз убедился в том, что в моих задачах F# через Mono на совершенно аналогичном коде работает быстрее, чем Haskell Platform. Раница доходит до 8%.

Интересно. А с JVM и Scala\Clojure не сравнивал? Было бы интересно узнать какая между ними разница.

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

Это F# поверх Mono на OS X для моих задачах работает быстрее, чем Haskell Platform (64-bit). На винде все наоборот. Код тот же самый. Только уже Haskell Platform работает несколько быстрее, чем .NET.

P.S. Mono надо строго запускать из консоли. В Xamarin Studio (MonoDevelop) происходит что-то странное, и получается гораздо медленнее.

dave ★★★★★
()

Передо мной не так давно тоже встал такой вопрос. После некоторого времени мытарств оказалась, что ответ лежит на поверхности - это С#. Бросьте плеваться, это именно то, что Вам нужно. Это быстро, это строго, это просто.

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

Для языков JVM нет такого синтаксического сахара для монад. Все виденное мною убого и неудобно для использования [1]. А я широко использую монады и продолжения. Фактически мне не с чем сравнивать.

[1] Поэтому в Scala часто пишут плагины к компилятору там, где могли бы подойти «computation expressions» в стиле F#.

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

потребление памяти близки к таковым для кода на C

без извращений с ручным выделением памяти

Разве компилятору так сложно при компиляции расставить free в конце функций и вычислить сколько нужно выделять на массив длинной l?

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

У K, насколько я знаю, совсем неплохо с производительностью, но проприетарщина

Тогда уж J, наверное. Я его даже изучал. Неплохой язык, но стремление авторов к краткости ценой использования #:{. в качестве операторов — весьма сомнительная идея.

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

Разве компилятору так сложно при компиляции расставить free в конце функций и вычислить сколько нужно выделять на массив длинной l?

Если у тебя всё так просто, используй alloca.

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

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

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

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

На первый взгляд, язык офигенный. Нравится синтаксис, ибо наконец-то программисты осознали, что точка с запятой в конце строки ну нафиг никому не нужна. И быстродействие 1-2 по сравнению с Си, и лицензия. Определенно, это заманчиво.

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

О, говноеды уже подтянулись.

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

У меня это этого сообщения жир на экране выступил

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

В общем случае это невозможно. Если язык ограничить, можно написать неплохой region inference времени компиляции.

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

Разве компилятору так сложно при компиляции расставить free в конце функций и вычислить сколько нужно выделять на массив длинной l?

А как компилятор узнает, что нужно подчищать, а что — не нужно? Скажем, есть у тебя статическая переменная: один раз выделил память, а дальше она постоянно используется, free() здесь делать нельзя. Еще более распространенный вариант: твоя функция выделяет память под объект и возвращает его (например, как strdup)!

Anon
()

Почитай для начала B.C. Pierce «Types and Programming Languages».

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

После некоторого времени мытарств оказалась, что ответ лежит на поверхности - это С#. Бросьте плеваться, это именно то, что Вам нужно.

А ты пробовал Tcl? Только там надо код выносить в процедуры, чтоб он компилировался и правильно квотить выражения, тогда он будет до 10 раз быстрее. По крайней мере, получается быстрее питона.

Ещё есть Lua, к которому можно применить luajit. Она тоже намного быстрее питона даже без Jit.

И да. C# нельзя компилить в нативный код или llvm, а OCaml можно. Если уж изучать, то последнее.

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

Это типа Lua что-то?

это гогно типа octave/matlab с элементами паскаля + JIT. В общем, весь шит, которым вечно кормятся «околонаучные» круги.

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

Определенно, это заманчиво.

Нет ООП, нет интерфейсов, нет интроспекции. Для чего-то серьезного не подходит.

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

Прошу прощения. У меня в версии F# была одна оптимизация. Я использовал ссылки самого F#, тогда как в хаскельной версии у меня свои ссылки по типу IORef, но только специальные.

В общем, одного чуда не свершилось. На OS X Haskell Platform на идентичной задаче таки оказался быстрее F# поверх mono: 53 секунды против 59 секунд (плюс-минус секунда или пол секунды, поскольку присутствует элемент стохастики, но он нивелируются при таких объемах).

Тем менее, сеансация присутствует. Mono под OS X на этой задаче (с оптимизацией, когда используются ссылки самого F#) работает быстрее, чем .NET под виндой: 41 секунда против 69 секунд. Повторюсь, это не совсем точно соответствует хаскельному коду.

Что касается самой Haskell Platform, то на винде и OS X она отработала примерно одинаково: 51 секунда на OS X для 64-битной Haskell Platform против 53 секунд на 64-битной Win 8 для 32-битной Haskell Platform.

Что касается -llvm, то у меня не линкуется - надо разбираться. У меня Mac Ports, а там какая-то фигня, из-за чего приходится при сборке указывать -L/usr/lib.

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

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

Скажем, есть у тебя статическая переменная: один раз выделил память, а дальше она постоянно используется, free() здесь делать нельзя.

free делать после последнего использования

Еще более распространенный вариант: твоя функция выделяет память под объект и возвращает его (например, как strdup)!

Если функция возвращает указатель, то память, выделенную под него чистить не нужно, если функция возвращает значение — то все локальные переменные чистить.

Кстати, что думаешь о Tcl и Lua? Второй вроде побыстрее, но памяти больше жрёт. При некоторых оптимизациях начинает работать не так уж и медленно.

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

free делать после последнего использования

И как компилятор это узнает? Это нужен уже другой ЯП. Вот я и смотрю, чего тут автору насоветуют. Пока только говно какое-то.

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

free делать после последнего использования

Как ты предлагаешь определить последнее использование?

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

Если функция возвращает указатель, то память, выделенную под него чистить не нужно, если функция возвращает значение — то все локальные переменные чистить.

А если функция возвращает аллоцированную память в аргументах?

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

А если функция возвращает аллоцированную память в аргументах?

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

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

если аргументы переданы по ссылк

ЧОООО?

Мы точно про С говорим? Я ведь именно С имел в виду: в сях всегда объекты передаются по указателям. Еще указателями передают массивы и т.п. Компилятор не может знать, используется этот аргумент как вход, как выход или как вход-выход!

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

В сях все передается по значению. Указатель - отдельный тип, значениями которого являются адреса. // К.О.

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

Мы точно про С говорим

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

А вообще, функции должны быть чистыми по умолчанию.

Вот в Tcl для работы с переменными родителя есть upvar, например. Для передачи «по ссылке» в качестве параметра передаётся имя переменной.

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

А ты пробовал Tcl?

Очень, очень давно. Я на нем писал сразу после С.

Если хочется экспериментов, тогда попробуйте DMD2 и Vala.

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

На первый взгляд оно правда Lua напоминает, но на самом деле это такой гибрид лиспа с питоном, в хорошем смысле этого слова. Оно даже гомоиконное, но без обрезков ногтей, мне нравится.

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

Зато не нужна особая клавиатура, как в APL, чтобы вводить все символы.
Мало найдётся языков столь лаконичных в своей области применения, да и синтаксис не столь страшен, как на первый взгляд: явно читаемее, чем Perl, и разумеется несравнимо более читаем, чем LISP.

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

Интересно, что-либо когда-нибудь сможет заменить фортран?

Хватит откапывать труп стюардессы.

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

Нравится синтаксис, ибо наконец-то программисты осознали, что точка с запятой в конце строки ну нафиг никому не нужна.

Насколько я понял из мануала, синтаксис там позаимствован из Octave/Matlab, отношение к точке с запятой — оттуда же.

PS. Кстати, точка с запятой — уже давно не такой уж и модный тренд.

theNamelessOne ★★★★★
()
Ответ на: комментарий от quantum-troll

Интересно, что-либо когда-нибудь сможет заменить фортран?

и что там заменять?

mashina ★★★★★
()
Ответ на: комментарий от quantum-troll

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

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

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