LINUX.ORG.RU

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

 ,


3

7

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

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

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

★★★★★

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

столь редкий техпроцесс

хз, но бабло там крутится сумасшедшее...

Или это мне спьяни почудилось?

может энтузиасты и пилят что-то, но интелам и зайлинксам это не надо. инфа 146%

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

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

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

Где бы энтузиастам взять те несколько миллиардов долларов, что требуется на разработку? Задача очень наукоемкая. Библиотеки ячеек разрабатываются годами, методом проб и ошибок.

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

на это я ему и пытался намекнуть: кучка фанатиков индустрию не поимеют.

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

не хватит.

тому же фотошопу, тридэмаксу, автокаду, либреофису нету аналогов.

про специализированый софт тебе уже сказали.

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

нет value types

читал на so.com что уже собираются сделать или уже сделали

вера в то, что JVM сделает всё за тебя

один жаба-гуру сказал что JVM на 2 порядка умнее и грамотнее среднего типового инженера вроде меня или например тебя. поэтому таки да, JVM сделает всё за тебя ;-)

недаром maxcom держит LOR на JVM и на Lispы с какацкелями и ржавчинами переходить не спешит

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

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

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

не-не-не, в другую сторону думай или см. quicksort в glibc-е.

что-то мне лениво эту хрень распаковывать. А что там сейчас?

данный пример должен приводиться, только как то, что форма записи в haskell может быть очень близка к математической. При приведении этого примера всегда говорится, что это не quicksort.

вот что-то мне не встречалось. Разве что на лурке в сраче. А примеры я не только на лурке наблюдал.

И да, тот «ЯП», который используют математики, ИМХО очень плохо подходит для записи алгоритмов. Потому, алгоритм и НЕ должен походить на формулу.

Я не знаю почему этот пример все так любят.

ответ выше...

P.S. моя реализация quicksort слила сишной (из lj) в 3 раза, с wiki во много, разбираться почему и делать более оптимальный вариант на haskell мне лень ибо работать надо.

написать хорошую qsort вообще не просто, да и она сильно зависит от CPU(или что там у вас вместо него). А учитывая её нестабильность в плане времени/памяти, то её вообще лучше стараться не использовать ИМХО.

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

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

микрософт говно, микрософтовские поделия не нужны.

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

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

опять же, 99% проектов на всякой функциональщине — околофинансовый софт, сорцы которого ты никогда не увидишь.

вот именно! И угадай, почему АНБ выкладывает свою систему безопасности SELinux, а какая-то безымянная говноконторка — стесняется? И даже не систему безопасности, а какой-то тривиальный гипертрофированный калькулятор на стероидах. И правильно стесняется, ибо если выложит свой калькулятор, то его будут иметь в хвост и гриву любой говнокодер вроде меня. А вот SELinux — я даже и не сунусь, ибо зачем мне биться в бетонную стену головой? Учитывая кучи трупов у этой стены, которые уже свою головушку расшибли.

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

что-то мне лениво эту хрень распаковывать. А что там сейчас?

отвечу цитатой, чтобы не переврать:

   1. Non-recursive, using an explicit stack of pointer that store the
      next array partition to sort.  To save time, this maximum amount
      of space required to store an array of SIZE_MAX is allocated on the
      stack.  Assuming a 32-bit (64 bit) integer for size_t, this needs
      only 32 * sizeof(stack_node) == 256 bytes (for 64 bit: 1024 bytes).
      Pretty cheap, actually.

вот что-то мне не встречалось.

начиная с haskell-wiki было так, наверное дальше по блогам и т.п. расползлось, небось через какие-нить pdf-ки лекций, где комментарий про то, что это не квиксорт дописать забыли.

И да, тот «ЯП», который используют математики, ИМХО очень плохо подходит для записи алгоритмов. Потому, алгоритм и НЕ должен походить на формулу.

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

написать хорошую qsort вообще не просто, да и она сильно зависит от CPU(или что там у вас вместо него). А учитывая её нестабильность в плане времени/памяти, то её вообще лучше стараться не использовать ИМХО.

