От CPU к GPU в MQL5: практическая схема OpenCL для ускорения исследований, оптимизаций и паттернов

Введение

Переход от CPU к GPU в MQL5 часто выглядит как очевидный шаг: если видеокарта умеет считать быстрее, значит, и торговые исследования должны ускориться автоматически. На практике всё устроено тоньше. GPU действительно способен дать серьёзный выигрыш, но только тогда, когда задача хорошо ложится на параллельную модель вычислений. Иначе можно получить не ускорение, а лишь более сложную архитектуру с теми же или даже большими затратами.

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

Но у GPU есть своя цена. Перед началом вычислений данные нужно подготовить, передать на устройство, дождаться выполнения ядра и вернуть результат обратно. Для компактных задач эта логика может оказаться слишком тяжёлой. Там, где CPU справляется быстро и без лишних накладных расходов, перенос расчётов на GPU не даёт выигрыша. Иногда он даже мешает, особенно если задача часто меняется, требует гибкой логики или связана с небольшими объёмами данных.

В среде MQL5 роль связующего звена между прикладной логикой и видеокартой выполняет OpenCL. Именно он позволяет вынести трудоёмкую часть вычислений за пределы основной программы и организовать пакетную обработку данных на GPU. Однако сам по себе OpenCL не является магической кнопкой ускорения. Он приносит пользу только тогда, когда архитектура задачи изначально учитывает специфику параллельных вычислений и минимизирует обмен данными между CPU и GPU.

В рамках данной статьи GPU рассматривается как отдельный уровень вычислительной схемы, предназначенный для тяжёлых и повторяемых операций. Такой подход полезен в исследованиях, оптимизациях и задачах поиска паттернов, где объём расчётов растёт быстрее, чем терпение исследователя. Практический смысл здесь прост: сначала нужно понять, что именно стоит переносить на GPU, а уже затем ждать от ускорения реального эффекта.

Подготовка среды

Работа с OpenCL начинается не с вычислений, а с подготовки. Сначала программе нужно найти доступное устройство, создать рабочий контекст, подготовить kernel и выделить память под данные. Всё это выглядит как техническая формальность, но именно на этом этапе часто теряется значительная часть производительности.

Главная ошибка — обращаться к GPU как к обычной функции: вызвал, получил результат и пошёл дальше. На самом деле за таким вызовом стоит целая цепочка действий. Нужно создать или подключить контекст, подготовить программу, скомпилировать kernel, выделить память, передать данные и только потом запустить расчёт. Если делать это заново каждый раз, GPU будет тратить слишком много времени не на вычисления, а на подготовку к ним.

Поэтому в хорошей реализации почти всё, что можно, делается один раз. Контекст создаётся заранее и потом переиспользуется. Kernel компилируется один раз, если код не меняется. Буферы памяти тоже лучше не пересоздавать без необходимости, а использовать повторно. Такой подход уменьшает накладные расходы и делает работу с GPU действительно полезной.

То же самое относится и к передаче данных. GPU плохо подходит для множества мелких задач, которые постоянно отправляются туда и обратно. При таком подходе время уходит не на вычисление, а на обмен данными. Намного эффективнее собирать данные в более крупные пакеты и запускать расчёт реже, но с большей нагрузкой. Один крупный запуск почти всегда лучше серии мелких.

Есть и ещё одна распространённая проблема — лишняя синхронизация. Если программа после каждого шага останавливается и ждёт завершения GPU, устройство простаивает. Это снижает общий эффект ускорения. Лучше строить работу так, чтобы GPU получал задачу, выполнял её без лишних остановок и возвращал результат только тогда, когда он действительно нужен.

Для MQL5 это особенно важно. Торговые программы чувствительны к задержкам, и архитектурная небрежность быстро становится заметной. Если контекст постоянно создаётся заново, память выделяется хаотично, а kernel компилируется при каждом расчёте, GPU превращается не в ускоритель, а в источник тормозов.

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

Работа с памятью

Когда речь заходит о GPU, многие думают в первую очередь о вычислительной мощности. Но на практике всё часто упирается не столько в скорость вычислений, сколько в то, как именно подаются данные. Даже очень быстрый GPU не даст хорошего результата, если ему неудобно работать с памятью.

В OpenCL память — это не просто место, где хранятся данные. От того, как она используется, напрямую зависит производительность. У GPU есть несколько уровней памяти. Одни работают быстрее, другие медленнее. Внутренние небольшие области памяти доступны быстро, а вот обращение к основной памяти устройства обходится заметно дороже.

