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
tempo = 1018
somma = 894782460
tempo = 371
somma = 894782460
Non so perché, ma µl lo supera (e anche le varianti rand() più intricate).
E per me è ovvio: toglierlo dal giro.
Sì, hai ragione, ho provato anche in VS e per qualche motivo non si è ottimizzato affatto, anche se una variante così semplice sembra... Infatti si riduce a questo:
Sì, hai ragione, ho provato anche in VS - per qualche motivo non è ottimizzato per niente, anche se è un'opzione così semplice, sembrerebbe... In sostanza si riduce a questo:
Sei sicuro di aver abilitato tutte le ottimizzazioni nelle impostazioni del progetto? In casi strani accendo la generazione di elenchi di montaggio e li guardo, è molto istruttivo.
Ho deciso di testarlo anche in C# per curiosità. Non solo i risultati sono quasi gli stessi in velocità, ma funzionano anche molto più velocemente di C++.
Risultati:
Somma: 894782460, Tempo: 69 ms.
Somma: 894782460, Tempo: 56 ms
Ed ecco un analogo in C++:
Somma: 894782460, Tempo: 2947 ms
Somma: 894782460, Tempo: 684 ms
Lo provo in VS 2019 etutte le ottimizzazioni sono abilitate .
Al diavolo un tale C++).
p.s. I risultati in C# variano piacevolmente da test a test, ma in media entrambe le varianti sono ugualmente veloci.
Bisogna prima capire le ragioni dei freni. Ho fatto un po' di ricerche e tutto è in linea tranne la chiamata
che si trova in libstdc++. Cioè, sullo sfondo del ciclo quasi nudo il collo di bottiglia sono le chiamate di funzione stesse (e ci sono anche un paio di chiamate da ...replaceEmmPKcm). Il compilatore può ottimizzare all'interno di una singola unità di traduzione. Potete provare a usare LTO (link time optimization), cioè questo permette di ottimizzare in fase di collegamento. Ma non l'ho usato e non lo farò ora. Beh, non c'è niente di particolarmente complicato - passa al compilatore/linker l'opzione -flto (ma ho qualche plugin mancante), troppo pigro per capirlo + potrebbe dover ricostruire libstdc++.
Come sarà con l'ottimizzazione del codice in relazione al prossimo avvitamento dei moduli (dal C++20)? Non so, si può provare in vs, anche se tutto è grezzo e sperimentalehttps://habr.com/en/company/pvs-studio/blog/328482/
c++'u ci mancherà )).
Per motivi di interesse, ho deciso di testare anche in C#. Non solo i risultati sono quasi gli stessi in termini di velocità, ma funzionano anche un ordine di grandezza più veloce del C++.
Risultati:
Somma: 894782460, Tempo: 69 ms
Somma: 894782460, Tempo: 56 ms
Ed ecco un analogo in C++:
Somma: 894782460, Tempo: 2947 ms.
Somma: 894782460, Tempo: 684 ms
Lo provo in VS 2019 etutte le ottimizzazioni sono abilitate .
Al diavolo un tale C++).
p.s. I risultati in C# fluttuano significativamente da test a test, ma in media entrambe le varianti sono uguali in velocità.
Br-r-r-r-r, non esiste! Sharp batte sempre i professionisti puri di un fattore due, metti fuori il progetto plz.
Bambini piccoli :)
Hanno allungato il giocattolo a 10 pagine...
Qui dovremmo capire le ragioni della lentezza all'inizio. Ho fatto un po' di ricerche e tutto è in linea tranne la chiamata
che si trova in libstdc++.
Così sembra aver capito che alloca e cancella la memoria ogni volta anche in questo caso:
A proposito, potrei aver dato risultati sbagliati l'ultima volta, molto probabilmente era in modalità x86. Ora sto testando in modalità x64 e i risultati di C++ sono molto migliori:
1) ~ 2000 msec
2) ~ 200 ms (è 3 volte più veloce).
Anche se ho anche aggiornato Studio all'ultima versione, deve aver influito anche questo dato che anche x86 è più veloce ora rispetto ai test precedenti.
Bene, ora il C++ non è così vergognosamente in ritardo rispetto a Sharp. Solo di 3 volte circa)
Quindi sembra aver capito che alloca e cancella la memoria ogni volta anche in questo caso:
A proposito, potrei aver dato risultati sbagliati l'ultima volta, molto probabilmente era in modalità x86. Ora sto testando in modalità x64 e i risultati di C++ sono molto migliori:
1) ~ 2000 msec
2) ~ 200 ms (è 3 volte più veloce).
Anche se ho anche aggiornato Studio all'ultima versione, deve aver influito anche questo dato che anche x86 è più veloce ora rispetto ai test precedenti.
Bene, ora C++ non sta perdendo così vergognosamente contro Sharp. Solo di 3 volte circa)
Brrr-r-rr, non esiste! Sharp è sempre stato due volte più buono di plus pulito, si mette il progetto fuori plz.
Meglio testare i moduli plus, i risultati sono più interessanti lì, anche se potrebbero essere ancora non documentati.
Ho cercato, risulta che nessun compilatore https://en.cppreference.com/w/cpp/compiler_support ha finito i moduli, quindi non c'è niente da vedere.