А что по скорости?

[stdray]

Регулярно можно видеть рассуждения, мол напишем за 20 минут наш проект на фичастом языке сверхвысокого уровня H, а критические по производительности участки кода сделаем на быстром низкоуровневом языке C. Что-то у меня ощущение, что об этом чаще говорят, чем применяют. Я поспрашивал знакомых программистов, тех что поближе, - подобным не занимаются. Один, говорит, пытался, а потом просто стал писать на плюсах. Даже в интернетах, читал о подобном только в исполнении levgem и lionet. В связи с чем пара вопросов:

1) Переписываете ли вы куски кода на низкоуровневом языке в угоду производительности?
2) Какой язык вы для этого используете?

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

Comments

[proofit404.livejournal.com]

Первое что пришло на ум это blender и mypaint - ядра проектов написаны на c и c++ соответственно, а вот всякая там скриптота на python

Сам таким не занимаюсь, т.к. за производительностью я ещё не гонялся.

[stdray.livejournal.com]

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

[proofit404.livejournal.com]

пайтон конечно ниразу не язык моей мечты
но вот как скриптота в том же 3D вполне себе состоялся
на равне со своим собственным скриптоподелием поддержка пайтона есть в 90% графических пакетов

за дотнэт не знаю, но к примеру opencv к нему всётаки прикрутили для скорости опять таки для задач с изображениями

[stdray.livejournal.com]

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

[proofit404.livejournal.com]

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

[stdray.livejournal.com]

Если один процессор, то все понятно, а если распараллеливать можно, то все не так однозначно.

[izard.livejournal.com]

Переписываю ли я? Да 50% работы как консультанта по производительности из этого состоит. Правда, переписываю или сразу на асме, или на С с интринзиками.

[stdray.livejournal.com]

А на чем как написаны проекты, которые вы консультируете?

>сразу на асме
Ого, а не слишком сурово? Как это потом поддерживать или запустить на новом_классном_дорогом_интелловском процессоре?

[izard.livejournal.com]

Встречались C, C++, Erlang, Java, пара экзотических внутриклиентских паскалеподобных языков.

Сложности с последующей поддержкой не такие большие, т.к.
1. 100% моих клиентов пишут софт, который не предназначен для широкого распространения (максимум - десятки тысяч контроллируемых инсталляций), и предназначен для работы на ограниченном множестве железа.
2. На асме переписывается несколько hot_fucntion_N, старая функция никуда не выкидывается, остается на всякий случай или как часть документации.
3. Главный asset Интел - совместимость. Код, откомпилированный на 8086, запустится на Core i7 (с некоторыми условиями и ограничениями, но условия в принципе выполнимы, а ограничения редки и документированы). Но это 35 лет разницы. В пределах 15 лет (типичное время жизни софта, с которым я работаю) проблем совместимости вообще нет.
4. Однако в новом_классном_дорогом_интелловском процессоре могут появится новые инструкции, которые позволят еще ускорить код - тогда клиент is welcome to be my guest еще раз.
5. Бывают регрессии по производительности с новыми архитектурами. Обычно я могу гарантировать, что в моем коде их не будет в течении 2 следующих поколений.

[zhengxi.livejournal.com]

фичастая clojure и низкоуровневая java.
я так не делаю, но видел подобное на github

[proofit404.livejournal.com]

>>> низкоуровневая java
если без clojure контекста, то звучит немного странно
интересно на каких задачах java уделала clojure по производительности?

[thedeemon.livejournal.com]

Практически на всех, я полагаю.
У clojure с ее динамикой нет причин быть быстрой, и на тестах shootout'a она отстает в разы.

[proofit404.livejournal.com]

тоесть следуя этой логике скала должна бы быть пошустрее?

[thedeemon.livejournal.com]

Да.

[proofit404.livejournal.com]

Спасибо, а sbcl вродебы сейчас самый шустрый из лиспов?

[thedeemon.livejournal.com]

