Раз уж Вы здесь. Видится ли правильным, что удаление ордера (например, руками) вызывает помещение его не в конец БД исторических ордеров, а в середину?
Например, в Тестере любое помещение в БД ордера происходит дозаписыванием в конец. А в Терминале?
Спасибо за пояснение. Ниже написал три варианта одной и той же функции и замерил скорость их выполнения. Нигде в цикле не создаются объекты.
Неужели нужно писать подобие первой функции?! Второй же вариант - полная засада с производительностью.
Уважаемые форумчане, а какой вариант используете Вы?
Тройка вариантов с рекурсией больше ради прикола. )) Впрочем в большинстве тестов побеждают, но не на много.
/====================================================================
double GetSum4( const STRUCT &Array[], constdouble Koef1, constdouble Koef2, constdouble Koef3, double Sum = 0, int i = 1)
{
_GetSum(Array[i].Request,Koef1,Koef2,Koef3,Sum);
if (++i<ArraySize(Array)) return GetSum4(Array,Koef1,Koef2,Koef3,Sum,i);
return(Sum);
}
double _GetSum( constMqlTradeRequest &Request[], constdouble Koef1, constdouble Koef2, constdouble Koef3, double &Sum, int j = 0 )
{
Sum += Koef1 * Request[j].price + Koef2 * Request[j].tp + Koef3 * Request[j].sl;
if (++j<ArraySize(Request)) return _GetSum(Request,Koef1,Koef2,Koef3,Sum,j);
return(Sum);
}
//====================================================================double GetSum5( const STRUCT &Array[], constdouble Koef1, constdouble Koef2, constdouble Koef3, double Sum = 0, int i = 1, int j = 0 )
{
Sum += Koef1 * Array[i].Request[j].price + Koef2 * Array[i].Request[j].tp + Koef3 * Array[i].Request[j++].sl;
if (j<ArraySize(Array[i].Request)) return GetSum5(Array,Koef1,Koef2,Koef3,Sum, i,j);
if (++i<ArraySize(Array)) return GetSum5(Array,Koef1,Koef2,Koef3,Sum, i);
return(Sum);
}
//====================================================================double GetSum6( const STRUCT &Array[], constdouble Koef1, constdouble Koef2, constdouble Koef3, double Sum = 0, int i = 1)
{
__GetSum(Array[i].Request,Koef1,Koef2,Koef3,Sum);
if (++i<ArraySize(Array)) return GetSum6(Array,Koef1,Koef2,Koef3,Sum,i);
return(Sum);
}
double __GetSum( constMqlTradeRequest &Request[], constdouble Koef1, constdouble Koef2, constdouble Koef3, double &Sum, int j = 0 )
{
Sum += GetResult(Request[j],Koef1,Koef2,Koef3);
if (++j<ArraySize(Request)) return __GetSum(Request,Koef1,Koef2,Koef3,Sum,j);
return(Sum);
}
double GetResult(constMqlTradeRequest &Request, constdouble Koef1, constdouble Koef2, constdouble Koef3) {
return Koef1 * Request.price + Koef2 * Request.tp + Koef3 * Request.sl;
}
//====================================================================
ЗЫ Проблемы рекурсии в том, что на дебаге можно словить переполнение стека. Да и как говорил Ильяс, оптимизация компилятором рекурсивной функции может быть пересмотрена в будущем.
Посмотрите примеры использования этого параметра в MQL5\Scripts\Examples\OpenCL\Float\FFT.mq5
Плюс документацию на саму официальную спецификацию OpenCL. Спецификация независима от карт, так что не имеет смысла задавать вопросы про специфичность того или иного устройства.
Пример то я посмотрел - с локальной памятью группы воркеров понятно. Просто у меня не использовалась локальная память и при изменении размера группы меняется результат... так по идеи же быть не должно.
Как Вы его выставили - по сравнению с HD7950 вышеуказанная карта работает в моей задаче на 30% быстрей, но рейтинг у последней значительно ниже - 869. Если бы я через клауд смог бы в будущем выбирать карты, и платить соответственно по рейтингу (в раз пять меньше), то это было бы хорошим подспорьем.
Спасибо за подробности. Тогда точно надо искать слабые места. Просьба все же ускорить историю.
Доступ в историю - это синхронизированные обращения в базу данных, а не в локальный массив.
Доступ в историю - это синхронизированные обращения в базу данных, а не в локальный массив.
Речь про работу уже ПОСЛЕ HistorySelect.
Раз уж Вы здесь. Видится ли правильным, что удаление ордера (например, руками) вызывает помещение его не в конец БД исторических ордеров, а в середину?
Например, в Тестере любое помещение в БД ордера происходит дозаписыванием в конец. А в Терминале?
Спасибо за пояснение. Ниже написал три варианта одной и той же функции и замерил скорость их выполнения. Нигде в цикле не создаются объекты.
Неужели нужно писать подобие первой функции?! Второй же вариант - полная засада с производительностью.
Уважаемые форумчане, а какой вариант используете Вы?
Тройка вариантов с рекурсией больше ради прикола. ))
Впрочем в большинстве тестов побеждают, но не на много.
ЗЫ Проблемы рекурсии в том, что на дебаге можно словить переполнение стека.
Да и как говорил Ильяс, оптимизация компилятором рекурсивной функции может быть пересмотрена в будущем.
Да и как говорил Ильяс, оптимизация компилятором рекурсивной функции может быть пересмотрена в будущем.
Сильно поменялось с тех пор.
Тройка вариантов с рекурсией больше ради прикола. ))
Впрочем в большинстве тестов побеждают, но не на много.
Очень сильные расхождения от запуска к запуску. Поэтому сделал такой замер.
Посмотрите примеры использования этого параметра в MQL5\Scripts\Examples\OpenCL\Float\FFT.mq5
Плюс документацию на саму официальную спецификацию OpenCL. Спецификация независима от карт, так что не имеет смысла задавать вопросы про специфичность того или иного устройства.
Пример то я посмотрел - с локальной памятью группы воркеров понятно. Просто у меня не использовалась локальная память и при изменении размера группы меняется результат... так по идеи же быть не должно.
Ещё вопрос, про рейтинг карт
Как Вы его выставили - по сравнению с HD7950 вышеуказанная карта работает в моей задаче на 30% быстрей, но рейтинг у последней значительно ниже - 869. Если бы я через клауд смог бы в будущем выбирать карты, и платить соответственно по рейтингу (в раз пять меньше), то это было бы хорошим подспорьем.
Доступ в историю - это синхронизированные обращения в базу данных
Вот это бы в документацию.
Поскольку многопоточности нет, то пришлось поделить бота на execution часть и все остальное.
Однако работа с историей как-то выпала, потому что вот не очевидно с первого взгляда, что обращения синхронизированы.
Однако работа с историей как-то выпала, потому что вот не очевидно с первого взгляда, что обращения синхронизированы.
Уверен, что Ренат ошибся. HistorySelect-функции - синхронные. HistoryGet - нет.