Здравствуйте, Воронков Василий, Вы писали:
H>>Что-то я сомневаюсь в том, что C# компилятор производит оптимизацию №2. H>>На каком количестве разреженных вхождений бинарный поиск будет в среднем быстрее линейного?
ВВ>
ВВ> switch (x)
ВВ> {
ВВ> case 0: x += 1; break;
ВВ> case 5: x += 1; break;
ВВ> case 100: x += 1; break;
ВВ> case 200: x += 1; break;
...
ВВ>
А можно объяснить как приведенный код отвечает на поставленный вопрос?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Подумай сам. Глупо ведь на основании синтетических тестов вводить оптимизации которые замедляют реальные приложения?
А какой прирост (в процентах) скорости работы реального приложения в виде компилятора дала реализация Switch?
Здравствуйте, Воронков Василий, Вы писали:
ВВ>А какой прирост (в процентах) скорости работы реального приложения в виде компилятора дала реализация Switch?
В релизе при константе 12 ~ +5 секунд на двух минутах. При константе 3 ~ -5 секунд.
Короче незначительный.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, VladD2, Вы писали:
VD>>Подумай сам. Глупо ведь на основании синтетических тестов вводить оптимизации которые замедляют реальные приложения?
ВВ>А какой прирост (в процентах) скорости работы реального приложения в виде компилятора дала реализация Switch?
В процентах не считал. Но разница в несколько секунд сборки самого себя.
Здравствуйте, VladD2, Вы писали:
VD>Кстати, у меня тут была одна идея... Вместо использования виртуального метода можно в каждый вариант (в базовый тип) добавлять поле типа int (или даже byte) и инициализировать его для каждого своим значением, и проверять потом именно его.
VD>Это немного увеличит объем памяти занимаемый вариантами и потребует лишний инструкции при создании их экземпляров, но возможно это увеличит скорость ПМ.
Попробовал — стало медленнее (заменил виртуальный вызов обращением к полю _N_VariantCode).
Патч можно забрать тут.
Здравствуйте, hardcase, Вы писали:
H>Попробовал — стало медленнее (заменил виртуальный вызов обращением к полю _N_VariantCode). H>Патч можно забрать тут.
То есть увеличение потребления памяти на один вариант влияет на производительность сильнее устранения виртуального вызова на один match?
Это хороший урок... значит есть смысл оптимизировать в компиляторе использование памяти.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, hardcase, Вы писали:
H>>Попробовал — стало медленнее (заменил виртуальный вызов обращением к полю _N_VariantCode). H>>Патч можно забрать тут.
C>То есть увеличение потребления памяти на один вариант влияет на производительность сильнее устранения виртуального вызова на один match? C>Это хороший урок... значит есть смысл оптимизировать в компиляторе использование памяти.
Здравствуйте, hardcase, Вы писали:
H>Ну, я не исключаю что у меня просто руки кривые.
Ну, вроде бы в патче ляпов не видно... единственное, может быть прокол в самом тестировании... ты одинаковые версии кода компилировал для измерения производительности?
Здравствуйте, catbert, Вы писали:
C>То есть увеличение потребления памяти на один вариант влияет на производительность сильнее устранения виртуального вызова на один match? C>Это хороший урок... значит есть смысл оптимизировать в компиляторе использование памяти.
Это ничего не значит. Там факторов выше крыши.
Скажем там есть статический вызов который тоже нужно устранить. Без него рассклд может быть совсем другим.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
