A Single Line Performance Error - .NET

Наткнулся на шикарную статью от Alois Kraus:

A Single Line Performance Error

        /// <summary>
        /// Logical and of a list of predicates.
        /// </summary>
        public static Predicate<T> And(params Predicate<T>[] ands)
        {
            // return a new delegate which checks if all delegates in the array did return 
            // true for a given item
            return item => ands.All(x => x(item));
        }

Казалось бы, что тут может пойти не так?

О том, как на ровном месте получить 2.5 гб аллокаций, замедлить код в 10 раз, а затем всё геройски разрулить, если профайлера нет под рукой — тынц по ссылке выше

Здравствуйте, Sinix, Вы писали:

S>О том, как на ровном месте получить 2.5 гб аллокаций, замедлить код в 10 раз, а затем всё геройски разрулить, если профайлера нет под рукой — тынц по ссылке выше

— Старайтесь не создавать замыканий, если надо перебрать 20 миллионов элементов
— Got it!

А вообще интересно, да

Здравствуйте, ionoy, Вы писали:

I>А вообще интересно, да

Угу. Мне больше нравится, что народ потихоньку втягивается в использование perfwiew. А то ещё года полтора назад обычная реакция была "ETW? WTF?!"

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, ionoy, Вы писали:

I>>А вообще интересно, да

S>Угу. Мне больше нравится, что народ потихоньку втягивается в использование perfwiew. А то ещё года полтора назад обычная реакция была "ETW? WTF?!"

Я вот даже купил книгу "Writing High Performance .NET Code" в электронном виде, может быть даже ты советовал, не помню. Там как раз про PerfView и ETW очень подробно расписано. Правда пока не дочитал, но полезной и новой информации там реально дофига, так что покупкой остался доволен.

Здравствуйте, ionoy, Вы писали:

I>Я вот даже купил книгу "Writing High Performance .NET Code" в электронном виде, может быть даже ты советовал, не помню. Там как раз про PerfView и ETW очень подробно расписано. Правда пока не дочитал, но полезной и новой информации там реально дофига, так что покупкой остался доволен.

Ага, я её где-то упоминал. Мне она понравилась как книга от практика, этакие вести с полей

Единственное но: мне там не понравились отдльные советы, что-то типа тюнинга шедулера для тасков и настройки пула потоков, если не перепутал. Всё-таки такие вещи надо делать по замерам, а не по чьим-то рекомендациям.

Интерес ещё в том, что автор работает в команде бинга, который как я подозреваю является основным раздвателей пенделей clr team. Во всяком случае большинство оптимизаций gc/jit (время запуска, фоновый gc, уборка в loh итд) добавили в рантайм после того, как .net стал активно использоваться в фронтэнде бинга.

А вообще книгу хорошо читать как дополнение к Pro .NET Performance от Sasha Goldshtein, там как раз упор на теорию и внутреннее устройство рантайма.

Здравствуйте, ionoy, Вы писали:

S>>О том, как на ровном месте получить 2.5 гб аллокаций, замедлить код в 10 раз, а затем всё геройски разрулить, если профайлера нет под рукой — тынц по ссылке выше

I>- Старайтесь не создавать замыканий, если надо перебрать 20 миллионов элементов
I>- Got it!
I>А вообще интересно, да

Вот ещё пища для размышлений: в C++ оба варианта — что с замыканиями, что с ручным условием — выдают идентичный ASM код

LIVE DEMO

auto conjunction = [](auto ...predicates)
{
    return [=](auto x)
    {
        return all([=](auto p){ return p(x); }, predicates...);
    };
};

void test_closure()
{
    vector<int> data(20 * 1000 * 1000);
    auto check_for_zero = conjunction
    (
        [](auto x){ return x > -1; },
        [](auto x){ return x <  1; }
    );
    for(auto x : data)
        if(!check_for_zero(x))
            violation(x);
}

void test_manual()
{
    vector<int> data(20 * 1000 * 1000);
    for(auto x : data)
        if(!(x > -1 && x < 1))
            violation(x);
}

_Z12test_closurev:                      # @_Z12test_closurev
    .cfi_startproc
    .cfi_personality 3, __gxx_personality_v0
.Leh_func_begin1:
    .cfi_lsda 3, .Lexception1
# BB#0:
    pushq    %rbp
.Ltmp12:
    .cfi_def_cfa_offset 16
    pushq    %r14
.Ltmp13:
    .cfi_def_cfa_offset 24
    pushq    %rbx