Точно не знаю, но вроде бы да.

[stdray.livejournal.com]

Ну, джава: jit-компиляция есть, сборщик мусора есть, стэка нет. Оно может простое, но точно не низкоуровневое.

[gds.livejournal.com]

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

[dr-hyder.livejournal.com]

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

[stdray.livejournal.com]

Вот люди даже с Erlang не брезгуют:
http://lionet.livejournal.com/84884.html
http://levgem.livejournal.com/386524.html
У них точно нет проблем с горизонтальным масштабированием.

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

[dr-hyder.livejournal.com]

Раз переписывают, значит есть какие то требования к производиетельности той части что горизонтально не масштабируется(критично время отклика например). Проще говоря занимаются миддлвэр'ом скорее всего, Иначе велика вероятность что просто переизобретают какой нибудь велосипед(что бывает нужно, да).

[metaclass.livejournal.com]

Я знаю только один пример такого - GNURadio - обертка на питоне и вычисления на C++
еще numpy/scipy вроде тоже.

А у меня все вычисления упираются в "как наиболее эффективно прочесть наименьшую часть БД размером в 10-50 гб и минимизировать расстояние от чтения до вычисления", так что мне вряд ли поможет переписывание на низкоуровневых языках.

[thedeemon.livejournal.com]

Другой известный пример - mercurial. Большая часть питон, какие-то важные по скорости куски на Си.

[stdray.livejournal.com]

Я уже понял, что куда в питоне не глянь, увидишь обернутые куски на сях.

[satanus.livejournal.com]

Любой проект питона - большая часть питон, какие-то важные по скорости куски на си. Как и сам питон.

[(Anonymous)]

FreeArc так сделан, например. Hackell + С. Сейчас вот в этот самый момент решаю эту проблему. Весь проект на Немерле, небольшая горячая часть на С++. Сценарий примерно такой - подготовка(генерация) сложных структур данных(деревья, автоматы) на Nemerle. Затем все эти структуры данных перемещаются в фиксированную память (System.Runtime.InteropServices.Marshal.AllocHGlobal, System.Runtime.InteropServices.Marshal.StructureToPtr). После в С++ кидается указатель на все это безобразие и он может ходить по этим структурам данным как по своим. Проблема в поддержке описания одних и тех же структур данных на обоих языках. Меняем в одном месте, нужно менять в другом месте. Нужно строго следить за выравниванием и порядком следования полей. Да что там, просто чтобы константу расшарить между двумя языками - уже проблема. Короче мне все это надоело и я написал (на Nemerle, естественно) небольшую утилиту, которая воспринимает описание структур данных на С-образном языке и выдает текст с описанием этих структур данных на С++, Nemerle и богомерзком C# (Ну потому, что в Немерле пока нет полноценной поддержки указателей. Указатель на int уже можно описать, а указатель на структуру еще нельзя.) Далее все это можно подключать как в .NET, так и в C++. Сейчас поддерживаются неймспейсы, структуры, шаблоны С++, енумы, тайпдефы. Про шаблоны... Например - у нас есть описание шаблонов:
LinkedListNode
{
T value;
LinkedListNode* next;
}

class LinkedList
{
LinkedListNode* root;
...
}
typedef LinkedList MyList;
typedef LinkedList HisList;
В С++ это передается как есть, для Шарпа генерируется следующие структуры LinkedListNode_instantation_int, LinkedList_instantation_int, LinkedListNode_instantation_SomeStruct, LinkedList_instantation_SomeStruct:
LinkedListNode_instantation_int
{
int value;
LinkedListNode* next;
}

class LinkedList_instantation_int
{
LinkedListNode_instantation_int *root
}
Для HisList тоже самое. Что-то типа инстанцирования шаблонов. Все это с поддержкой области видимости. LinkedList < SomeTemplate < SomeOtherTemplate < int > > > то же поддерживается. Вопрос - не велосипед ли я изобретаю?
P.S.: Перед тем, как прочел этот пост, сидел отлаживал описанную выше утилиту.

