Cancellare un array di elementi definiti - pagina 16
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Penso che sia un buon abbinamento per le bandiere:
http://osinavi.ru/asm/4.php
e per gli operatori/confronti inutili...
Torno alla mia incompresa differenza nel tempo di esecuzione di quasi il 100% identico nella logica e nel numero di controlli e somme di due cicli:
Ho già scritto sopra - ho meno operazioni di confronto nel mio codice...
-----
Da fuori scuola, da qualche parte negli anni '90:
1) se (condizioni) A,B,C sono indipendenti, allora devi spingerli nella funzione AND quando la probabilità aumenta, e nella funzione OR quando diminuisce.
e se sono dipendenti, non devono essere combinati in un'unica espressione (cioè do if (A && B) ).
2) Se ci sono loop annidati A,B, allora quello esterno dovrebbe essere più corto
3) Se c'è una condizione all'interno del ciclo, si dovrebbe dividere il ciclo e portare la condizione all'esterno, se possibile.
Ho già scritto sopra - ho meno operazioni di confronto nel mio codice...
-----
da studi extrascolastici, da qualche parte negli anni '90:
1) se (condizioni) A,B,C sono indipendenti, allora dovrebbero essere messe nella funzione AND per probabilità crescente, e nella funzione OR per probabilità decrescente.
e se dipendenti, non possono essere combinati in un'unica espressione (cioè do if (A && B) ).
2) Se ci sono loop annidati A,B, allora quello esterno dovrebbe essere più corto
3) Se c'è una condizione all'interno del ciclo, si dovrebbe dividere il ciclo e portare la condizione all'esterno, se possibile.
1) viceversa, che è esattamente quello che avete fatto voi. Se la prima condizione in un operatore composto AND non viene eseguita, perché dovremmo controllare tutte le altre condizioni? Quindi, prima controlliamo la condizione che è molto probabilmente falsa.
Anche se, sì - lo è: ordinamento per probabilità ascendente delle affermazioni di verità in una condizione composta.
1) il contrario, cosa che avete fatto. Peculiarità dell'esecuzione di operatori condizionali in C.
Forse l'ho scritto male, ma è più facile da spiegare per tutti insieme...
A && B && C
E dovrebbe essere feyed il più presto possibile per evitare di provare tutte le altre condizioni. L'ottimizzatore non lo farà per il programmatore (*), poiché non sa su quali dati verrà eseguito il programma.
A || B || C
qui è viceversa :-) perché è aritmetica booleana. !( ((!A)&&(!B)&&(!C) ) (se non incasini le parentesi, firma di nuovo)
(*) I compilatori ottimizzanti possono contare sul fatto che le condizioni sono impostate proprio così e costruiscono la loro cucina interna su questi presupposti
Forse è scritto male, ma ha più senso per tutti insieme...
A && B && C
E dovrebbe essere feyed il più presto possibile in modo da non passare attraverso tutte le altre condizioni. Significa che il primo predicato da mettere è quello che non riuscirà ad eseguire l'intera catena successiva. L'ottimizzatore non lo farà per il programmatore (*) perché non sa su quali dati il programma sarà eseguito
A || B || C
è il contrario :-) perché l'aritmetica booleana... !( ((!A)&&(!B)&&(!C) ) (se di nuovo tra parentesi, i segni non si confondono)
(*) I compilatori ottimizzanti possono contare sul fatto che le condizioni sono impostate proprio così e costruiscono la loro cucina interna su questi presupposti
Sono completamente d'accordo.
Torno alla mia incompresa differenza di tempo di esecuzione di quasi il 100% identica nella logica e nel numero di controlli e somme di due cicli:
Quindi, di nuovo, perché una tale variante dal codice di Kuznetsov:
lavora più del doppio più velocemente di quello che fa assolutamente la stessa cosa:
Quali sono le meraviglie del compilatore?
È davvero possibile per un design come questo:
il compilatore trova qualche comando speciale di ricerca dell'assemblatore per il processore? Ma c'è un ulteriore controllo i<j all'interno, vero?
Perché la stessa cosa attraverso per viene eseguita molto più lentamente:
Il codice dello script dimostrativo è allegato
Questo è il modo in cui spesso accade. Siete occupati con della spazzatura inutile e scoprite qualcosa di piuttosto interessante.
Sviluppatori, potreste dare un'occhiata al codice eseguibile e vedere cosa fa questa differenza?
È necessario comprendere la logica del compilatore per creare algoritmi più ottimali in futuro.
Che strana situazione in generale. Penso che molte cose dipendano dal compilatore e dalla macchina su cui sto testando. Ecco il mio risultato del tuo esempio su una macchina a 32 bit
come potete vedere non c'è nessun vantaggio particolare. Ed ecco una prova delle funzioni di cancellazione dell'array dell'ultima variante.
A volte durante i test i risultati possono essere molto diversi da quelli precedenti, e non è chiaro perché, forse ha qualcosa a che fare con qualche specifico sistema di interruzione nell'elaborazione del codice MQL
quando si testano gli algoritmi, si dovrebbe prendere
* o set di dati pre-preparati (più o meno simili a quelli effettivamente richiesti),
* o fare un numero molto significativo di passaggi sul RNG,
nei test:
* alternare/rimescolare la sequenza dei test e
* osservare le pause e resettare tutti i tipi di cache
quando si testano gli algoritmi, si dovrebbe prendere
* o set di dati pre-preparati (più o meno simili a quelli effettivamente richiesti),
* o fare un numero molto significativo di passaggi sul RNG,
nei test:
* sequenza di test alternata/miscelata e
* osservare le pause e scaricare ogni sorta di cache
bene, come se usassimo dati pre-preparati. Per tutte le funzioni vengono utilizzati gli stessi dati per il test. Per quanto riguarda lo shuffle/queueing, sì, ho notato una differenza se si cambia l'ordine dei test. Ma come resettare le cache?
quando si testano gli algoritmi, si dovrebbe prendere
* o set di dati pre-preparati (più o meno simili a quelli effettivamente richiesti),
* o fare un numero molto significativo di passaggi sul RNG,
nei test:
* alternare/miscelare le sequenze di test e
* osservare le pause e scaricare ogni sorta di cache
Non prendere in giro la gente