Блеск и нищета ООП - страница 7

[Dmitry Fedoseev]

Нашел! Удалось все-таки получить с ООП выше скорость. Да! Преимущества неоспоримые.

[Dmitry Fedoseev]

dimeon:

Давайте тогда все на ассемблере писать. По-любому будет быстрей. 

Не понимаю суть проблемы. НИ разу не видел советника  или индикатора с 1 мБ кода. 

Сам вызов любой функции тоже занимает определенное время . Давайте и от функций откажемся! 

Контроль над большими проектами намного удобней с ООП.  

Кроме того, скорость исполнения кода очень часто не так критична как время пинга до брокера и ответ брокра по приказу. 

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

PS. Что добраться из пукта А в Пункт Б как правило не нужен суперкар или карьерный БЕЛАЗ. Достаточно мопеда! 

Есть тут один кадр, вместо функции пишет код в файл и include.

[Alexey Navoykov]

Integer:

Нашел! Удалось все-таки получить с ООП выше скорость. Да! Преимущества неоспоримые.

Так а код то какой был?

[Dmitry Fedoseev]

meat:
Так а код то какой был?

Вызов iCustom() с различным количеством параметров, для каждого количества параметров свой case, или же свой класс для каждого количества параметров в варианте ООП. 

[Renat Fatkhullin]

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

Этот метод позволит упростить и ускорить виртуальные вызовы во множество программ, работающих с классами.

Результаты примера test.mq4 из первого сообщения в 670 билде:

switch: 172
OOP:    312

цикл пришлось увеличить с 10 000 000 до 50 000 000, чтобы не работать с мизерными замерами времени в 32-64 мс. Показано время в мс, чем меньше число, тем быстрее код.

Вот что получилось с новым компилятором на том же коде:

switch: 157
OOP:     93

ООП с треском выиграл. Но почему?

Сначала виртуальный метод был превращен в обычный, а затем он был заинлайнен и оптимизирован в ноль. Фактически вызов и тело функции полностью пропали, оставив чистый цикл:

  mov     int[i] <- int[0]

$label:
                                        <- тут когда-то было тело, но оно оптимизировалось в ноль
  add     int[i] <- int[i], int[1]
  jlt     int[i], int[50000000] --> $label

Файлы приложены, включая новую бету консольного компилятора. Можете сравнивать любые примеры, используя штатный 670 билд метаедитора(компилятор встроен в него) и консольный компилятор.

Что это доказывает:

1. Тестируется именно качество оптимизатора компилятора
2. Тесты на самом деле надо писать с полным пониманием как все оптимизируется
3. Как я и говорил - показал на существующем примере как можно ввести в заблуждение (ООП вдруг выиграл), если не знать особенности оптимизации кода