Re: Еще о тестировании производительности

[Serge]

Идея функционального ускорения в двух словах следующая:
во первых, бывают ситуации, когда какая-то медленная операция не обязательно должна случиться немедленно (тут действует просто lazy evaluation), во вторых есть специальные алгоритмы, которые на типичном случае позволяют просто избежать совсем обработки каких-то кусков (либо используют memoization чтобы не исполнять этот кусок), и эти алгоритмы очень хорошо реализуются именно в функциональной нотации (хотя можно и императивом все сделать, но оно получается очень трудночитаемо и трудноотлаживаемо).
В книгах приводят пример среднесбалансированного двоичного дерева (не идеально сбалансированного) - идеальная балансировка дерева дорогая операция, потому что нужно просматривать всё дерево, но хитрая математика позволяет добиться очень приличной балансировки без просмотра существенного процента дерева.

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

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

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

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

15.06.2011, 19:09, "Serg Gulko" <s.gulko at gmail.com>:
> Можешь дать пример такой задачи?
>
> On 15 июн, 10:55, Serge <si... at yandex.ru>; wrote:
>
>>  Согласен.
>>
>>  Я просто говорю что эта задача _неудобная_ для Перл, как раз своей _простотой_.
>>
>>  А на более сложных примерах всё может быть намного лучше, вплоть до того что на Перл будет быстрее чем на Яве.
>>
>>  15.06.2011, 18:47, "Serg V. Gulko" <s.gulko at gmail.com>;:
>>
>>  Сережа, когда ты пишешь маленькую программу для себя или для других, чтобы показать свою крутизну - я только 'за' функциональное программирование:) Но как только ты начинаешь делать большое приложение, да еще и не один, здравый смысл(ну, или зашоренность моего разума) начинает подсказывать, что ООП - это хорошая штука. Мой пример прост, как угол дома - последовательный проход по элементам массива с вычислениями. Если в такой простой задаче(а в финансах, в основном, это проходы по массивам значений) я получил разницу в 40 раз, то запускать более тяжелый пример как то уже и не хочется:)
>>  В Срд, 15/06/2011 в 18:34 +0400, Serge пишет:Это Перл. И если хочешь из него выжать максимум, нужно не писать как на Си, а использовать возможности Перл - применять функциональные алгоритмы. Конкретно в этом примере мало что можно наловить, ибо он как забивание гвоздей ифуной ;) А вот если ты найдешь чего-то посложней, там можно будет исполнить. 15.06.2011, 18:19, "Serg Gulko" <s.gulko at gmail.com>;: > Можешь дать свой вариант Order? Пусть там будет задействовано только > несколько полей - open_price, side, size, pl, close_price. > Кстати, я не согласен насчет неприменимости ООП в высоконагруженных > задачах. > On 15 июн, 10:13, Oleg Alistratov <a... at ali.org.ua>;;; wrote: > >>  On 15.06.2011 17:09, Serg V. Gulko wrote: >>>>  мне  кажется,что  можно  переписать  алгоритм  и  ускорить  работу  скрипта  на  perl >>>  Готов рассмотреть идеи оптимизации. Там для построения простых >>>  getter/setter-ов используется относительно быстрый >>>  Class::Accsssor::Fast. Заменить можно только на ручное формирование >>>  полей, но разве это вариант? Думаю, если туда затолкать огробло Moose, >>>  там тест и за минуту не закончился бы. >>>  В любом случае - любые предложения по оптимизации приветствуются:) >>  Например, блессануть не хеш, а массив. Доступ к членам по числовому >>  индексу будет таки побыстрее, чем по текстовому. Это если все же хочется >>  оставить объекты, чего в нагруженной вычислительной задаче лучше избежать. >> >>  -- >>  Олег