Особенности языка mql5, тонкости и приёмы работы - страница 153

 
Roffild:

В справке ArrayReverse:

Функция ArraySetAsSeries() физически не перемещает элементы массива, а только меняет направление индексации задом наперед для организации доступа к элементам как в таймсерии. Функция ArrayReverse() физически перемещает элементы массива таким образом, что массив "переворачивается".

Но этот код доказывает обратное: 

Почему? Все правильно.

Если мы имеем дело с массивом, где нумерация как в таймсерии, т.е. нулевой бар самый поздний, а последний - самый раний, то при добавлении нового элемента, он будет находится рядом с последним, т.е. самым ранним.

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

Где здесь доказательство - не понимаю. Как вообще это можно доказать и выяснить, где начало массива в памяти и каков шаг приращения - положительный или отрицательный. 
Доказать это можно лишь с dll с передачей массива и использованием указателей.
А вообще проще доказать замером времени выполнения данной операции. Если массив из 100 000 000 элементов "переворачивается" мгновенно, то понятно, что никакой перекидки нет, а просто меняется ссылка на начало и приращение меняет знак.
Я постоянно пользуюсь функцией  ArraySetAsSeries() и вижу что по времени это абсолютно бесплатно. Так что Вы не правы.

Если честно, не понимаю зачем нужна медленная функция ArrayReverse при наличии быстрой  ArraySetAsSeries() 

 
Roffild:

В справке ArrayReverse:

Функция ArraySetAsSeries() физически не перемещает элементы массива, а только меняет направление индексации задом наперед для организации доступа к элементам как в таймсерии. Функция ArrayReverse() физически перемещает элементы массива таким образом, что массив "переворачивается".

Но этот код доказывает обратное: 

У Вас перераспределение памяти для массива с флагом asSeries, естественно они это учли. Там у них должно быть что-то типа этого:

template<typename T>
T* ReAllocArray(T* array, size_t size, size_t newSize, bool asSeries) {
    auto _array = (T*)realloc(array, newSize * sizeof(T));
    if (_array == NULL) throw bad_alloc();
    auto _ptr = _array + size;
    auto ptr = _array + newSize;
    if (asSeries){
        while (_ptr != _array) *(--ptr) = *(--_ptr);
        while (ptr != _array) new(--ptr) T;
    }
    else {
        while (_ptr != ptr) new(_ptr++) T;
    }
    return _array;
}
 
Vladimir Simakov:

У Вас перераспределение памяти для массива с флагом asSeries, естественно они это учли. Там у них должно быть что-то типа этого:

Да, скорей всего учли. Но такое поведение не соответствует CopyRates():

Неважно, какое свойство имеет приемный массив - as_series=true или as_series=false, данные будут скопированы таким образом, что самый старый по времени элемент будет в начале физической памяти, отведенной под массив.

А еще к ArrayCopy():

Если count<0 либо count>src_size-src_start, то копируется весь остаток массива. Массивы копируются слева направо. Для серийных массивов правильно переопределяется стартовая позиция с учетом копирования слева направо.

Последнее предложение какое-то двусмысленное.
 

пребываю в легком шоке. Написал тест на Java. Оказывается Java практически так же быстра как C, а стало быть чуть быстрей MQL5.

Не понимаю, как им это удается, это же по сути язык интерпретатор. 

Итересно, с Питоном тоже самое?

Это, конечно же, не говорит, что MQL5 плох. Просто Java слишком крута.

Что-то, видно, упустил. С каких пор интерпретаторы сравнялись по скорости с компиляторами?...

Видно такое возможно только с помощью частичной компиляцией, т.е. интерпретаторы не чистые.

 
Nikolai Semko:

пребываю в легком шоке. Написал тест на Java. Оказывается Java практически так же быстра как C, а стало быть чуть быстрей MQL5.

Не понимаю, как им это удается, это же по сути язык интерпретатор. 

Итересно, с Питоном тоже самое?

Это, конечно же, не говорит, что MQL5 плох. Просто Java слишком крута.

