Как последовательно перебрать перечисление? - страница 3

 
Alexey Navoykov:

Ну а продемонстрированные тут примеры (case 1: return value1;  case 2: return value2;  case 3: return value3... и т.д.) - это вообще образец глупости.  Адекватный человек поместит все значения в массив и будет просто получать нужное значение по его индексу.  А для обратной задачи воспользуется бинарным поиском.

Двумя руками за красивый код с массивами. Но при написании более быстрой NormalizeDouble, чем штатная, столкнулся с эффектом оптимизатора - красивое решение через const-массив было заметно медленней, чем громоздкое через switch-case. Оставил второй вариант, поскольку NormalizeDouble в тестере ой как много используется. Засунул в инклудник и не смотрю на это страшилище. Зато бэктесты бегают быстрее.
 
fxsaber:
Двумя руками за красивый код с массивами. Но при написании более быстрой NormalizeDouble, чем штатная, столкнулся с эффектом оптимизатора - красивое решение через const-массив было заметно медленней, чем громоздкое через switch-case. Оставил второй вариант, поскольку NormalizeDouble в тестере ой как много используется. Засунул в инклудник и не смотрю на это страшилище. Зато бэктесты бегают быстрее.

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

Тут конечно уже надо отталкиваться от твоих приоритетов. Но имхо, если столь критична скорость, что ты готов изобретать костыли, тогда надо отказываться и от ООП, да и вообще от MQL ;)  Хотя я уверен, при правильном построении кода эта разница в скорости будет не столь существенна.  Это в тестовых замерах ты тупо гоняешь функцию в цикле миллионы раз. А в реальном коде используешь более рационально, не так ли?

 
Alexey Navoykov:

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

Компилятор, если не тупой, обязан был бы const-массив и единственное типовое к нему обращение по индексу превратить в код switch.

Тут конечно уже надо отталкиваться от твоих приоритетов. Но имхо, если столь критична скорость, что ты готов изобретать костыли, тогда надо отказываться и от ООП, да и вообще от MQL ;)  Хотя я уверен, при правильном построении кода разница в скорости будет не столь существенна.  Это в тестовых замерах ты тупо гоняешь функцию в цикле миллионы раз. А в реальном коде используешь более рационально, не так ли?

Скорость не критична, но когда пишу нерационально, ощущаю сильный дискомфорт. Не использовать ООП совсем - не рационально, конечно. Короче, посмотри скромные потуги в кодобазе, что выложил и лежат на проверке не сосчитать уже сколько дней. Там поймешь, откуда костыли в виде того-же NormalizeDouble возникли. Это результат случайного факта от иногда нерациональных реализаций разработчиков.
 
fxsaber:
Компилятор, если не тупой, обязан был бы const-массив и единственное типовое к нему обращение по индексу превратить в код switch.

Дык массив просто конст? А как насчёт статик? Если да, тогда действительно всё должно быть равнозначно. Да и почему "код switch", тут ведь простейшие операции:  сравниваем значение индекса с размером массива/перечисления, если меньше то получаем адрес нужного элемента как адрес массива + индекс, ну и прочитываем оттуда значение. Мне казалось, такая ерунда должно компилироваться одинаково.

Короче, посмотри скромные потуги в кодобазе, что выложил и лежат на проверке не сосчитать уже сколько дней. Там поймешь, откуда костыли в виде того-же NormalizeDouble возникли. Это результат случайного факта от иногда нерациональных реализаций разработчиков.
Не очень понятно, какие "потуги" вы имеете ввиду.   И кстати, как давно вы проводили эти сравнения? Может тогда компилятор был ещё "тупой"?
 
Alexey Navoykov:

Дык массив просто конст? А как насчёт статик? Если да, тогда действительно всё должно быть равнозначно. Да и почему "код switch", тут ведь простейшие операции:  сравниваем значение индекса с размером массива/перечисления, если меньше то получаем адрес нужного элемента как адрес массива + индекс, ну и прочитываем оттуда значение. Мне казалось, такая ерунда должно компилироваться одинаково.

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

Не очень понятно, какие "потуги" вы имеете ввиду.   И кстати, как давно вы проводили эти сравнения? Может тогда компилятор был ещё "тупой"?
Потуги будут видны, как кто-нибудь из модераторов нажмет несколько кнопок и даст добро на публикацию кода в кодобазе. Делал удобное решение для себя, не задумываясь про производительность, а получился выигрыш почти на порядок в билде 1383 32-бита.
 
fxsaber:

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

А, ну тогда всё понятно. Не стоит рассчитывать на излишнюю интеллектуальность компилятора, мол он за вас дооптимизирует плохо-спроектированное решение. Если вы сами поленились/не додумались сделать как надо, мол "статик гораздо сложнее" (хотя чего там сложного, непонятно), то чё ж после этого обвинять компилятор?

 
Alexey Navoykov:

А, ну тогда всё понятно. Не стоит рассчитывать на излишнюю интеллектуальность компилятора, мол он за вас дооптимизирует плохо-спроектированное решение. Если вы сами поленились/не додумались сделать как надо, мол "статик гораздо сложнее" (хотя чего там сложного, непонятно), то чё ж после этого обвинять компилятор?

Добавил к массиву static. Стало работать почти в три раза быстрее switch! На помойку такой switch. Спасибо за подсказку!
 
fxsaber:
Добавил к массиву static. Стало работать почти в три раза быстрее switch! На помойку такой switch. Спасибо за подсказку!

Всегда пожалуйста.  Будет урок на будущее, что надо 7 раз подумать, прежде чем бежать изобретать костыли )

Теперь выходит, что я рано похвалил свитч, точнее его разработчиков.  Значит там всё только через бинарный поиск реализовано, даже когда перечисление идёт с кратным шагом. Нехорошо.

 
Alexey Navoykov:

Всегда пожалуйста.  Будет урок на будущее, что надо 7 раз подумать прежде чем бежать изобретать костыли )

Почти в четыре раза быстрее стандартной NormalizeDouble (build 1395)... это костыль разработчиков.

 
fxsaber:
Почти в четыре раза быстрее стандартной NormalizeDouble (build 1395)... это костыль разработчиков.

Все не без греха )