ЕМНИП в ленивом языке нужен merge сорт, который и красиво пишется и хорошо использует фичи ленивости и immutable-ности в pearls of functional programming Бёрда есть глава посвященная сортировкам неполохая, и в задачах у Окасаки в purely functional data structures, но там меньше оптимизаций покрыто.

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

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

Итого, все подобные алгоритмы просто записываются как в имепаривном языке, и остаются безопасными.

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

всё правильно говорит

Но не может свою позицию аргументировать.

Ибо зонды от мысы всегда огорожены и замкнуты сами на себя

Все зонды такие. С этим ничего не поделать.

Ты разве не понимаешь

Речь не обо мне. Я пользуюсь и открытым и проприетарным софтом. Например, мне и в голову не придет пользоваться открытым софтом типа q-cad'а, если на рабочем компе стоит купленный альтиум дизайнер.

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

Если бы был действительно не редкий, то каждая компания не пилила бы свой софт, а пользовалась всеобщей разработкой!

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

Можно я (не)много не в тему, но скажу. Допустим используются OCaml/Lisp/Haskell/etc. Что у них с GUI?

С GUI у них дела обстоят откровенно хреново.

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

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

3. Попытки побороть п.2 имеются. Но во-первых, они крайне сложны; во-вторых, всем пофиг.

Но, не так все плохо:

1. Веб интерфейс. Оформить JSON веб-сервис на базе приложения — очень и очень просто. В некоторых случаях, не нужно будет заморачиваться с организацией HTTP-сервера и JSON-оберток на хаскеле. Просто, нужно подходить в задаче внешаблонно и креативно.

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

3. FFI. Внезапно! Пишем логику представления на C/C++, обмениваемся данными через какой-нибудь механизм IPC. Например, тот же хаскелевский FFI.

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

С чего это? gimp полностью аналогичен фотожопу, а в qcad'е я уже давным-давно делаю всякие разные чертежи. Автокад не осилил: по-моему, в нем нагромождена уйма ненужных функций, а нужный функционал фиг найдешь!

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

gimp полностью аналогичен фотожопу

даже не знаю что на это сказать...

а в qcad'е я уже давным-давно делаю всякие разные чертежи

а инженеры BMW и Caterpillar используют автокады/солидворксы.

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

софт который осуществляет банковские транзакции когда ты пользуешься банкоматами тоже открытый?

там какая-то говноподелка на делфи под вендой за $20. Если её открыть, то полгорода твоего на паперти окажутся. Переписывать == деньги. И не малые. А банкиры деньги тратить не привыкли. Они их привыкли ДЕЛАТЬ. И один из способов деланья денег любым банком == рассказывать, какой банк надёжный и богатый. Чем больше людей доверяют банку, тем больше профита этому банку. Разве в их интересах делать какой-нить FireFox, в котором дыры раз в неделю находят (и закрывают, но об этом быдло не задумывается)?

Что касается микросхем, то там другая ситуация. Нет никакого смысла этот софт открывать/закрывать. Если у тебя есть фабрики как у TI, то ты всё равно найдёшь сырцы и мозги к ним. А если у тебя этих фабрик нет, то зачем тебе вообще это ПО? ЧТО ты с ним делать будешь?

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

Если у тебя есть фабрики как у TI, то ты всё равно найдёшь сырцы и мозги к ним.

Ну так эдди говорит, что, мол, опенсорса хватит всем. Де-факто же далеко не всем.

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

банкиры деньги тратить не привыкли

Нет. Расходы на R&D у крупных банков/бирж не маленькие.

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

один жаба-гуру сказал что JVM на 2 порядка умнее и грамотнее среднего типового инженера вроде меня или например тебя. поэтому таки да, JVM сделает всё за тебя ;-)

а я, вместо поклоненія ЖВМ і сыну его ЖЫТ, проверяю (в том чісле і в асмовом лістінге, когда надо). Уже есть опыт улучшенія перформансу в разы только знаючі где кончается разум ЖЫТ.

dzidzitop

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

Софт для сквозного проектирования закрыт и стоит огромных денег.

