C'è già stata una discussione sull'operatore [], che è in qualche modo troppo lento per un linguaggio C++ come questo. Non pensavo che fosse così lento che ArrayCopy potesse strapparlo.
Questa è una domanda separata sugli incrementi all'interno degli operatori.
C'è già stata una discussione sull'operatore [], che è in qualche modo troppo lento per un linguaggio C++ come questo. Non pensavo che fosse così lento che ArrayCopy potesse distruggerlo.
Questa è una domanda separata sugli incrementi all'interno degli operatori.
Qui non c'è nemmeno motivo di eseguire operazioni inutili. Se il looping è in corso. Non c'è bisogno di controllare se l'elemento corrente è fuori dai limiti quando viene copiato. Sarà all'interno dei confini. E non ha senso aggiungere qualcosa, o tirare una variabile in più. Se per default c'è una i. Comunque, c'è tutta una serie di cose banali. Solo per informazione
Hanno raccomandato test contenenti errori (Semko e Pavlov) .
Grazie, l'ho aggiustato.
Maxim Kuznetsov:
anche abbozzato in questo concorso spietato :-)
Non ho controllato di nuovo :-) dovrebbe funzionare...
incluso, ma c'è qualcosa di sbagliato con la prima variante
2018.11.1506:19:01.929 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Pastushak : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 141053 микросекунд
2018.11.1506:19:01.934 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Korotky : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 2494 микросекунд
2018.11.1506:19:01.938 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Fedoseev : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 1869 микросекунд
2018.11.1506:19:01.941 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Semko : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 785 микросекунд
2018.11.1506:19:01.945 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Nikitin : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 2039 микросекунд
2018.11.1506:19:01.952 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Vladimir : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 4385 микросекунд
2018.11.1506:19:01.961 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Peter : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 7476 микросекунд
2018.11.1506:19:01.965 ArrayDeleteValue__13 (.BrentCrud,M1) вариант fann95 : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 1255 микросекунд
2018.11.1506:19:01.969 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Kuznetsov1 : Контрольная сумма = 7219.502578; элементов - 1000000; время выполнения - 2016 микросекунд
2018.11.1506:19:01.975 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Kuznetsov2 : Контрольная сумма = 7225.756203; элементов - 998992; время выполнения - 3965 микросекунд
2018.11.1506:19:01.975 ArrayDeleteValue__13 (.BrentCrud,M1)
2018.11.1506:19:01.975 ArrayDeleteValue__13 (.BrentCrud,M1) === Порядок в массиве не сохраняется ===
2018.11.1506:19:01.978 ArrayDeleteValue__13 (.BrentCrud,M1) вариант Kuznetsov3 : Контрольная сумма = 7222.657252; элементов - 998992; время выполнения - 694 микросекунд
Quali sono le meraviglie del compilatore? È davvero possibile un tale disegno:
while(arr[i]!=x && i<j) i++;
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:
for (;;) if (arr[i]!=x && i<j) i++; elsebreak;
Allego il codice dello script dimostrativo
2018.11.1513:30:51.354 TestLoop (EURUSD,D1) вариант while: Контрольная сумма = 7697.499145747599; элементов - 998975; время выполнения = 771 микросекунд
2018.11.1513:30:51.357 TestLoop (EURUSD,D1) вариант for: Контрольная сумма = 7697.499145747599; элементов - 998975; время выполнения = 1051 микросекунд
2018.11.1513:30:51.360 TestLoop (EURUSD,D1) вариант slow: Контрольная сумма = 7697.499145747599; элементов - 998975; время выполнения = 1531 микросекунд
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.
Consenti l'uso dei cookie per accedere al sito MQL5.com.
Abilita le impostazioni necessarie nel browser, altrimenti non sarà possibile accedere.
Hai effettuato l'accesso. L'autenticazione a due fattori è stata disattivata. Configurala di nuovo e scansiona un nuovo codice QR, oppure continua con l'autenticazione a due fattori disattivata.
C'è già stata una discussione sull'operatore [], che è in qualche modo troppo lento per un linguaggio C++ come questo. Non pensavo che fosse così lento che ArrayCopy potesse strapparlo.
Questa è una domanda separata sugli incrementi all'interno degli operatori.
Perché ti sei sistemato e mi hai buttato fuori? Non va bene.
Non ho buttato fuori nessuno. Quello che ho scaricato, l'ho restituito )))
Non ha buttato fuori nessuno. Quello che hai scaricato lo hai restituito ))))
Bene, quindi hai scaricato l'11, il mio è il 12 (sotto) e tu hai corretto l'11 e l'hai restituito come il 13.
C'è già stata una discussione sull'operatore [], che è in qualche modo troppo lento per un linguaggio C++ come questo. Non pensavo che fosse così lento che ArrayCopy potesse distruggerlo.
Questa è una domanda separata sugli incrementi all'interno degli operatori.
Qui non c'è nemmeno motivo di eseguire operazioni inutili. Se il looping è in corso. Non c'è bisogno di controllare se l'elemento corrente è fuori dai limiti quando viene copiato. Sarà all'interno dei confini. E non ha senso aggiungere qualcosa, o tirare una variabile in più. Se per default c'è una i.
Comunque, c'è tutta una serie di cose banali. Solo per informazione
Bene, quindi hai scaricato l'11, il mio è il 12 (sotto) e tu hai corretto l'11 e l'hai restituito come il 13.
Non ha prestato attenzione. Sostituito il file.
anche abbozzato in questo concorso spietato :-)
Di nuovo, non controllato :-) dovrebbe funzionare...
Hanno raccomandato test contenenti errori (Semko e Pavlov) .
Grazie, l'ho aggiustato.
anche abbozzato in questo concorso spietato :-)
Non ho controllato di nuovo :-) dovrebbe funzionare...
incluso, ma c'è qualcosa di sbagliato con la prima variante
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:
Quindi, di nuovo, perché una tale variante dal codice di Kuznetsov:
funziona più del doppio più velocemente di questo, che fa esattamente la stessa cosa:
Quali sono le meraviglie del compilatore?
È davvero possibile un tale disegno:
while(arr[i]!=x && i<j) i++;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:
Allego il codice dello script dimostrativo
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.
Osservazione interessante. e per amor di interesse, ha eseguito il codice
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:
Quindi, di nuovo, perché una tale variante dal codice di Kuznetsov:
funziona più del doppio più velocemente di uno che fa esattamente la stessa cosa:
Quali sono le meraviglie del compilatore?
È davvero possibile per un costrutto 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:
Allego il codice dello script dimostrativo
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.
Penso che sia un buon abbinamento per le bandiere:
http://osinavi.ru/asm/4.php
E per gli operatori/confronti inutili...