La tela è forte! - pagina 17

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

Analisi morfometrica - analisi delle cellule uccise. Prima li uccidiamo, poi li mettiamo sotto il microscopio.

Morfometria (Greco: morphe form + ...metry)

Questo è tutto. Basta con l'ingombro del soggetto.

 
fxsaber:


Il doppio int è due volte più veloce del doppio

Non vi rendete conto della scala e non state facendo i test correttamente in microsintesi, non considerando le implicazioni di eseguire non 30 funzioni di assemblaggio ma un array di 50k-100k istruzioni.

Confutate ogni punto che ho fatto sopra nella mia risposta originale.

 
Renat Fatkhullin:

Non vi rendete conto della scala e state erroneamente eseguendo test in microsintesi, non considerando le conseguenze dell'esecuzione non di 30 funzioni assembly, ma di un array di 50k-100k istruzioni.

Confuta ciascuno dei miei punti qui sopra nella tua risposta originale.

Ha confutato quel punto (anche se con azioni primitive su ogni tick)

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

La tela è fantastica!

Renat Fatkhullin, 2019.01.15 22:37

Tenendo conto del codice a 64 bit e del nostro compilatore, dobbiamo dimenticare l'intero nella classe di attività basata su calcoli doppi...

Il tester si basa su doppi calcoli. E ce ne sono così tanti in ogni tick che anche una corsa vuota va a 7 milioni di tick al secondo.


Si può scrivere un simulatore con azioni più complicate su ogni tick. Ma la base del Tester è il confronto del prezzo corrente di tick con il prezzo dell'ordine, che rende i codici più alti. Questa affermazione non è fatta nel vuoto. Ho pubblicato misure riproducibili e alternative di calcolo nel pubblico dominio.

 
fxsaber:

Dimostrato questo punto (anche se con azioni primitive su ogni tick)

Il tester si basa su doppi calcoli. E ce ne sono così tanti in ogni tick che anche una corsa a vuoto va a una velocità di 7 milioni di tick al secondo.


È possibile scrivere un simulatore con azioni più complicate su ogni tick. Ma la base del Tester è il confronto tra il prezzo attuale del tick e il prezzo dell'ordine, che è ciò che rende i codici approssimativamente più alti.

Confutate questo:

  1. tutto dovrà essere convertito in ints
  2. ottenere un sacco di ritardi nella conversione dei dati
  3. ottenere un consumo di memoria selvaggio
  4. ottenere il 100% di possibilità di overflow in ogni operazione e la morte totale del sistema
  5. ottenere un disinteresse per gli sviluppatori che si offrono di farvi leggere i loro indicatori e lavorare in ints invece che in dubs
  6. E ta da, non c'è più differenza tra i dub e gli int in velocità. Difficile da credere, ma sì.

Ogni punto, per favore.

Tenete presente che anche un punto 4 o 5 è sufficiente per fondere l'idea dell'accelerazione intera.

Non sto parlando del fatto che il tester non è for(i=0;i<limit;i++ ) { }

Ma posso anche sottolineare che non si può sperare di conservare i risultati dell'ottimizzazione locale del microcodice nelle operazioni intere. A volte è sufficiente aggiungere una stringa innocua in un ciclo per perdere velocità di decine di percentuali. E se si passa ai compiti reali quando il codice è gonfio di lavoro reale, tutti i confronti vanno a farsi benedire lì.

 
Renat Fatkhullin:

Confutate questo:

  1. tutto dovrà essere convertito in ints
  2. ottenere un sacco di ritardi nella conversione dei dati
  3. ottenere un consumo di memoria pazzesco
  4. ottenere una probabilità del 100% di overflow in ogni operazione e la morte totale del sistema
  5. ottenere un disinteresse per gli sviluppatori che si offrono di farvi leggere i loro indicatori e lavorare in ints invece che in dubs
  6. E ta da, non c'è più differenza tra i dub e gli int in velocità. Difficile da credere, ma sì.

