Caratteristiche del linguaggio mql5, sottigliezze e tecniche - pagina 153

 
Roffild:

Nella guida di ArrayReverse:

La funzioneArraySetAsSeries() non sposta fisicamente gli elementi dell'array, ma inverte solo la direzione di indicizzazione all'indietro per organizzare l'accesso agli elementi come in unaserie temporale. La funzione ArrayReverse() sposta fisicamente gli elementi dell'array in modo che l'array sia "invertito".

Ma questo codice dimostra il contrario:

Perché? Proprio così.

Se abbiamo a che fare con un array in cui la numerazione è come in una serie temporale, cioè la barra zero è l'ultima e l'ultima è la più vecchia, quando un nuovo elemento viene aggiunto, sarà accanto all'ultimo, cioè il più vecchio.

E se l'array non è numerato come nelle serie temporali, allora l'elemento zero è il più vecchio e l'ultimo elemento è il più recente. Pertanto, quando un nuovo elemento viene aggiunto, sarà accanto all'ultimo.
Che è quello che succede nel vostro test.

Dove sono le prove, non capisco. Come possiamo provarlo e scoprire dove si trova l'inizio dell'array nella memoria e quale passo di incremento è positivo o negativo.
Puoi provarlo solo passando l'array e usando i puntatori.
Ma è più facile dimostrarlo misurando il tempo necessario per eseguire questa operazione. Se una matrice di 100 000 000 elementi si "capovolge" istantaneamente, è chiaro che non c'è nessun capovolgimento; il riferimento all'inizio cambia e l'incremento cambia il suo segno.
Uso la funzioneArraySetAsSeries() tutto il tempo, e posso vedere che è assolutamente libera nel tempo. Quindi ti sbagli.

Ad essere onesti, non capisco perché abbiamo bisogno della lenta funzioneArrayReverse quando abbiamo la veloceArraySetAsSeries()

 
Roffild:

Nella guida di ArrayReverse:

La funzioneArraySetAsSeries() non sposta fisicamente gli elementi dell'array, ma inverte solo la direzione di indicizzazione all'indietro per organizzare l'accesso agli elementi come in unaserie temporale. La funzione ArrayReverse() sposta fisicamente gli elementi dell'array in modo che l'array sia "invertito".

Ma questo codice dimostra il contrario:

Avete la riallocazione della memoria per un array con il flag asSeries, naturalmente ne hanno tenuto conto. Devono avere qualcosa del genere lì:

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:

Avete la riallocazione della memoria per un array con il flag asSeries, ovviamente ne hanno tenuto conto. Devono avere qualcosa del genere lì:

Sì, devono averne tenuto conto. Ma questo comportamento non corrisponde aCopyRates():

Non importa quale proprietà abbia l'array ricevente - as_series=true o as_series=false, i dati saranno copiati in modo che l'elemento più vecchio nel tempo sia all'inizio della memoria fisica allocata all'array.

Anche aArrayCopy():

Se count<0 o count>src_size-src_start, viene copiato l'intero resto dell'array. Gli array sono copiati da sinistra a destra. Per gli array seriali, la posizione iniziale è correttamente sovrascritta , tenendo conto della copia da sinistra a destra.

L'ultima frase è un po' ambigua.
 

Sono in uno stato di shock. Ho scritto un test in Java. Si è scoperto che Java è quasi veloce come il C, e quindi leggermente più veloce di MQL5.

Non so come facciano, si tratta infatti di un linguaggio interpretativo.

Mi chiedo se è lo stesso con Python.

Naturalmente, non sta dicendo che MQL5 è male. È solo che Java è troppo figo.

Devo essermi perso qualcosa. Da quando gli interpreti sono diventati veloci come i compilatori?

Apparentemente questo è possibile solo con la compilazione parziale, cioè gli interpreti non sono puri.

 
Nikolai Semko:

Sono in uno stato di shock. Ho scritto un test in Java. Si è scoperto che Java è quasi veloce come il C, e quindi leggermente più veloce di MQL5.

Non so come facciano, si tratta infatti di un linguaggio interpretativo.

Mi chiedo se è lo stesso con Python.

Naturalmente, non sta dicendo che MQL5 è male. È solo che Java è troppo figo.

Devo essermi perso qualcosa. Da quando gli interpreti sono diventati veloci come i compilatori?

Apparentemente questo è possibile solo con la compilazione parziale, cioè gli interpreti non sono puri.

MQL è anche un interprete.

 
Nikolai Semko:

Sono in uno stato di shock. Ho scritto un test in Java. Si è scoperto che Java è quasi veloce come il C, e quindi leggermente più veloce di MQL5.

