Caractéristiques du langage mql5, subtilités et techniques - page 153

Nouveau commentaire
 
Roffild:

Dans l'aide de ArrayReverse :

La fonctionArraySetAsSeries() ne déplace pas physiquement les éléments du tableau, mais inverse seulement la direction d'indexation vers l'arrière pour organiser l'accès aux éléments comme dans unesérie chronologique. La fonction ArrayReverse() déplace physiquement les éléments du tableau de manière à ce que celui-ci soit "inversé".

Mais ce code prouve le contraire :

Pourquoi ? C'est vrai.

Si nous avons affaire à un tableau où la numérotation est comme dans une série chronologique, c'est-à-dire que la barre zéro est la plus récente et le dernier élément est le plus ancien, lorsqu'un nouvel élément est ajouté, il sera à côté du dernier, c'est-à-dire le plus ancien.

Et si le tableau n'est pas numéroté comme dans les séries chronologiques, alors l'élément zéro est le plus ancien et le dernier élément est le plus récent. Par conséquent, lorsqu'un nouvel élément est ajouté, il sera à côté du dernier.
C'est ce qui se passe dans votre test.

Où est la preuve, je ne comprends pas. Comment pouvons-nous le prouver et trouver où se trouve le début du tableau en mémoire et quel pas d'incrémentation est positif ou négatif.
Vous pouvez le prouver uniquement en passant le tableau et en utilisant des pointeurs.
Mais il est plus facile de le prouver en mesurant le temps nécessaire à l'exécution de cette opération. Si un tableau de 100 000 000 d'éléments se "retourne" instantanément, il est clair qu'il n'y a pas de retournement ; la référence au début change et l'incrément change de signe.
J'utilise la fonctionArraySetAsSeries() tout le temps, et je peux constater qu'elle est absolument gratuite en temps. Donc vous avez tort.

Pour être honnête, je ne comprends pas pourquoi nous avons besoin de la fonctionArrayReverse lentealors que nous avons la fonctionArraySetAsSeries()rapide.

 
Roffild:

Dans l'aide de ArrayReverse :

La fonctionArraySetAsSeries() ne déplace pas physiquement les éléments du tableau, mais inverse seulement la direction d'indexation vers l'arrière pour organiser l'accès aux éléments comme dans unesérie temporelle. La fonction ArrayReverse() déplace physiquement les éléments du tableau de manière à ce que celui-ci soit "inversé".

Mais ce code prouve le contraire :

Il y a une réallocation de la mémoire pour un tableau avec le drapeau asSeries, naturellement ils ont pris cela en compte. Ils doivent avoir quelque chose comme ça là-bas :

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:

Il y a une réallocation de la mémoire pour un tableau avec un drapeau asSeries, bien sûr qu'ils ont pris cela en compte. Ils doivent avoir quelque chose comme ça là-bas :

Oui, ils ont dû le prendre en compte. Mais ce comportement ne correspond pas àCopyRates():

Quelle que soit la propriété du tableau récepteur - as_series=true ou as_series=false, les données seront copiées de manière à ce que l'élément le plus ancien dans le temps se trouve au début de la mémoire physique allouée au tableau.

Également àArrayCopy():

Si count<0 ou count>src_size-src_start, tout le reste du tableau est copié. Les tableaux sont copiés de gauche à droite. Pour les tableaux en série, la position de départ est correctement remplacée , en tenant compte de la copie de gauche à droite.

La dernière phrase est un peu ambiguë.
 

Je suis un peu en état de choc. J'ai écrit un test en Java. Il s'avère que Java est presque aussi rapide que le C, et donc légèrement plus rapide que MQL5.

Je ne sais pas comment ils font, c'est en fait une langue d'interprétation.

Je me demande si c'est la même chose avec Python.

Bien sûr, il ne s'agit pas de dire que MQL5 est mauvais. C'est juste que Java est trop cool.

J'ai dû rater quelque chose. Depuis quand les interprètes sont-ils devenus aussi rapides que les compilateurs ?

Apparemment, cela n'est possible qu'avec une compilation partielle, c'est-à-dire que les interprètes ne sont pas purs.

 
Nikolai Semko:

Je suis un peu en état de choc. J'ai écrit un test en Java. Il s'avère que Java est presque aussi rapide que le C, et donc légèrement plus rapide que MQL5.

Je ne sais pas comment ils font, c'est en fait une langue d'interprétation.

Je me demande si c'est la même chose avec Python.

Bien sûr, il ne s'agit pas de dire que MQL5 est mauvais. C'est juste que Java est trop cool.

J'ai dû rater quelque chose. Depuis quand les interprètes sont-ils devenus aussi rapides que les compilateurs ?

Apparemment, cela n'est possible qu'avec une compilation partielle, c'est-à-dire que les interprètes ne sont pas purs.

MQL est également un interprète.

 
Nikolai Semko:

Je suis un peu en état de choc. J'ai écrit un test en Java. Il s'avère que Java est presque aussi rapide que le C, et donc légèrement plus rapide que MQL5.

Je ne sais pas comment ils font, c'est en fait une langue d'interprétation.

Je me demande si c'est la même chose avec Python.

Bien sûr, il ne s'agit pas de dire que MQL5 est mauvais. C'est juste que Java est trop cool.

J'ai dû rater quelque chose. Depuis quand les interprètes sont-ils devenus aussi rapides que les compilateurs ?

Apparemment, cela n'est possible qu'avec une compilation partielle, c'est-à-dire que les interprètes ne sont pas purs.

Java, bien que traduit en bytecode, possède sa propre machine d' exécution virtuelle (JVM).
Le langage est également strictement typé, contrairement aux autres langages dotés d'un interprète.
Il est fort probable que le typage strict et la JVM soient à l'origine de la rapidité d'exécution et de transmission des instructions au matériel.
Les terminaux de trading américains sont écrits en Java pour une raison. Le CME Group de Chicago propose officiellement des terminaux écrits en Java.
Un programmeur m'a dit un jour que Java avait ses racines dans les télécommunications.
Dans les télécommunications, il faut avoir la vitesse nécessaire pour traiter et transférer les données dès le début.
Et Oracle a sa propre communauté pour le développement de ce langage.
En d'autres termes, le langage est vivant et en cours de finalisation par la communauté Oracle.

Par ailleurs, la marque Quik et le langage LUA ont également été développés par les Américains.
Mais dans les années 90, elle a été vendue avec succès à la Fédération de Russie.
À l'époque, les Américains avaient déjà compris que LUA n'avait pas d'avenir.
Et ils ont réussi à le vendre à la Fédération de Russie, où un marché des changes commençait tout juste à se former après l'effondrement de l'Union soviétique.

 
Nikolai Semko:

Je suis un peu en état de choc. J'ai écrit un test en Java. Il s'avère que Java est presque aussi rapide que le C, et donc légèrement plus rapide que MQL5.

Je ne comprends pas comment ils font, c'est essentiellement un langage d'interprète.

Le modèle est le même qu'en .Net - le code source est compilé en bytecode, il s'agit d'un interprète, et lorsque vous décompressez le bytecode sur un PC donné, le code natif sera généré pour l'environnement virtuel dans lequel il sera exécuté, c'est-à-dire qu'il s'agira d'un code compilé.

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


google "compilateur ou interpréteur Java" pour Java - il y aura des articles similaires

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

MQL est également un interprète.

La justification ?

 
Nikolai Semko:

Je suis un peu en état de choc. J'ai écrit un test en Java. Il s'avère que Java est presque aussi rapide que le C, et donc légèrement plus rapide que MQL5.

Je ne sais pas comment ils font, c'est en fait une langue d'interprétation.

Je me demande si c'est la même chose avec Python.

Bien sûr, il ne s'agit pas de dire que MQL5 est mauvais. C'est juste que Java est trop cool.

J'ai dû rater quelque chose. Depuis quand les interprètes sont-ils devenus aussi rapides que les compilateurs ?

Apparemment, cela n'est possible qu'avec une compilation partielle, c'est-à-dire que les interprètes ne sont pas purs.

Vous êtes-vous déjà demandé combien de temps il faut au démarrage, combien de mémoire est absorbée et combien de threads la JVM exécute pour compiler des octets de code ? J'ai lancé un monstre qui a compilé hello world à la volée et il s'est retrouvé avec les deux nativ. Sauf que le monstre C n'en a pas. Et à propos de Python.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

MetaTrader 5 Python User Group - Comment utiliser Python dans Metatrader

Vict, 2019.12.07 07:12

A propos de python - nous avons récemment parlé de ranger (gestionnaire de fichiers), qui est écrit dans ce langage. Je l'ai utilisé pendant quelques jours et mes impressions sont que c'est une idée cool avec des fonctionnalités intéressantes, mais python est vraiment lent (si certaines tâches compliquées sont effectuées en arrière-plan). Je l'ai arraché, je ne sais pas pourquoi les gens aiment tant Python. Mettez une chose similaire sur C.

Bon ok - achetez un broyeur de chiffres multi-core avec un wagon de RAM et dites que mon java/sharp/... sont très cool dans ce test, et restons discrets sur la charge globale. Ils ne rattraperont jamais C. Progrès, prenez le tetris des années 80, réécrivez-le en sharpe, et faites la course aussi vite qu'avant, mais avec un CPU de 60 cœurs)).

ZS : semblable à la façon dont deux threads dans Elbrus sont seulement impliqués dans la diffusion des instructions x86. BelAZ transportant un colis.

 
Au fait, en ce qui concerne Sharp, il semblerait que les petits logiciels aient permis de compiler directement en code natif. Je n'ai pas encore essayé, mais ça devrait être cool.
1...146147148149150151152153154155156157158159160...247
Nouveau commentaire