.Ltmp14:
    .cfi_def_cfa_offset 32
.Ltmp15:
    .cfi_offset %rbx, -32
.Ltmp16:
    .cfi_offset %r14, -24
.Ltmp17:
    .cfi_offset %rbp, -16
.Ltmp6:
    movl    $80000000, %edi         # imm = 0x4C4B400
    callq    _Znwm
    movq    %rax, %r14
.Ltmp7:
# BB#1:                                 # %.lr.ph
    xorl    %ebp, %ebp
    xorl    %esi, %esi
    movl    $80000000, %edx         # imm = 0x4C4B400
    movq    %r14, %rdi
    callq    memset
    movl    $4, %ebx
    jmp    .LBB1_2
    .align    16, 0x90
.LBB1_5:                                # %._crit_edge4
                                        #   in Loop: Header=BB1_2 Depth=1
    movl    (%r14,%rbx), %ebp
    addq    $4, %rbx
.LBB1_2:                                # =>This Inner Loop Header: Depth=1
    testl    %ebp, %ebp
    je    .LBB1_4
# BB#3:                                 #   in Loop: Header=BB1_2 Depth=1
.Ltmp9:
    movl    %ebp, %edi
    callq    _Z9violationi
.Ltmp10:
.LBB1_4:                                #   in Loop: Header=BB1_2 Depth=1
    cmpq    $80000000, %rbx         # imm = 0x4C4B400
    jne    .LBB1_5
# BB#8:                                 # %._crit_edge
    testq    %r14, %r14
    je    .LBB1_9
# BB#12:
    movq    %r14, %rdi
    popq    %rbx
    popq    %r14
    popq    %rbp
    jmp    _ZdlPv                  # TAILCALL
.LBB1_9:                                # %_ZNSt6vectorIiSaIiEED2Ev.exit
    popq    %rbx
    popq    %r14
    popq    %rbp
    retq
.LBB1_6:
.Ltmp11:
    movq    %rax, %rbp
    testq    %r14, %r14
    je    .LBB1_11
# BB#7:
    movq    %r14, %rdi
    callq    _ZdlPv
    movq    %rbp, %rdi
    callq    _Unwind_Resume
.LBB1_10:
.Ltmp8:
    movq    %rax, %rbp
.LBB1_11:                               # %_ZNSt6vectorIiSaIiEED2Ev.exit2
    movq    %rbp, %rdi
    callq    _Unwind_Resume
.Ltmp18:
    .size    _Z12test_closurev, .Ltmp18-_Z12test_closurev
    .cfi_endproc

_Z11test_manualv:                       # @_Z11test_manualv
    .cfi_startproc
    .cfi_personality 3, __gxx_personality_v0
.Leh_func_begin2:
    .cfi_lsda 3, .Lexception2
# BB#0:
    pushq    %rbp
.Ltmp25:
    .cfi_def_cfa_offset 16
    pushq    %r14
.Ltmp26:
    .cfi_def_cfa_offset 24
    pushq    %rbx
.Ltmp27:
    .cfi_def_cfa_offset 32
.Ltmp28:
    .cfi_offset %rbx, -32
.Ltmp29:
    .cfi_offset %r14, -24
.Ltmp30:
    .cfi_offset %rbp, -16
.Ltmp19:
    movl    $80000000, %edi         # imm = 0x4C4B400
    callq    _Znwm
    movq    %rax, %r14
.Ltmp20:
# BB#1:                                 # %.lr.ph
    xorl    %ebp, %ebp
    xorl    %esi, %esi
    movl    $80000000, %edx         # imm = 0x4C4B400
    movq    %r14, %rdi
    callq    memset
    movl    $4, %ebx
    jmp    .LBB2_2
    .align    16, 0x90
.LBB2_5:                                # %._crit_edge5
                                        #   in Loop: Header=BB2_2 Depth=1
    movl    (%r14,%rbx), %ebp
    addq    $4, %rbx
.LBB2_2:                                # =>This Inner Loop Header: Depth=1
    testl    %ebp, %ebp
    je    .LBB2_4
# BB#3:                                 #   in Loop: Header=BB2_2 Depth=1
.Ltmp22:
    movl    %ebp, %edi
    callq    _Z9violationi
.Ltmp23:
.LBB2_4:                                #   in Loop: Header=BB2_2 Depth=1
    cmpq    $80000000, %rbx         # imm = 0x4C4B400
    jne    .LBB2_5