Из этого вытекает важное практическое правило: данные нужно организовывать так, чтобы GPU как можно реже обращался к медленной памяти. Чем меньше лишних чтений и записей, тем лучше. Особенно важно не передавать одни и те же данные между CPU и GPU снова и снова без необходимости. Очень часто именно обмен данными, а не само вычисление, становится главным узким местом.

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

Для торговых задач это особенно чувствительно. Если программа на каждом шаге то подготавливает данные, то передаёт их, то ждёт результат, то снова всё повторяет, производительность будет нестабильной. Гораздо лучше собрать нужные данные заранее, отправить их на устройство одним блоком, выполнить расчёт и использовать результат уже на стороне основной программы.

Здесь важно правильно разделить роли. CPU остаётся управляющим центром: он собирает данные, запускает расчёт и принимает итоговое решение. GPU берёт на себя ту часть работы, где нужно быстро и много раз повторить одну и ту же операцию. Такая схема почти всегда надёжнее и эффективнее, чем попытка переложить всё на одно устройство.

Есть и ещё одна типичная ошибка — слишком мелкие запуски kernel. На первый взгляд это кажется удобным: пришли новые данные, сразу отправили на GPU. Но каждый запуск тоже стоит времени. Если запусков слишком много, накладные расходы начинают съедать весь выигрыш. Поэтому в большинстве случаев лучше запускать GPU реже, но давать ему более крупную и ровную задачу.

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

Вывод: GPU ускоряет вычисления только тогда, когда данные подаются ему правильно. Чем меньше лишних передач, обращений и мелких запусков, тем выше реальный эффект.

Построение программы

В прикладной программе CPU и GPU не конкурируют друг с другом, а работают в связке. CPU остаётся центром управления — он формирует исходные данные, вызывает нужный метод, принимает результат и сравнивает время выполнения. GPU берёт на себя только вычислительную часть. Это классическая схема: не тащить на устройство всю программу целиком, а отдать ему только участок, где действительно есть параллелизм.

Построение программы с использованием OpenCL проще всего понять на конкретном примере. В стандартной библиотеке MQL5 есть показательная реализация умножения матриц. В основной программе сначала создаются две матрицы и заполняются случайными значениями.

