Ottenere il numero di posizioni decimali di qualsiasi numero (non solo le virgolette) bypassando Digits() in MQL4 e MQL5 - pagina 21

 
Nikolai Semko:
Sulla strada per ora. Potete provarlo voi stessi. L'idea è di usare le unioni con array di strutture di diverse dimensioni, per esempio 10, 100, 1000, 10000...
Questo accorcerà il ciclo di ordini di grandezza e ridurrà il numero di chiamate ArrayCopy di ordini di grandezza.
Questo dovrebbe essere vicino alla variante memcopy.

Questa idea è stata utilizzata. In questo caso

Potete vedere tutto nel codice sorgente.
 
fxsaber:

Questa idea è stata utilizzata. Così facendo

Puoi vedere tutto nel sourcebook.
Sì, l'ho cercato. Strano che non abbia alcun effetto.
 
Nikolai Semko:
Sì, l'ho cercato. Strano che non abbia alcun effetto.

C'è una linea nel sorgente che controlla la dimensione

#define  CONVERT_AMOUNT 128

Potete cambiare questo valore e vedere il risultato. Se il valore è superiore a cento, la velocità non aumenta. È infatti facile da spiegare, perché tutti lo stesso numero di elementi sono copiati in totale. E i ritardi associati a piccole porzioni di copia sono eliminati.

 
fxsaber:

Temo che siamo già bloccati nelle prestazioni massime.

Sì, sono d'accordo.
Ho provato - lo stesso risultato del tuo TicksToIntArray_fxsaber4/IntArrayToTicks_fxsaber4

 
Andrey Khatimlianskii:

Avete il codice sorgente, potete misurarlo voi stessi.

Quindi misuratelo. Sono abbastanza sicuro di no, quindi non vedo il motivo di perdere tempo né con l'articolo né con la misura.

 
fxsaber:

Temo che siamo già al limite delle prestazioni.

Ad essere onesti, sono molto sorpreso che siano riusciti ad avvicinarsi così tanto a memcpy. Non può essere. C'è qualcosa che non va.

 
fxsaber:

Temo che siamo già bloccati con le massime prestazioni.

Credo di capire un suo grave errore di calcolo.
Il vostro BANCH seleziona il minimo di 50 corse assolutamente identiche.
Ma il compilatore è un gran furbone e pigro. Non farà lo stesso lavoro 50 volte e ottimizzerà il codice. Ecco perché dovreste almeno cambiare gli array ad ogni esecuzione. Oppure si può sostituire 50 con 1 e aumentare il numero di test. Allora i risultati saranno molto diversi e più obiettivi.

2018.12.09 13:55:43.048 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9813963
2018.12.09 13:55:43.048 StructToArray__2        TicksToIntArray_thexpert
2018.12.09 13:55:43.296 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 247579
2018.12.09 13:55:43.296 StructToArray__2        IntArrayToTicks_thexpert
2018.12.09 13:55:43.544 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 247840
2018.12.09 13:55:43.634 StructToArray__2        true
2018.12.09 13:55:43.766 StructToArray__2        
2018.12.09 13:55:43.766 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:43.766 StructToArray__2        TicksToIntArray_fxsaber4
2018.12.09 13:55:44.118 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 351847
2018.12.09 13:55:44.118 StructToArray__2        IntArrayToTicks_fxsaber4
2018.12.09 13:55:44.452 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 334011
2018.12.09 13:55:44.548 StructToArray__2        true
2018.12.09 13:55:44.692 StructToArray__2        
2018.12.09 13:55:44.692 StructToArray__2        https://www.mql5.com/ru/forum/287618/page18#comment_9814108
2018.12.09 13:55:44.692 StructToArray__2        TicksToIntArray_semko
2018.12.09 13:55:45.037 StructToArray__2        Time[TicksToIntArray(TicksIn,Array)] = 344707
2018.12.09 13:55:45.037 StructToArray__2        IntArrayToTicks_semko
2018.12.09 13:55:45.373 StructToArray__2        Time[IntArrayToTicks(Array,TicksOut)] = 336193
2018.12.09 13:55:45.462 StructToArray__2        true

Quando la differenza rispetto a memcpy è del 40% è più plausibile

Mi chiedo se comprimere l'array avrà un effetto. Un array di tick può essere compresso con un fattore di 10-12. L'unica domanda è se questo farà risparmiare il tempo risultante nell'invio e nella ricezione attraverso la risorsa.

File:
 
Nikolai Semko:

Credo di capire un tuo gravissimo errore di calcolo.
La tua BANCH seleziona il minimo di 50 corse assolutamente identiche.
Ma il compilatore è un gran furbone e pigro. Non farà lo stesso lavoro 50 volte, ottimizzerà il codice.

Il codice è scritto in modo tale che farà esattamente quello che si suppone che faccia. Il compilatore non sarà in grado di influenzare la velocità di memcpy, ma i risultati dei suoi passaggi sono i seguenti

Un ciclo di un passaggio

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 235285
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 192509
true


Su 50

https://www.mql5.com/ru/forum/287618/page18#comment_9813963
TicksToIntArray_thexpert
Time[TicksToIntArray(TicksIn,Array)] = 80970
IntArrayToTicks_thexpert
Time[IntArrayToTicks(Array,TicksOut)] = 81103
true
 
fxsaber:

Il codice è scritto in modo tale che farà esattamente quello che volete che faccia. Il compilatore non è in grado di influenzare la velocità di memcpy, ma i risultati dei passaggi sono

Un ciclo di un passaggio.


Su 50.

Ma allora perché succede questo? Naturalmente, il compilatore non può influenzare il processo di esecuzione di memcpy, ma può rifiutarsi di eseguirlo, tirando i risultati pre-memorizzati dal primo calcolo, se capisce che nessuno dei parametri calcolati cambia durante il ciclo. Questo è il modo in cui io stesso organizzerei il compilatore per correggere gli alogismi del programma.
 
Ilya Malev:

Quindi misuratelo. Sono abbastanza sicuro di no, quindi non vedo il motivo di perdere tempo né con l'articolo né con la misura.

Non sono obbligato a farlo.