[stdray.livejournal.com]

>Весь проект на Немерле, небольшая горячая часть на С++... подготовка(генерация) сложных структур данных(деревья, автоматы) на Nemerle... С++ кидается указатель на все это безобразие и он может ходить по этим структурам данным как по своим.

Если структуры действительно сложные, то писать обходчики на С++ - это адский ад. Какие преимущества дает цепепе? Какие преимущества перед unsafe C#, который достаточно быстр (http://stdray.livejournal.com/73674.html?thread=377546#t377546) и может простым и прозрачным образом общаться со структурами данных, описанными на Nemerle?

[(Anonymous)]

Обходчики - не ад. Вот генерация всех этих деревьев, конечных автоматов - вот это реально ад (алгоритмы на строках сейчас мой фокус). Писать все это на С++ - застрелиться легче.

Я не знаю насколько ансейф С# быстрый в реальности, а не на тестах. В С++ я почти уверен, в С# не уверен. Тем более на плюсах у меня есть немалый опыт, на С# опыта нет, я сразу начал писать на Немерле. Шаблоны опять же. OpenMP опять же. Куча нативных библиотек опять же. И т.д.

[stdray.livejournal.com]

>Тем более на плюсах у меня есть немалый опыт, на С# опыта нет, я сразу начал писать на Немерле.

Если из Nemerle убрать паттерн-матчинг, макросы и TCO, то получится Сишарп. Что касается обхода структур, то я не понимаю, на чем там можно в плюсах сэкономить. Адресная арифметика здесь мало применима, а для распараллеливания есть PLINQ, async/await (в C#5 и Немерле) и Async монада для Nemerle.

[(Anonymous)]

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

В С++ я почти уверен, в С# не уверен. На С++ у меня большой опыт, на шарпе опыта нет почти. Темплейты опять же, куча нативных библиотек, OpenMp, и т.д.

[thedeemon.livejournal.com]

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

[wizzard]

Python+C, отлично работало.

Еще Javascript+C был.

[stdray.livejournal.com]

Я уже понял, что питон по другому не работает.

>Еще Javascript+C был.
Это еще что за эксперименты?

[wizzard]

chromium как гуй к приложению

кстати, ЕМНИП, Steam так устроен (морда на HTML, остальное на плюсах)

[satanus.livejournal.com]

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

[enternet.livejournal.com]

Я когда-то давно по неопытности писал extended stored procedures на C для MSSQL7. Потом бросил заниматься этой дурью, т.к. у MSSQL есть хранимые процедуры для дергания COM-объектов, что (1) отвязывает от С и (2) часто ничего писать не нужно, т.к. нужный объект в системе уже есть. Ну и (3) COM c некоторыми нюансами можно делать in-process, т.е. ничего на производительности не терять даже в теории. А потом и это бросил делать, т.к. попадающиеся задачи требовали других методов оптимизации - головой.

Но пример, когда С был реально нужен у меня есть - писал когда-то индексатор для MS Indexing Service, там производительность была критична и заголовки портировать на что-то не хотелось. Т.е. изначально отладил сам алгоритм на дельфи, а потом итог оформил на С.

[si14.livejournal.com]

Пришлось один раз, но case достаточно специфичный — впилить в Erlang мутабельные циклические массивы. Получилось https://github.com/band115/ecirca .

[stdray.livejournal.com]

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

[si14.livejournal.com]

За исключением куска по ссылке — да, всё отлично работает. На самом деле, тормоза эрланга очень сильно overrated в общем случае.

[levgem.livejournal.com]

При вычислении mpeg crc32 эрланг работает в 40 раз медленнее чем аналогичный кусок а С.
По прошестви пары лет я выкинул с-шный кусок потому что это очень неудобно таскать такие экстеншны. И ничего в общей скорости не поменялось.

Там где скорости эрланга не хватает возможно и скорости plain c может не хватить, потребуются всякие intrinsic