Non so come facciano, si tratta infatti di un linguaggio interpretativo.

Mi chiedo se è lo stesso con Python.

Naturalmente, non sta dicendo che MQL5 è male. È solo che Java è troppo figo.

Devo essermi perso qualcosa. Da quando gli interpreti sono diventati veloci come i compilatori?

Apparentemente questo è possibile solo con la compilazione parziale, cioè gli interpreti non sono puri.

Java, anche se tradotto in bytecode, ha una propria macchina di esecuzione virtuale (JVM).
Il linguaggio è anche strettamente tipizzato, a differenza di altri linguaggi con un interprete.
Molto probabilmente, la digitazione rigorosa e la JVM sono la ragione per l'esecuzione veloce e la trasmissione delle istruzioni all'hardware.
I terminali di trading americani sono scritti in Java per un motivo. Il CME Group di Chicago offre ufficialmente terminali scritti in Java.
Un programmatore una volta mi ha detto che Java ha le sue radici nelle telecomunicazioni.
Nelle telecomunicazioni bisogna avere la velocità per elaborare e trasferire i dati.
E Oracle ha la sua comunità per lo sviluppo di questo linguaggio.
Cioè, il linguaggio è vivo e in fase di finalizzazione da parte della comunità Oracle.

Per inciso, anche il marchio Quik e il linguaggio LUA sono stati sviluppati dagli americani.
Ma negli arruffati anni '90, è stato venduto con successo alla Federazione Russa.
In quegli anni, gli americani avevano già capito che LUA non aveva uno sviluppo futuro.
E l'hanno venduto con successo alla Federazione Russa, dove un mercato di scambio aveva appena iniziato a formarsi dopo il crollo dell'Unione Sovietica.

 
Nikolai Semko:

Sono in uno stato di shock. Ho scritto un test in Java. Si è scoperto che Java è quasi veloce come il C, e quindi leggermente più veloce di MQL5.

Non capisco come facciano, è essenzialmente un linguaggio interpretativo.

Il modello lì è lo stesso che in .Net - il codice sorgente è compilato in bytecode, sarà un interprete, e quando si scompatta il bytecode su un dato PC, il codice nativo sarà generato per l'ambiente virtuale dove sarà eseguito, cioè sarà codice compilato

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


Cerca su Google "Java compiler o interprete" per Java - ci saranno articoli simili

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

MQL è anche un interprete.

Giustificazione?

 
Nikolai Semko:

Sono in uno stato di shock. Ho scritto un test in Java. Si è scoperto che Java è quasi veloce come il C, e quindi leggermente più veloce di MQL5.

Non so come facciano, si tratta infatti di un linguaggio interpretativo.

Mi chiedo se è lo stesso con Python.

Naturalmente, non sta dicendo che MQL5 è male. È solo che Java è troppo figo.

Devo essermi perso qualcosa. Da quando gli interpreti sono diventati veloci come i compilatori?

Apparentemente questo è possibile solo con la compilazione parziale, cioè gli interpreti non sono puri.

Vi siete mai chiesti quanto tempo ci vuole all'avvio, quanta memoria viene inghiottita e quanti thread la JVM esegue per compilare byte di codice? Ho eseguito un mostro che ha compilato hello world al volo e ha finito con entrambi i nativ. Solo che il mostro C non ne ha uno. E riguardo al pitone.

Forum sul trading, sistemi di trading automatico e test di strategia

MetaTrader 5 Python User Group - Come usare Python in Metatrader

Vittoria, 2019.12.07 07:12

A proposito di python - recentemente si è parlato di ranger (file manager), che è scritto in esso. L'ho usato per qualche giorno e le mie impressioni sono che è una bella idea con caratteristiche interessanti, ma python è davvero lento (se alcuni compiti complicati vengono eseguiti in background). L'ho strappato, non so perché alla gente piaccia così tanto il pitone. Mettere una cosa simile su C.

Bene ok - comprate un frantumatore di numeri multi-core con un vagone di RAM e dite che il mio java/sharp/... in questo test sono molto freddi, e non parliamo del carico complessivo. Non raggiungeranno mai C. Progresso, prendere tetris dagli anni 80, riscriverlo in sharpe, e correre veloce come prima, ma con una CPU a 60 core)).

ZS: simile a come due thread in Elbrus sono coinvolti solo nella trasmissione di istruzioni x86. BelAZ che trasporta un pacco.

 
A proposito, per quanto riguarda Sharp, sembra che i piccoli software abbiano reso possibile la compilazione diretta del codice nativo. Non l'ho ancora provato, ma dovrebbe essere forte.