# BB#8:                                 # %._crit_edge
    testq    %r14, %r14
    je    .LBB2_9
# BB#12:
    movq    %r14, %rdi
    popq    %rbx
    popq    %r14
    popq    %rbp
    jmp    _ZdlPv                  # TAILCALL
.LBB2_9:                                # %_ZNSt6vectorIiSaIiEED2Ev.exit
    popq    %rbx
    popq    %r14
    popq    %rbp
    retq
.LBB2_6:
.Ltmp24:
    movq    %rax, %rbp
    testq    %r14, %r14
    je    .LBB2_11
# BB#7:
    movq    %r14, %rdi
    callq    _ZdlPv
    movq    %rbp, %rdi
    callq    _Unwind_Resume
.LBB2_10:
.Ltmp21:
    movq    %rax, %rbp
.LBB2_11:                               # %_ZNSt6vectorIiSaIiEED2Ev.exit3
    movq    %rbp, %rdi
    callq    _Unwind_Resume
.Ltmp31:
    .size    _Z11test_manualv, .Ltmp31-_Z11test_manualv
    .cfi_endproc

Здравствуйте, ionoy, Вы писали:

I>Здравствуйте, Sinix, Вы писали:

S>>Здравствуйте, ionoy, Вы писали:

I>>>А вообще интересно, да

S>>Угу. Мне больше нравится, что народ потихоньку втягивается в использование perfwiew. А то ещё года полтора назад обычная реакция была "ETW? WTF?!"

I>Я вот даже купил книгу "Writing High Performance .NET Code" в электронном виде, может быть даже ты советовал, не помню. Там как раз про PerfView и ETW очень подробно расписано. Правда пока не дочитал, но полезной и новой информации там реально дофига, так что покупкой остался доволен.

Сам разработчик perfview -- Vance Morrison -- эту книгу советовал. Он там и отзыв оставил.

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вот ещё пища для размышлений: в C++ оба варианта — что с замыканиями, что с ручным условием — выдают идентичный ASM код

Еще бы. .NET не умеет инлайнить лямбды.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Вот ещё пища для размышлений: в C++ оба варианта — что с замыканиями, что с ручным условием — выдают идентичный ASM код

H>Еще бы. .NET не умеет инлайнить лямбды.

А в чём, кстати, загвоздка?

Здравствуйте, Sharov, Вы писали:

S>Сам разработчик perfview -- Vance Morrison -- эту книгу советовал. Он там и отзыв оставил.

Что-то содержание не впечатляет

Впихнуть в 330 страниц машину тьюринга, raid, api win/java/google, agile, закон Амдала, параметризацию sql-запросов, теорию массового обслуживания и её применимость к xml web services...

Мне кажется, автору должно понравиться вот это.

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

В общем, если тянет на хардкор, потратьте время на Рихтера, FDG от Krzysztof Cwalina и Brad Abrams, .net pro performance и Руссиновича. Ну и C# 5.0 Unleashed: Bart De Smet, чтобы заполировать. Всяко полезней будет.

Здравствуйте, ionoy, Вы писали:

I>А в чём, кстати, загвоздка?

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

Здравствуйте, Sinix, Вы писали:

S>Наткнулся на шикарную статью от Alois Kraus

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

Вопросы по грабле:
1. Суть проблемы — много распределений памяти для лямбды, комбинирующей вычисления. Но ведь где-то писалось, что .NET не выкидывает объекты просто так — если запрошено распределение объекта того же типа, который ранее был освобождён, .NET может вернуть тот же кусок памяти без дополнительных поисков. Почему же тогда тормоза?
2. Отдельное нарекание на комбинатор: "проверить, что элемент удовлетворяет N условиям" и "проверить, что все элементы удовлетворяют условию У1, потом У2..." — разные вещи с очевидным преимуществом первого варианта.
3. Если даже допустить, что неоднократно восхваляемая самим же мелкософтом LINQ не так хороша, почему мы узнаём об этом только сейчас, да и то от посторонних людей? Где были глаза у "архитекторов" этого "универсального поделия"? Разве не проводилось никаких тестов? Разве их архитектурные решения не высвечивали очевидные сценарии, где LINQ лажает? А проводились хоть какие-то сравнения с другими вариантами обработки массивов — например, ranges из D?

Короче, за предупреждение о грабле — спасибо, но выводы вы делать не умеете — упомянутые книжки пусть читают *овнокодеры микрософта — это ИХ КОСЯК. Программист должен думать о задаче и как её решить _идеально_спроектированными_и_вылизанными_ инструментами, а "копаться в кишках" — это и есть прямая задача архитекторов инструментов, за что и получают двойное бабло.