Ogni punto, per favore.

Tenete presente che anche un punto 4 o 5 è sufficiente per fondere l'idea dell'accelerazione intera.

Lo scopo era quello di mostrare che ci sono problemi che possono ancora essere risolti in numeri interi per accelerare. Un Tester come questo non è universale, poiché non si adatta almeno al punto 5.


Per quanto riguarda i primi quattro punti, i problemi sono inverosimili. Perché la velocità del Tester è necessaria solo durante l'ottimizzazione. Converte i tick solo una volta per tutto il gruppo di passaggi.

 
fxsaber:

L'obiettivo era quello di mostrare che ci sono problemi che possono ancora essere risolti in numeri interi per accelerare. Un Tester come questo non è universale, poiché non si adatta almeno al punto 5.


Per quanto riguarda i primi quattro punti, i problemi sono inverosimili. Perché la velocità del Tester è necessaria solo durante l'ottimizzazione. Converte i ticchettii solo una volta per tutto il gruppo di passaggi.

Cioè, né i punti 4 né 5 sono confutati.

E anche la conversione che si vuole salvare, che aumenta immediatamente il costo del tempo di diverse volte. Sì, a volte, compresa la memoria per la conversione. Pensavo che tu stessi suggerendo che l'intera piattaforma dovrebbe essere convertita in prezzi int64 per sbarazzarsi delle conversioni.

Anche teoricamente non c'è profitto dalla migrazione all'int già da 10 anni.
 
Renat Fatkhullin:

Non sto parlando di come un tester non sia for(i=0;i<limit;i++ ) { }

Se si tratta di un tester senza timer, è provato che un tester è per i ticchettii.

 
fxsaber:

Se si tratta di un tester senza timer, è provato che un tester è per le zecche.

Questo non è un tester, ma un falso. Senza indicatori, senza profitti o altro. Ma con un rischio costante di overflow di interi.

Non ha nemmeno senso discuterne.

E ancora:

Ma posso anche far notare che non si può sperare di salvare i risultati dell'ottimizzazione del microcodice locale nelle operazioni intere.

A volte è sufficiente aggiungere una stringa innocua in un ciclo per perdere decine di punti percentuali di velocità. E se si passa ai compiti reali quando il codice si gonfia di lavoro reale, tutti i confronti vanno a farsi benedire.

Capite che l'ottimizzazione di 20 comandi dell'assemblatore e del blocco reale per diverse centinaia o migliaia di comandi ucciderà il vostro esempio?
 
Renat Fatkhullin:

Quindi né il punto 4 né il punto 5 sono confutati.

E vuoi anche salvare la conversione, il che moltiplica immediatamente il tempo speso. Sì, molte volte, compresa la memoria di conversione. Pensavo che stessi suggerendo di passare l'intera piattaforma ai prezzi int64 per sbarazzarsi delle conversioni.

Sembra essere un fraintendimento di ciò di cui stavo parlando. Stavo parlando di un esempio di un problema di Tester privato, dove i prezzi interi possono dare un guadagno in certe situazioni. Il caso universale non era in mente. È per questo che il mio Tester, di cui ho dato un link sopra, è implementato sui dub, poiché è universale.

Anche teoricamente non c'è alcun guadagno nell'andare a int per 10 anni.

Non posso essere d'accordo il 100% delle volte.

 
Renat Fatkhullin:

Non è un tester, è un bidone. Senza indicatori, senza profitti e senza niente. Ma con un rischio costante di overflow di interi.

Questo è un add-on per il tuo tester, che fa un passaggio completo con tutti i trade e i profitti, senza alcun cambiamento nel codice di nessun Expert Advisor (con nessun indicatore). Ma lo fa più velocemente del normale Tester. Tutte le prove riproducibili sono state date. Persone della risorsa hanno verificato queste affermazioni.

Motivazione: