На текущем уровне процессоров можно забыть про тормоза double математики - Общее обсуждение

Renat Fatkhullin 2019.01.15 21:37 #151

На текущем уровне процессоров можно забыть про тормоза double математики. Нет тормозов.

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

С учетом 64 битного кода и нашего компилятора нужно забыть про integer в классе задач, основанном на double вычислениях..

Вот предыдущий пример разбора попыток оптимизации Николая: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

Компилятор сумел вычисления двух 64 битных double корней из разных выражений объединить в одной 128 битной ассемблерной команде. При работе с double математикой категорически не рекомендуется прыгать/конвертироваться в integer типы. Там на конвертации дикие процессорные(не наши) оверхеды.

Ошибки, баги, вопросы

2018.03.11
www.mql5.com

Общее обсуждение: Ошибки, баги, вопросы

Интересное мнение про ООП Ошибки, баги, вопросы Скорость выполнения функций ceil(),round(),floor()

Renat Fatkhullin 2019.01.15 21:42 #152

Nikolai Semko:

ничего не надо округлять

вот тебе скрипт, как наглядный пример.

Запусти сначала с параметрами по умолчанию (со сглаженными окружностями и координатами и размерами типа double)

а потом запусти с параметром typ = not_smoothed_circles (с несглаженными окружностями и координатами и размерами типа int - из класса CCanvas)

Шикарно получилось.

У меня без сглаживания 347 кадров в секунду, а со сглаживанием 97 на канвасе в 2100х550 пикселей.

Для информации, у нас стоит ограничитель частоты апдейтов окна в 500 кадров в секунду. Это показывает, какой производительности можно добиться в графике.

DirectX Как создать функцию обработки Как сделать вывод на

fxsaber 2019.01.15 21:42 #153

Renat Fatkhullin:

На текущем уровне процессоров можно забыть про тормоза double математики. Нет тормозов.

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

С учетом 64 битного кода и нашего компилятора нужно забыть про integer в классе задач, основанном на double вычислениях..

Вот предыдущий пример разбора попыток оптимизации Николая: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332

Компилятор сумел вычисления двух 64 битных double корней из разных выражений объединить в одной 128 битной ассемблерной команде. При работе с double математикой категорически не рекомендуется прыгать/конвертироваться в integer типы. Там на конвертации дикие процессорные(не наши) оверхеды.

Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.

Алексей Тарабанов 2019.01.15 22:35 #154

Artyom Trishkin:

Не, ну это не морфинг. Морфингом с натяжкой можно это назвать:

А вообще, лень было делать самому настоящий - нашёл в папках примеров.

Морфинг, буквально - умертвление.

Алексей Тарабанов 2019.01.15 22:48 #155

fxsaber:

Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.

Коню понятно, как говорила Елена Юрьевна.

Renat Akhtyamov 2019.01.15 23:03 #156

Nikolai Semko:

По мотивам Doom и по совету @fxsaber.

За основу был взят алгоритм с этого сайта с небольшими доработками

Реально круто!

Чем картинки делаешь, Николай?

Renat Fatkhullin 2019.01.15 23:06 #157

fxsaber:

Почти уверен, что если сделать тики целочисленными, то "Тестер" начнет работать значительно быстрее.

Нет.

Для начала осознайте, что:

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

Я не зря привел выше доказательства. Там Николай попытался применить метод оптимизации через предрасчитанные таблицы корней и проиграл рилтаймовому расчету дабловых корней на проце.

Свои символы и свои Работаю со скользящими средними(MA) MQL5 Компилятор не различает

Artyom Trishkin 2019.01.15 23:08 #158

Алексей Тарабанов:

Морфинг, буквально - умертвление.

Не стоит тут это обсуждать, но всё же Морфинг (англ. morphing — трансформация) Уж где ты там мертвецов увидел - трезвей...

Алексей Тарабанов 2019.01.15 23:17 #159

Artyom Trishkin:

Не стоит тут это обсуждать, но всё же Морфинг (англ. morphing — трансформация) Уж где ты там мертвецов увидел - трезвей...

Морфометрический анализ - анализ убитых клеток. Сначала убиваем, после - под микроскоп.

fxsaber 2019.01.15 23:18 #160

Renat Fatkhullin:

Нет.

#define BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
}  

template <typename T>
T Tester( const int Amount = 1e7 )
{
  T Sum = 1;
  T Price = 1;
  
  for (int i = 0; i < Amount; i++)
  {
    Price = 1 - Price;
    
    Sum += (Sum > Price) ? 1 : 0;
  }
  
  Print(Sum);
  
  return(Sum);
}

void OnStart()
{
  BENCH(Tester<int>());
  BENCH(Tester<double>());
}

В два раза int быстрее double

10000001
Time[Tester<int>()] = 25523
10000001.0
Time[Tester<double>()] = 51253

Canvas - это круто! - страница 16