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

[stdray]

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

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

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

Comments

[proofit404.livejournal.com]

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

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

[izard.livejournal.com]

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

[zhengxi.livejournal.com]

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

[gds.livejournal.com]

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

[dr-hyder.livejournal.com]

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

[metaclass.livejournal.com]

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

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

[(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.: Перед тем, как прочел этот пост, сидел отлаживал описанную выше утилиту.

[thedeemon.livejournal.com]

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

[wizzard]

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

Еще Javascript+C был.

[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 .

[levgem.livejournal.com]

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

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