Что-то, видно, упустил. С каких пор интерпретаторы сравнялись по скорости с компиляторами?...

Видно такое возможно только с помощью частичной компиляцией, т.е. интерпретаторы не чистые.

MQL тоже интерпретатор. 

 
Nikolai Semko:

пребываю в легком шоке. Написал тест на Java. Оказывается Java практически так же быстра как C, а стало быть чуть быстрей MQL5.

Не понимаю, как им это удается, это же по сути язык интерпретатор. 

Итересно, с Питоном тоже самое?

Это, конечно же, не говорит, что MQL5 плох. Просто Java слишком крута.

Что-то, видно, упустил. С каких пор интерпретаторы сравнялись по скорости с компиляторами?...

Видно такое возможно только с помощью частичной компиляцией, т.е. интерпретаторы не чистые.

Java хоть и транслируется в байт-код, но он имеет свою виртуальную машину выполнения (JVM).
Так же язык является строго типизированным, в отличие от других языков с интерпретатором.
Скорее всего строгая типизация и JVM, тому причина быстрого выполнения и передачи инструкций оборудованию.  
Не спроста американские торговые терминалы пишут на Java. Чикагская биржа CME Group, официально предоставляет терминал который написан на Java.
Как то один программист мне говорил, что язык Java имеет корни из телекоммуникационной сферы.
А сфера телекоммуникации, изначально требует скорости обработки и передачи данных.
Да и компания Oracle имеет своё сообщество по разработке данного языка.
То есть язык жив, и дорабатывается сообществом Oracle.

Кстати бренд Quik и язык LUA, был так же разработан американцами.
Но в мохнатые 90-ые удачно слит(продан) в РФ.
Ещё в те годы, амеры уже понимали, что у LUA нет будущего развития.
И удачно спихнули его в РФ, где только начал формироваться биржевой рынок, после развала союза. 

 
Nikolai Semko:

пребываю в легком шоке. Написал тест на Java. Оказывается Java практически так же быстра как C, а стало быть чуть быстрей MQL5.

Не понимаю, как им это удается, это же по сути язык интерпретатор. 

там модель как в .Net - исходник компилируется в байт-код, это будет еще интерпретатором , а при распаковке байт-кода на конкретном ПК будет уже сгенерирован нативный код под виртуальное окружение в котором он будет исполняться, т.е. это уже скомпилированный код будет

https://habr.com/ru/post/107585/


про Java гуглом "Java компилятор или интерпретатор" - будут похожие статьи

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

MQL тоже интерпретатор. 

Обоснования?

 
Nikolai Semko:

пребываю в легком шоке. Написал тест на Java. Оказывается Java практически так же быстра как C, а стало быть чуть быстрей MQL5.

Не понимаю, как им это удается, это же по сути язык интерпретатор. 

Итересно, с Питоном тоже самое?

Это, конечно же, не говорит, что MQL5 плох. Просто Java слишком крута.

Что-то, видно, упустил. С каких пор интерпретаторы сравнялись по скорости с компиляторами?...

Видно такое возможно только с помощью частичной компиляцией, т.е. интерпретаторы не чистые.

А не возникал вопрос - сколько уходит время на старт? сколько памяти отожрала и сколько потоков запустила JVM для компиляции байт кода? Запустил монстра, который "на лету" скомпилировал hello world, в итоге и там, и там натив. Вот только у Си монстра нет. А про питон

Форум по трейдингу, автоматическим торговым системам и тестированию торговых стратегий

MetaTrader 5 Python User Group - как использовать Python в Метатрейдере

Vict, 2019.12.07 07:12

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

Ну нормально - покупать многоядерный числодробилки с вагоном озу и говорить, что моя джава/шарп/... очень круты в этом тесте, а про общую нагрузку промолчим. Никогда им Си не догнать. Прогресс, взять тетрис из 80х, переписать на шарпе, и гонять столь же быстро, как и раньше, но 60 ядерном ЦПУ)).

ЗЫ: сродни тому, как в Эльбрусах два потока занимаются лишь трансляцией из x86 инструкций. Перевоз Белазом бандероли.

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