La mia insoddisfazione al tester di strategia. agli sviluppatori di MQL - pagina 7

[Maxim Kuznetsov]

(Continua)

Ho fatto alcuni semplici programmi di comprensione analitica che mostrano che il mercato ha una forte influenza sui tick Ask e Bid.

il marcato ha già trovato il suo posto nella citazione del forum?

questo è un HIT ... :-)

PS/ Tester è necessario per controllare le prestazioni del robot. Optimizer per assicurarsi che i parametri siano stabili. Il tester non fa strategie e l'ottimizzatore non indovina il mercato.

[fxsaber]

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

La mia insoddisfazione per i tester di strategia. per gli sviluppatori MQL

Renat Fatkhullin, 2017.12.02 15:23

E si confronta come il loro zip in modalità di compressione debole comprime. Forse i file BMP sono così.

La compressione delle risorse funziona.

Non è serio dire queste cose senza prove sullo sfondo della confutazione diretta.

Prendete questo codice. Il mio EX5 è di 1.717.722 byte. ZIP al suo modo di compressione più debole è di 1.177.567 byte.

[Renat Fatkhullin]

fxsaber:

Prendete questo codice. Il mio EX5 è di 1.717.722 byte. ZIP in modalità più debole - 1 177 567 byte.

È vero, questi particolari file sono debolmente compressi e la dimensione del file EX è ragionevole.

Naturalmente, all'interno dell'EX le risorse sono compresse.

[fxsaber]

Renat Fatkhullin:

È vero, questi particolari file si comprimono male e la dimensione del file EX è ragionevole.

Naturalmente, all'interno delle risorse EX sono compresse.

No, purtroppo.

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result));  
}

Risultato

826534
306648

Il tuo ZIP comprime molto meglio di EX5.

[Renat Fatkhullin]

Le risorse sono compresse con l'algoritmo lzss più veloce possibile, non zippate.

Non siamo suicidi a chiudere la cerniera per un tempo molto lungo e poi a togliere la cerniera per un tempo molto lungo.

[fxsaber]

Renat Fatkhullin:

Le risorse sono compresse con l'algoritmo lzss più veloce possibile, non zippate.

Non siamo suicidi a chiudere la cerniera per un tempo molto lungo e poi a togliere la cerniera per un tempo molto lungo.

#define  BENCH(A)                                                              \
{                                                                             \
  const ulong StartTime = GetMicrosecondCount();                              \
  A;                                                                          \
  Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \
} 

void OnStart()
{
  uchar Data[];
  uchar Key[1];
  uchar Result[];
  
  FileLoad("thousands_rubies_galaxy.bmp", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
  
  ArrayFree(Data);
  
  FileLoad("space_wind.wav", Data);  
  BENCH(Print(CryptEncode(CRYPT_ARCH_ZIP, Data, Key, Result)))
}

Risultato

826534
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 53334
306648
Time[Print(CryptEncode(CRYPT_ARCH_ZIP,Data,Key,Result))] = 29029

80ms è un suicidio?

[Renat Fatkhullin]

fxsaber:

Risultato

80ms è un suicidio?

Eseguilo su un celoron.

E poi scalare a una variante di file di dimensioni maggiori nel progetto.

[fxsaber]

Renat Fatkhullin:
Eseguilo su un celoron.

Si tratta di tempo relativo, ovviamente. Sul mio i7, la compilazione del codice sorgente da KB richiede

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 232 msec                1       1

Quando commento questo.

//#resource "\\Files\\thousands_rubies_galaxy.bmp";
//#resource "\\Files\\space_wind.wav";

Ottengo una riduzione di 30ms.

'demo_bitmapoffset.mq5' demo_bitmapoffset.mq5   1       1
0 error(s), 0 warning(s), compile time: 202 msec                1       1

Il passaggio totale allo ZIP puro (80ms) richiederebbe 282ms. Quindi il rallentamento sarebbe del 21,5%. E questo è per il codice sorgente più semplice.

Se prendete dei sorgenti che compilano in pochi secondi, il rallentamento sarà di circa l'1%. Sembra che non sia un grosso problema in questo caso.

[Renat Fatkhullin]

No, credevamo e crediamo ancora che le risorse debbano essere compresse e decompresse il più velocemente possibile sull'intero zoo di processori. Ci sono molti processori strangolati dall'economia, compresi gli atomi semi-vitali. C'è una perdita di velocità di una dozzina di volte rispetto ai potenti processori di oggi.

A proposito, nell'ultima build di MT5 abbiamo aumentato drasticamente la velocità di lancio del terminale e dell'editor dopo una profonda valutazione dell'impatto della compressione delle risorse e dei metodi di inizializzazione della protezione. Abbiamo guadagnato interi secondi sui processori di fascia bassa.

Ciò che era impercettibile su i7/xeon completi, era un disastro da pochi secondi su atomi/celebrone e simili.

[fxsaber]

Renat Fatkhullin:

No, credevamo e crediamo ancora che le risorse debbano essere compresse e decompresse il più velocemente possibile sull'intero zoo di processori. Ci sono molti processori strangolati dall'economia, compresi gli atomi semi-vitali. C'è una perdita di velocità di una dozzina di volte rispetto ai potenti processori di oggi.

A proposito, nell'ultima build di MT5 abbiamo aumentato drasticamente la velocità di lancio del terminale e dell'editor dopo una profonda valutazione dell'impatto della compressione delle risorse e dei metodi di inizializzazione della protezione. Abbiamo guadagnato interi secondi sui processori di fascia bassa.

Ciò che era impercettibile su i7/xeon completi, era un disastro da pochi secondi su atomi/celebrone e simili.

Tanto di cappello per una tale ricerca! Vorrei lo stesso approccio approfondito per CopyTicks e CustomSymbols. Lì è quasi un disastro.