Здравствуйте, ionoy, Вы писали:

I>А в чём, кстати, загвоздка?

Проблема Неуловимого Джо. Никто не заморачивался, другими словами.

Со временем вполне возможно добавят, по крайней мере в предкомпилированный код. В .net native трансляция возложена на бэкенд от msvc, так что затык, как я понимаю, только в безопасности оптимизаций. Для инлайна лямбд принципиальных проблем нет.

Здравствуйте, hardcase, Вы писали:

H>В .NET нет таких сущностей как "лямбда" и "замыкания". Они реализуются языками программирования через классы и делегаты. Выделять память на стеке под экземпляры классов .NET не умеет
Так это ответственность рантайма, не CTS. В зависимости от реализации может и поменяться.

H>инлайнить виртуальные вызовы вроде как тоже.
Ну, инлайнить — нет, а вот хак для интерфейсов есть, и давно (см раздел The JIT's Approach). Для делегатов реализовать ту же комбинацию (проверка на target method + прямой jump) в принципе, не проблема. Другое дело, что вся эта радость никак не докуменирована и может свободно меняться от релиза к релизу.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Sharov, Вы писали:

S>>Сам разработчик perfview -- Vance Morrison -- эту книгу советовал. Он там и отзыв оставил.

S>Что-то содержание не впечатляет

S>Впихнуть в 330 страниц машину тьюринга, raid, api win/java/google, agile, закон Амдала, параметризацию sql-запросов, теорию массового обслуживания и её применимость к xml web services...

S>Мне кажется, автору должно понравиться вот это.

S>И это я всего до двухсотой страницы дошёл. Очень похоже на полупереваренный аналог курса "Теория информационных процессов и систем", только с выкинутой нафиг теорией игр (за избыток матана).

Вот не согласен, хоть пока (а с таким курсом еще не скоро, если pdf не качать и печатать) и не читал.
Машина Тьюринга и проч. теория наверное на пол страницы. А так в основном "common cases & pitfalls", что кмк полезно.
И как раз наличие тмо и проч. математики меня наоборот радует, поскольку позволяет к этому делу подойти с научным
подходом и соотв. наработанным инструментарием. Что опять же позволяет
понять и быстро исправить всяческие bottleneck'и, а в лучшем случае вообще сразу предотвратить.

S>В общем, если тянет на хардкор, потратьте время на Рихтера, FDG от Krzysztof Cwalina и Brad Abrams, .net pro performance и Руссиновича. Ну и C# 5.0 Unleashed: Bart De Smet, чтобы заполировать. Всяко полезней будет.

FDG есть и читал (вероятно не все), но не очень ясно каким они сюда боком. Т.е. понятно, но крайне незначительно
они цепляют производительность -- "дизпоузьте все что дизпоузится". Руссинович про устройство венды? Дельно, но не самое
актуальное чтение для дотнет разботчика в контексте озвученных книг, хотя книга очень полезная, ибо закладывает базис
понимания работы ОС. Вообще, кмк, прозводительность такая штука, где
безусловно нужно знать и понимать азы. И книга, приведенная мной выше, думается их дает.
Но также важно, если не важнее,уметь пользоваться инструментарием, как платным -- dottrace и т.п.,
так и бесплатным -- perfview, например.
У меня к сожалению, слабо с теорией, а из инструментов ничего кроме dottracе'а и не использовал.

Здравствуйте, Sharov, Вы писали:

S>И как раз наличие тмо и проч. математики меня наоборот радует, поскольку позволяет к этому делу подойти с научным
S>подходом и соотв. наработанным инструментарием. Что опять же позволяет
S>понять и быстро исправить всяческие bottleneck'и, а в лучшем случае вообще сразу предотвратить.
А вот меня нет. Потому что любая мат модель должна использоваться по месту, или не использоваться вообще. Иначе получается math for lulz и никакого практического выхлопа.

Попробую объяснить мысль. Сорри, немного эмоционально, но так получилось что я некоторое время как раз разгребал завалы идеальных решений, наболело

Я таки не поленился и скачал книгу (потом я честно её выкачал обратно, так что ничего не было). Это самый обычный вузовский учебник, со всем прелестями типа упоминания win 2000 в 2009 году, черно-белыми малопонятными графиками по трём точкам без источников и формулами из вики. Поэтому к книге я даже не буду возвращаться, от неё один фиг толка не будет.

Так вот. В перфомансе есть всего два кита: это алгоритмы и измерения. Первое позволяет оценить порядок величин плюс-минус тапок, второе — проверить соответствие реальности и ожиданий и найти виноватого. С научным подходом с обеих сторон тоже всё понятно. В 99% случаев, O-нотация и перцентиль (или вообще среднее арифметическое), вот и вся rocket science. В теории, мы можем прикрутить ещё что-то наукообразное на этапе перевода алгоритма в исполняемый код, но к обсуждаемой теме это не имеет ровным счётом никакого отношения.

Возвращаемся к матмоделям. В книге (ну да, я обещал, но кто помнит дальше одного абзаца?

) в самом "практическом" разделе "CASE STUDY I: QUEUING THEORY APPLIED TO SOA" тупо берутся готовые формулы из M/M/1 Open Model и... нет, я просто оставлю вот эту картинку:

That's it. Глава закончилась, дальше вопросы "для закрепления".

Сорри, но к научному подходу(tm) это имеет не больше отношения, чем барби — к компьютерной инженерии.

Собственно, две цитаты

5.9 VALIDITY OF THE SOA PERFORMANCE MODEL
... the SOA performance model was more accurate with the smaller utilizations or lighter loads prior to the knee of the curve.

This concludes our ﬁrst case study on applying queuing theory to predicting the performance and scalability of the SOA-based enterprise software applications.

5.10 SUMMARY
...

и

A PILLOW. SKIPPER HITS HER SISTER WITH A PILLOW. PLAYFULLY. Skipper has just lost her homework, all her music files and her laptop, but all she's moved to is STATUS: PILLOW FIGHT.

попробуй угадать, какая откуда

S>>В общем, если тянет на хардкор, потратьте время на Рихтера, FDG от Krzysztof Cwalina и Brad Abrams, .net pro performance и Руссиновича. Ну и C# 5.0 Unleashed: Bart De Smet, чтобы заполировать. Всяко полезней будет.

S>FDG есть и читал (вероятно не все), но не очень ясно каким они сюда боком. Т.е. понятно, но крайне незначительно
FDG относится к обязательным для прочтения книжкам, т.к. она помогает правильно поставить мозги и не писать код ради кода

Вот офигенный пример. Предлагаемый в FDG подход имеет куда больше отношения к научному чем "формулы и графики есть == всё ок". И, если натягивать сову на глобус, то основной принцип в FDG

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.

вполне относится и к перформансу. Интересует производительность? Начни с верифицируемых примеров.

S> Руссинович про устройство венды? Дельно, но не самое актуальное чтение для дотнет разботчика в контексте озвученных книг, хотя книга очень полезная, ибо закладывает базис понимания работы ОС.
+1 Его и деСмета давал уже для веса. Иначе несолидно маленький список получался

S>Вообще, кмк, прозводительность такая штука, где безусловно нужно знать и понимать азы.
Угу. Но тогда надо или лезть в теорию по конкретной предметной области, где всё уже хожено и перехожено до нас, или ограничиться азами из теории алгоритмов и структур данных (причём для типового опердня в 99% случаев хватает знания O-нотации).

S>Но также важно, если не важнее,уметь пользоваться инструментарием, как платным -- dottrace и т.п.,
S>так и бесплатным -- perfview, например.
S>У меня к сожалению, слабо с теорией, а из инструментов ничего кроме dottracе'а и не использовал.
А там нет никакой магии, только практика. Ищем самое тормозное место (обычно это узел в дереве с высоким весом, который вызывает хелперы или системные API), определяем проблему, чиним, повторяем.
Основные идеи классно расписаны в начале книги у Ben Watson (.net performance).

	От:	Sinix
	Дата:	23.12.14 07:06
	Оценка:	148 (6)

От:	ionoy	www.ammyui.com
Дата:	23.12.14 07:30
Оценка:	+1

	От:	Sinix
	Дата:	23.12.14 07:55
	Оценка:

От:	ionoy	www.ammyui.com
Дата:	23.12.14 08:00
Оценка:	10 (1)

	От:	Sinix
	Дата:	23.12.14 08:22
	Оценка:	8 (3)

	От:	Evgeny.Panasyuk
	Дата:	23.12.14 09:50
	Оценка:	39 (3)

От:	hardcase	http://nemerle.org
Дата:	23.12.14 11:53
Оценка:	+1