Это тебе не бутылка пива. У него нет такой характеристики как «розничная цена». У него есть стоимость разработки, стоимость внедрения, стоимость поддержки и проч. И лицензии по типу GPL (или EULA) тоже нет. Не потому-что «закрыт», а не нужна ему EULA. И на сайте производителя не лежит хотя-бы потому, что это штучный товар, а не ширпотреб. А не потому-что «закрыт». К нему это понятие вообще не применимо.

Ну и стоимость разработки того же FireFox тоже не малая. Ещё не известно, что дороже. Просто FireFox нужен Over9000 миллионов хомяков, а вот такое ПО — 3.5 корпорациям. Туда можно и на персональной машине софт возить с эскортом. Это всё равно дешевле, чем FireFox раздавать.

Ты просто не понимаешь, что сравниваешь.

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

фотошопу

gimp

Как это ни печально, при ретуши фотографий в гимпе на уровне сложности «чуть больше нулевой» уже хочется плакать.

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

Софт уровня сложности Intellij IDEA практически не реально написать на С++

Забавно. А почему ты так считаешь? На С++ пишут софт и посложнее.

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

Ты просто не понимаешь, что сравниваешь.

Стоп. Эдди сказал что для всех задач хватит оперсорса. Ему сказали, что это не так и привели примеры.

Причем тут понимаешь/не понимаешь?

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

Там и про «быстрый» С++ рассказывают.

Это сказки все.

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

Это слышал лично от человека из JetBrains. И похожее от человека из DevExperts, кстати там используют C++ и Java в рамках одной конторы. Вывод такой же. Что-то не слишком огромное, низкоуровневое написать на плюсах можно. Huge проект - самоубийство.

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

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

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

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

может энтузиасты и пилят что-то, но интелам и зайлинксам это не надо. инфа 146%

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

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

Верить не нужно ни во что. Нужно тестить. Я тестил. Если у тебя все ок с архитектурой, нету рефлекшена и прочих тормозилок - ява просто зверь.

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

Ява-адепты тут заинтересованы. Они, как правило, являются С++ неосиляторами.

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

Оно у них и не серверах и на рабочих станциях

Этим набор рабочих инструментов не ограничивается.

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

предлагаю напісать быструю реалізацію добавленія подстрокі в StringBuilder.

У меня разніца в «достаточно хорошіх» реалізаціях была в 8 раз. А лучшая реалізація (что для серверной, что для кліентской ЖВМ) была не самой очевідной.

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

а всё потому, что какіе-то дурачкі не умеют проектіровать API с учётом особенностей ЖВМ.

dzidzitop.

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

есть много задач которые попросту не ложатся на это ваше ФП

Что значит «не ложаться»? Нужно устраивать оголтелый выжим производительности из архитектуры? Дык, сваргань же кодогенератор, который будет срезать массу «острых углов». Аппликативное программирование (а не какое-то там сферическое ФП, которое есть в любом языке) сделает задачу намного проще и интереснее.

Вершина некомпетентности — предъявлять претензии, связанные с «сырой» производительностью к GHC, у кодогенератора которого туева хуча уровней индерекции! В GHC не работает даже схемовская/коммонлисповская модель кодогенерации, не говоря уж про сишную. Даже без учета ленивости, иммутабельности и сборки мусора!

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

Допустим используются OCaml/Lisp/Haskell/etc. Что у них с GUI?

походу это языки только для расчетов или серверного проганья, с веб-мордами. я подозреваю что для них даже ODBC/JDBC нет, т.е. с БД не поработать

Понятно, Пастернака читать предмет изучать никто не собирается.

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

Ну, ежели им хочется

ты думаешь, если бы им предоставили свободу выбора, они выбрали бы что-нибудь другое?

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

на Vector.Unboxed большая часть уровней индирекции уйдёт

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

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

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

из своего кармана

ну это должно быть весьма странное место работы)

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

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

по конвейеру пойдет код более близкий к нативному, и результирующий код будет более эффективный.

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

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

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

написанию эффективных элементарных блоков

Написание эффективных элементарных блоков — это к лисперам. У них так вся философия построена.

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

С IO-то масса проблем...

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

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

Бесполезно. Я когда его последний раз носом тыкал в то, что он не в курсе о том, про что говорит «говно», разговор съехал на что-то ещё. Не мечи бисер. Эдик же прямым текстом говорил, что «не программист»

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