void OnStart()
  {
//--- matrix A 1000x2000
   int rows_a = 1000;
   int cols_a = 2000;
//--- matrix B 2000x1000
   int rows_b = cols_a;
   int cols_b = 1000;
//--- matrix C 1000x1000
   int rows_c = rows_a;
   int cols_c = cols_b;
//--- matrix A: size=rows_a*cols_a
   int size_a = rows_a * cols_a;
   int size_b = rows_b * cols_b;
   int size_c = rows_c * cols_c;
//--- prepare matrix A
   float matrix_a[];
   ArrayResize(matrix_a, rows_a * cols_a);
   for(int i = 0; i < rows_a; i++)
      for(int j = 0; j < cols_a; j++)
        {
         matrix_a[i * cols_a + j] = (float)(10 * MathRand() / 32767);
        }
//--- prepare matrix B
   float matrix_b[];
   ArrayResize(matrix_b, rows_b * cols_b);
   for(int i = 0; i < rows_b; i++)
      for(int j = 0; j < cols_b; j++)
        {
         matrix_b[i * cols_b + j] = (float)(10 * MathRand() / 32767);
        }

Сначала вызывается последовательный расчёт на CPU, а затем выполняется тот же самый расчёт на GPU.

//--- CPU: calculate matrix product matrix_a*matrix_b
   float matrix_c_cpu[];
   ulong time_cpu = 0;
   if(!MatrixMult_CPU(matrix_a, matrix_b, matrix_c_cpu, rows_a, cols_a, cols_b, time_cpu))
     {
      PrintFormat("Error in calculation on CPU. Error code=%d", GetLastError());
      return;
     }
//--- calculate matrix product using GPU
   float matrix_c_gpu_method1[];
   float matrix_c_gpu_method2[];
   ulong time_gpu_method1 = 0;
   ulong time_gpu_method2 = 0;
   if(!MatrixMult_GPU(matrix_a, matrix_b, matrix_c_gpu_method1, matrix_c_gpu_method2,
       rows_a, cols_a, cols_b, size_a, size_b, size_c, time_gpu_method1, time_gpu_method2))
     {
      PrintFormat("Error in calculation on GPU. Error code=%d", GetLastError());
      return;
     }

Непосредственно вычисления вынесены в отдельные методы. Причём GPU-часть представлена в двух реализациях одной задачи: наивной и оптимизированной. Это позволяет сразу увидеть разницу не на словах, а в коде и во времени выполнения.

Сначала посмотрим на CPU-версию. Здесь всё предельно ясно: классический тройной цикл. Каждый элемент результирующей матрицы вычисляется последовательно.

bool MatrixMult_CPU(const float &matrix_a[], const float &matrix_b[], float &matrix_c[],
                    const int rows_a, const int cols_a, const int cols_b, ulong &time_cpu)
  {
   int size = rows_a * cols_b;
   if(ArrayResize(matrix_c, size) != size)
      return(false);
//--- CPU calculation started
   time_cpu = GetMicrosecondCount();
   for(int i = 0; i < rows_a; i++)
     {
      for(int j = 0; j < cols_b; j++)
        {
         float sum = 0.0;
         for(int k = 0; k < cols_a; k++)
           {
            sum += matrix_a[cols_a * i + k] * matrix_b[cols_b * k + j];
           }
         matrix_c[cols_b * i + j] = sum;
        }
     }
//--- CPU calculation finished
   time_cpu = ulong((GetMicrosecondCount() - time_cpu) / 1000);
//---
   return(true);
  }

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

Дальше начинается GPU-часть. И вот здесь важно подчеркнуть главный принцип: OpenCL в этом примере спрятан в отдельный метод. Основная программа остаётся чистой, а вся работа с GPU сосредоточена в одном месте.

bool MatrixMult_GPU(const float &matrix_a[], const float &matrix_b[], float &matrix1_c[], float &matrix2_c[],
                    const int rows_a, const int cols_a, const int cols_b, const int size_a, const int size_b,
                    const int size_c, ulong &time1_gpu, ulong &time2_gpu)
  {
   const int task_dimension = 2;
//--- prepare matrices for result
   if(ArrayResize(matrix1_c, size_c) != size_c || ArrayResize(matrix2_c, size_c) != size_c)
      return(false);
   ArrayFill(matrix1_c, 0, size_c, (float)0.0);
   ArrayFill(matrix2_c, 0, size_c, (float)0.0);

Здесь сразу видно важную вещь: матрицы результатов для двух GPU-вариантов готовятся заранее. Это позволяет не смешивать вычисление с подготовкой памяти. Уже на этом уровне программа устроена дисциплинированно: сначала выделение массивов, потом OpenCL.

Далее создаётся и инициализируется OpenCL-контекст.

//--- OpenCL
   ulong timei_gpu = GetMicrosecondCount();
   COpenCL OpenCL;
   if(!OpenCL.Initialize(cl_program, true))
     {
      PrintFormat("Error in OpenCL initialization. Error code=%d", GetLastError());
      return(false);
     }

Вот здесь как раз и начинается тот самый практический смысл OpenCL. До этого момента программа была обычным MQL5-кодом. Теперь она готовит вычислительную среду для GPU. И что особенно важно — это не бесплатная операция. Отдельно замеряем время инициализации. Перед тем как говорить об ускорении, нужно честно посмотреть, сколько стоит сам запуск среды.

Следом создаются два kernel. Первый — это простой параллельный вариант. Второй — более продвинутый, с локальными группами.

//--- create kernels
   OpenCL.SetKernelsCount(2);
   OpenCL.KernelCreate(0, "MatrixMult_GPU1");
   OpenCL.KernelCreate(1, "MatrixMult_GPU2");

Здесь стоит обратить внимание, что время выполнения во многом зависит от качества алгоритма, используемого в OpenCL-программе. Можно просто распараллелить расчёт, а можно улучшить работу с памятью. В примере есть оба варианта, и это делает его особенно наглядным.

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

//--- create buffers
   OpenCL.SetBuffersCount(3);
//---
   if(!OpenCL.BufferFromArray(0, matrix_a, 0, size_a, CL_MEM_READ_ONLY))
     {
      PrintFormat("Error in BufferFromArray for matrix A. Error code=%d", GetLastError());
      return(false);
     }
   if(!OpenCL.BufferFromArray(1, matrix_b, 0, size_b, CL_MEM_READ_ONLY))
     {
      PrintFormat("Error in BufferFromArray for matrix B. Error code=%d", GetLastError());
      return(false);
     }
   if(!OpenCL.BufferCreate(2, size_c * sizeof(float), CL_MEM_WRITE_ONLY))
     {
      PrintFormat("Error in BufferCreate for matrix C. Error code=%d", GetLastError());
      return(false);
     }

Это уже настоящая рабочая схема GPU. Данные сначала целиком передаются на устройство, потом считаются и возвращаются назад. Именно такой порядок делает ускорение возможным. Если разорвать его на мелкие куски, GPU начнёт тратить слишком много времени на подготовку и обмен, а не на сам расчёт.

После этого задаются аргументы первого kernel.

//--- prepare arguments for kernel 0
   int kernel_index = 0;
   OpenCL.SetArgumentBuffer(kernel_index, 0, 0);
   OpenCL.SetArgumentBuffer(kernel_index, 1, 1);
   OpenCL.SetArgumentBuffer(kernel_index, 2, 2);
   OpenCL.SetArgument(kernel_index, 3, rows_a);
   OpenCL.SetArgument(kernel_index, 4, cols_a);
   OpenCL.SetArgument(kernel_index, 5, cols_b);
   timei_gpu = ulong((GetMicrosecondCount() - timei_gpu) / 1000);
   PrintFormat("time of initialization GPU =%d ms", timei_gpu);

Здесь логика очень простая: kernel получает буферы с данными и размеры матриц. И уже внутри OpenCL-ядра решается, какой поток за какой элемент отвечает. Это важный момент: GPU сам по себе не знает, как интерпретировать массивы. Эту структуру ему нужно явно передать.

Затем задаётся размер задачи и запускается первый вариант вычисления.

//--- set task dimension a_rows x b_cols
   uint global_work_size[2];
//--- set dimensions
   global_work_size[0] = rows_a;
   global_work_size[1] = cols_b;
   uint global_work_offset[2] = {0, 0};
//--- GPU calculation start kernel 0
   time1_gpu = GetMicrosecondCount();
   if(!OpenCL.Execute(kernel_index, task_dimension, global_work_offset, global_work_size))
     {
      PrintFormat("Error in Execute. Error code=%d", GetLastError());
      return(false);
     }
   if(!OpenCL.BufferRead(2, matrix1_c, 0, 0, size_c))
     {
      PrintFormat("Error in BufferRead for matrix1 C. Error code=%d", GetLastError());
      return(false);
     }
//--- GPU calculation finished
   time1_gpu = ulong((GetMicrosecondCount() - time1_gpu) / 1000);

Это первый GPU-вариант. Он показывает базовую идею: один поток считает один элемент результата. Такая схема уже даёт параллелизм, но ещё не использует все возможности оптимизации памяти. Поэтому рядом в примере есть второй kernel. Перед его запуском аргументы задаются так же, а вот способ выполнения уже другой — с локальной рабочей группой.

//--- prepare arguments for kernel 1
   kernel_index = 1;
//--- set arguments
   OpenCL.SetArgumentBuffer(kernel_index, 0, 0);
   OpenCL.SetArgumentBuffer(kernel_index, 1, 1);
   OpenCL.SetArgumentBuffer(kernel_index, 2, 2);
   OpenCL.SetArgument(kernel_index, 3, rows_a);
   OpenCL.SetArgument(kernel_index, 4, cols_a);
   OpenCL.SetArgument(kernel_index, 5, cols_b);
   uint local_work_size[2];
   local_work_size[0] = BLOCK_SIZE;
   local_work_size[1] = BLOCK_SIZE;

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

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

//--- GPU calculation start, kernel1
   time2_gpu = GetMicrosecondCount();
   if(!OpenCL.Execute(kernel_index, task_dimension, global_work_offset, global_work_size, local_work_size))
     {
      PrintFormat("Error in Execute. Error code=%d", GetLastError());
      return(false);
     }
   if(!OpenCL.BufferRead(2, matrix2_c, 0, 0, size_c))
     {
      PrintFormat("Error in BufferRead for matrix2 C. Error code=%d", GetLastError());
      return(false);
     }
//--- GPU calculation finished
   time2_gpu = ulong((GetMicrosecondCount() - time2_gpu) / 1000);
//--- remove OpenCL objects
   OpenCL.Shutdown();
//---
   return(true);
  }

Теперь самое интересное — что происходит внутри OpenCL-кода. Первая версия kernel выглядит максимально просто.

__kernel void MatrixMult_GPU1(__global float *matrix_a,
                              __global float *matrix_b,
                              __global float *matrix_c,
                              int rows_a, int cols_a, int cols_b)
  {
   int i = get_global_id(0);
   int j = get_global_id(1);
   float sum = 0.0;
   for(int k = 0; k < cols_a; k++)
     {
      sum += matrix_a[cols_a * i + k] * matrix_b[cols_b * k + j];
     }
   matrix_c[cols_b * i + j] = sum;
  }

Это почти буквальный перенос математической логики на GPU. Каждый поток получает свою координату и считает один элемент матрицы результата.

Вторая версия уже интереснее. В ней применяются локальные массивы и синхронизация потоков.

__kernel void MatrixMult_GPU2(__global float *matrix_a,
                              __global float *matrix_b,
                              __global float *matrix_c,
                              int rows_a, int cols_a, int cols_b)
  {
   int group_i = get_group_id(0);
   int group_j = get_group_id(1);
   int i = get_local_id(0);
   int j = get_local_id(1);
   __local float submatrix_a[BLOCK_SIZE][BLOCK_SIZE];
   __local float submatrix_b[BLOCK_SIZE][BLOCK_SIZE];
   int offset_b = BLOCK_SIZE * group_i;
   int offset_a_start = cols_a * BLOCK_SIZE * group_j;
   float sum = (float)0.0;

Здесь уже видно, что вычисление строится иначе. Потоки объединяются в группы, а данные загружаются во внутреннюю память блока. Это уменьшает количество обращений к global-памяти и делает работу устройства более эффективной.

Далее происходит загрузка фрагментов и синхронизация потоков.

   for(int offset_a = offset_a_start;
       offset_a < offset_a_start + cols_a;
       offset_a += BLOCK_SIZE,
       offset_b += BLOCK_SIZE * cols_b)
     {
      submatrix_a[i][j] = matrix_a[offset_a + cols_a * i + j];
      submatrix_b[i][j] = matrix_b[offset_b + cols_b * i + j];
      barrier(CLK_LOCAL_MEM_FENCE);
      for(int k = 0; k < BLOCK_SIZE; k++)
         sum += submatrix_a[i][k] * submatrix_b[k][j];
      barrier(CLK_LOCAL_MEM_FENCE);
     }

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

Полученный результат записывается обратно в выходной массив.

   int offset_c = BLOCK_SIZE * (cols_b * group_j + group_i);
   matrix_c[offset_c + cols_b * i + j] = sum;
  };

Эти два kernel сравниваются в основной программе по времени выполнения и контролируется точность вычислений в сравнении с CPU-вариантом.

//--- calculate CPU/GPU ratio
   double CPU_GPU_ratio1 = 0;
   double CPU_GPU_ratio2 = 0;
   if(time_gpu_method1 != 0)
      CPU_GPU_ratio1 = 1.0 * time_cpu / time_gpu_method1;
   if(time_gpu_method2 != 0)
      CPU_GPU_ratio2 = 1.0 * time_cpu / time_gpu_method2;
   PrintFormat("time CPU=%d ms, time GPU global work groups =%d ms, CPU/GPU ratio: %f",
                                           time_cpu, time_gpu_method1, CPU_GPU_ratio1);
   PrintFormat("time CPU=%d ms, time GPU local work groups  =%d ms, CPU/GPU ratio: %f",
                                           time_cpu, time_gpu_method2, CPU_GPU_ratio2);
   PrintFormat("time matrix CPU=%d ms", time_mat);

Для полноты картины добавим в сравнение использование встроенных матричных операций.

//--- matrix
   matrix<float> A, B, C;
   if(!A.Assign(matrix_a) || !B.Assign(matrix_b))
     {
      PrintFormat("Error of copy data to matrices. Error code=%d", GetLastError());
      return;
     }
   if(!A.Reshape(rows_a, cols_a) || !B.Reshape(rows_b, cols_b))
     {
      PrintFormat("Error of copy data to matrices. Error code=%d", GetLastError());
      return;
     }
   ulong time_mat = GetMicrosecondCount();
   C = A.MatMul(B);
   time_mat = ulong((GetMicrosecondCount() - time_mat) / 1000); 

В практическом эксперименте сравнивалось время умножения матриц на гибридной системе: CPU и два GPU: NVIDIA GeForce RTX 4060 Laptop GPU и Intel Iris Xe Graphics. В качестве базовой линии использовалась наивная CPU-реализация, которая показала время порядка 2056 – 2180 мс. Здесь стоит обратить внимание на оптимизированные матричные операции, показавшие стабильное время порядка 32–34 мс, что для процессора данного класса можно считать близким к ожидаемому уровню производительности при векторизованной обработке.

При переносе вычислений на GPU картина оказалась неоднородной и хорошо иллюстрирует зависимость эффективности OpenCL от организации вычислительных блоков. В случае RTX 4060 при использовании глобальных рабочих групп время выполнения составило около 38 мс, что формально не даёт выигрыша относительно матричных операций CPU. Однако переход к локальным рабочим группам радикально изменил ситуацию — время снизилось до 11 мс. Это уже демонстрирует полноценную работу tiled-подхода, при котором повторное использование данных в локальной памяти снижает давление на глобальную память и позволяет задействовать вычислительные блоки GPU значительно эффективнее.

Похожая, но более выраженная тенденция наблюдается и на интегрированной Intel Iris Xe. В режиме глобальных групп время выполнения составило 213 мс, тогда как при использовании локальных групп оно снизилось до 45 мс. Несмотря на сохранение общего отставания от дискретной GPU, относительное ускорение здесь ещё более заметно, что подчёркивает чувствительность менее производительных GPU к оптимизации доступа к памяти.

Отдельного внимания заслуживает время инициализации GPU, которое для RTX 4060 составило около 99 мс, а для Iris Xe — порядка 4 мс. Этот фактор в прикладных сценариях нельзя игнорировать, поскольку он влияет на суммарную эффективность вычислительного конвейера.

В целом результаты демонстрируют классическую картину перехода от memory-bound к compute-эффективному режиму выполнения. CPU остаётся конкурентоспособным на данном масштабе задачи, тогда как GPU раскрывают преимущество только при корректной организации локальных вычислительных блоков. Особенно отчётливо это видно на RTX 4060, где разница между неоптимальной и оптимизированной реализацией достигает порядка трёх-четырёх раз, что фактически определяет границу между неэффективным и полноценным использованием графического ускорителя.

Тестирование свечных паттернов

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

Обычно свечные паттерны описывают как готовые фигуры с известными названиями. Их легко узнать на картинке, и в книгах они часто выглядят убедительно. Но если посмотреть на это строже, возникает вопрос: насколько такие модели действительно подтверждаются статистикой? Где точные критерии? Как понять, что паттерн работает не в теории, а на реальных данных?

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

Берётся несколько последних свечей — то есть текущая рыночная ситуация. Это наш образец. Затем программа проходит по истории и ищет участки, которые похожи на него по форме. Сравнение идёт не по названию паттерна, а по реальным характеристикам свечей: телу, верхней тени и нижней тени. Причём допускается небольшое отклонение, потому что рынок почти никогда не повторяет один и тот же рисунок идеально.

Если в истории находится похожий участок, дальше программа не делает догадок, а проверяет результат. Для этой ситуации моделируется сделка: задаются уровни Take Profit и Stop Loss, а также ограничение по времени. Затем считается, чем чаще заканчивались такие случаи в прошлом — прибылью или убытком.

Именно здесь OpenCL становится особенно полезен. Такая задача состоит из большого количества однотипных проверок: нужно перебрать много участков истории, сравнить их с текущим шаблоном и для каждого варианта просчитать результат сделки. Для CPU это возможно, но при большом объёме данных расчёты становятся тяжёлыми. Для GPU это, наоборот, естественная нагрузка: много независимых вычислений, которые можно выполнять параллельно.

Кроме того, в статье проверяется не одна комбинация параметров сделки, а сразу целая сетка вариантов. То есть программа одновременно рассматривает разные значения Take Profit и Stop Loss. Это позволяет оценить, какие параметры в похожих рыночных условиях выглядели наиболее разумно.

Начнём с логики на стороне OpenCL — именно здесь задача принимает свою настоящую форму. CPU в этой конструкции остаётся дирижёром, но вся тяжёлая работа — поиск, сравнение, моделирование — уходит на GPU.

Перед нами конвейер анализа.

__kernel void PatternStats3D(__global const float4 *price,
                             __global const float  *tp,
                             __global const float  *sl,
                             __global float        *global_stats,
                             const int bars,
                             const float tolerance,
                             const int horizon)
  {
   const int lid = get_local_id(0);
   const int itp = get_global_id(1);
   const int isl = get_global_id(2);
   const int total_loc = get_local_size(0);
   const int tp_count = get_global_size(1);
   const int sl_count = get_global_size(2);

Исходные данные организованы предельно компактно. История передаётся как массив векторов float4. Каждая запись — это свеча: open, high, low, close. Это важно. Мы не дробим данные на отдельные массивы, не усложняем доступ. GPU лучше работает с плотными структурами, и здесь это используется в полной мере.

Отдельно передаются массивы tp и sl. Тем самым мы сразу закладываем второе и третье измерение задачи. Каждый поток работает не только со своим участком истории, но и с конкретной комбинацией параметров сделки. В результате пространство вычислений становится трёхмерным: история × TP × SL.

Дальше начинается сама работа. Каждый поток внутри группы получает свой lid и начинает обход истории с шагом, равным размеру группы.

   __local int buf_stat[BLOCK_SIZE][STAT_DIM];
   int local_stat[STAT_DIM];
   for(int i=0;i<STAT_DIM;i++)
     local_stat[i]=0;
//---
   float4 pattern[PATTERN_SIZE];
   if(bars < (PATTERN_SIZE + horizon))
      return;
   for(int i = 0; i < PATTERN_SIZE; i++)
      pattern[i] = price[bars - 1 - PATTERN_SIZE + i];
//--- граница
   for(int i = lid; i < (bars - horizon - PATTERN_SIZE); i += total_loc)
     {
      bool match = true;
      //--- проверка паттерна
      for(int k = 0; k < PATTERN_SIZE ; k++)
        {
         float4 a = price[i + k];
         float body_a  = a.w - a.x;
         float body_b  = pattern[k].w - pattern[k].x;
         if(fabs(body_a - body_b) > tolerance)
           {
            match = false;
            break;
           }
         float upper_a = a.y - fmax(a.w, a.x);
         float upper_b = pattern[k].y - fmax(pattern[k].w, pattern[k].x);
         if(fabs(upper_a - upper_b) > tolerance)
           {
            match = false;
            break;
           }
         float lower_a = fmin(a.w, a.x) - a.z;
         float lower_b = fmin(pattern[k].w, pattern[k].x) - pattern[k].z;
         if(fabs(lower_a - lower_b) > tolerance)
           {
            match = false;
            break;
           }
        }

Это классический приём. Мы не создаём поток на каждый бар — это было бы слишком дорого. Вместо этого каждый поток обрабатывает свою полосу данных. Нагрузка распределяется равномерно, без лишних запусков kernel.

Перед началом прохода формируется эталон. Берём последние свечи из истории. Это и есть текущий рынок, который нас интересует. Никаких внешних паттернов. Никаких предположений. Только фактическое состояние цены.

Далее — ключевой момент: сравнение. Для каждой позиции в истории проверяется, похож ли участок на эталон. Причём сравнение идёт по структуре свечи:

• тело;
• верхняя тень;
• нижняя тень.

И всё это — с допуском tolerance. Это аккуратный, но важный нюанс. Мы не требуем точного совпадения. Рынок не рисует идеальные копии. Нас интересует форма, а не пиксельная идентичность.

Если хотя бы один элемент выходит за пределы допуска — совпадение отклоняется. Быстро и без лишних вычислений. Если совпадение найдено, начинается вторая часть — моделирование сделки. Точка входа берётся на открытии новой свечи после паттерна.

      //--- симуляция сделки
      if(match)
        {
         local_stat[0] += 1;
         int open = i + PATTERN_SIZE;
         float4 bar = price[open];
         float entry = bar.x;
         float tp_val = tp[itp];
         float sl_val = sl[isl];
         float buy_tp  = entry + tp_val;
         float buy_sl  = entry - sl_val;
         float sell_tp = entry - tp_val;
         float sell_sl = entry + sl_val;
         bool buy_tp_hit  = 0, buy_sl_hit  = 0;
         bool sell_tp_hit = 0, sell_sl_hit = 0;
         for(int k = 0; k < horizon; k++)
           {
            bar = price[open + k];
            float high = bar.y;
            float low  = bar.z;
            // SL проверяем первым (worst-case)
            buy_sl_hit  |= (buy_tp_hit  == 0) & (buy_sl_hit  == 0) & (low  <= buy_sl);
            buy_tp_hit  |= (buy_tp_hit  == 0) & (buy_sl_hit  == 0) & (high >= buy_tp);
            sell_sl_hit |= (sell_tp_hit == 0) & (sell_sl_hit == 0) & (high >= sell_sl);
            sell_tp_hit |= (sell_tp_hit == 0) & (sell_sl_hit == 0) & (low  <= sell_tp);
            if((buy_tp_hit | buy_sl_hit) & (sell_tp_hit | sell_sl_hit))
               break;
           }
         // принудительное закрытие по времени
         buy_sl_hit  |= (buy_tp_hit  == 0) & (buy_sl_hit  == 0) & (entry  > bar.w);
         buy_tp_hit  |= (buy_tp_hit  == 0) & (buy_sl_hit  == 0) & (entry  < bar.w);
         sell_sl_hit |= (sell_tp_hit == 0) & (sell_sl_hit == 0) & (entry  < bar.w);
         sell_tp_hit |= (sell_tp_hit == 0) & (sell_sl_hit == 0) & (entry  > bar.w);
         //---
         local_stat[1] += (int)buy_tp_hit;
         local_stat[2] += (int)buy_sl_hit;
         local_stat[3] += (int)sell_tp_hit;
         local_stat[4] += (int)sell_sl_hit;
        }
     }

Дальше рассчитываются уровни TP и SL для покупки и продажи. И обратите внимание на деталь: обе стороны считаются одновременно. Это экономит вычисления и даёт полную картину поведения рынка.

Затем запускается проход вперёд по истории с ограничением horizon. На каждом шаге проверяется:

• достигнут ли SL;
• достигнут ли TP.

Причём SL проверяется первым. Это не случайность, а сознательное допущение worst-case сценария. Такой подход делает оценку более консервативной — а значит, ближе к реальности.

Как только для обеих сторон исход определён, цикл прерывается. Лишняя работа не выполняется.

Если ни TP, ни SL не были достигнуты, позиция закрывается принудительно по времени. Это ещё один важный элемент. Мы не оставляем висящие сделки — каждая ситуация должна дать результат.

Все результаты накапливаются в приватном массиве local_stat. Это принципиально. На этом этапе нет ни одной синхронизации. Каждый поток работает независимо и быстро.

Далее начинается то, ради чего всё и строилось — локальная агрегация. Первые BLOCK_SIZE потоков записывают свои результаты в buf_stat. Это локальная память, она быстрая и общая для группы.

//--- запись в local
   if(lid < BLOCK_SIZE)
      for(int k = 0; k < STAT_DIM; k++)
         buf_stat[lid][k] = local_stat[k];
   barrier(CLK_LOCAL_MEM_FENCE);

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

   for(int i = BLOCK_SIZE; i < total_loc; i += BLOCK_SIZE)
     {
      if(lid >= i && lid < (i + BLOCK_SIZE))
         for(int k = 0; k < STAT_DIM; k++)
            buf_stat[lid-i][k] += local_stat[k];
      barrier(CLK_LOCAL_MEM_FENCE);
     }

После этого выполняется классическая редукция — попарное суммирование с уменьшением шага.

//--- редукция
   for(int stride = BLOCK_SIZE / 2; stride > 0; stride >>= 1)
     {
      if(lid < stride)
        {
         for(int k = 0; k < STAT_DIM; k++)
           {
            buf_stat[lid][k] += buf_stat[lid + stride][k];
            buf_stat[lid + stride][k] = 0;
           }
        }
      barrier(CLK_LOCAL_MEM_FENCE);
     }

На выходе остаётся один поток, который содержит агрегированную статистику по всей группе. Он осуществляет финальный шаг — запись результата.

//--- запись результата
   if(lid == 0)
     {
      int idx = (itp * sl_count + isl) * STAT_DIM;
      int count = buf_stat[0][0];
      global_stats[idx + 0] = count;
      float norm = (count > 0) ? (1.0f / ((float)count)) : 0.0f;
      for(int k = 1; k < STAT_DIM; k++)
         global_stats[idx + k] = buf_stat[0][k] * norm;
     }
  }

Здесь происходит важное преобразование:

• общее количество совпадений сохраняется как есть;
• остальные значения приводятся к вероятностям.

После завершения расчёта на выходе получается не набор сырых чисел, а уже готовая статистика. Мы видим:

• сколько раз в истории встречалась похожая ситуация;
• как часто после неё срабатывал Take Profit для покупки;
• как часто срабатывал Stop Loss;
• как вели себя сделки на продажу;
• какие сочетания параметров выглядели лучше.

Дальше решение принимает уже основная программа. Она смотрит не на красивый паттерн, а на статистику. Если данных слишком мало, сигнал игнорируется. Если выборка достаточная, сравниваются вероятности для покупки и продажи. Затем подбираются более подходящие значения Take Profit и Stop Loss, и только после этого может открываться позиция.

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

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

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

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

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

Заключение

OpenCL в MQL5 следует воспринимать как инструмент для конкретного класса задач. Он показывает себя там, где есть большой массив данных, повторяемые операции и возможность эффективно распараллелить вычисления. Во всех остальных случаях CPU остаётся более рациональным выбором: он проще, гибче и нередко быстрее, когда речь идёт о небольших или слабо масштабируемых расчётах.

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

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

Главный вывод остаётся практическим. Перенос на GPU не делает торговую систему прибыльной и не заменяет содержательную модель рынка. Зато он открывает доступ к тому объёму перебора и анализа, который на CPU был бы слишком дорогим или слишком медленным. В этом и состоит его реальная ценность: не обещать чудес, а делать возможным более широкий и более системный исследовательский цикл в MQL5.

Программы, используемые в статье

#	Имя	Тип	Описание
1	PatternStats.mq5	Советник	Советник тестирования
2	PatternStats.cl	Библиотека	Библиотека кода OpenCL-программы