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++.
publicclass Program
{
publicstaticvoid Main()
{
int count = (int)10 e6;
{
var watch = System.Diagnostics.Stopwatch.StartNew();
int sum = 0;
for (int i = 0; i < count; i++)
{
string st;
st = "12345678qwertyuioasdfgh";
sum += st[i % 23];
}
Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
}
{
var watch = System.Diagnostics.Stopwatch.StartNew();
int sum = 0;
string st;
for (int i = 0; i < count; i++)
{
st = "12345678qwertyuioasdfgh";
sum += st[i % 23];
}
Console.WriteLine("Sum: {0}, Time: {1} ms", sum, watch.ElapsedMilliseconds);
}
Console.ReadKey();
}
}
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.
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/
Команда Visual C++ рада сообщить, что в Visual Studio 2017 было существенно улучшено качество реализации модулей C++ согласно технической спецификации; также мы добавили возможность подключать Стандартную Библиотеку C++ через интерфейсы модулей. Эти интерфейсы, как и поддержка модулей компилятором, являются экспериментальной разработкой и будут...
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.
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:
char *str = newchar[23];
...
delete str;
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)
non capisci, non è quello che voglio dire. In generale, il test è un giocattolo - un ciclo nudo senza carico utile. Ho cercato di dirvi che le perdite sulle chiamate di funzione, che non possono essere inline. Migliore test più moduli, risultati più interessanti lì, anche se potrebbe essere ancora non sviluppato.
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.