ISA intel core i7

[fano]

Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):

1. -O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core Da quel giorno compiliamo tutto in debug
2. Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default

Avevo fatto un po' di test con l'auto vettorizzazione dovevi fare dei for con valori numerici e null'altro bastava una printf() dentro al for e l'auto vettorizzazione si disabilitava (che è ovvio la printf() non è di certo un'operazione vettoriale!) temo che gli ambiti in cui le istruzioni vettoriali hanno senso sia davvero limitato (codec video? Ma non è meglio far fare quel lavoro alla GPU invece che a SSE? Videogames? Di nuovo meglio far fare i conti float alla GPU...).

[GTKM]

Originariamente inviato da fano

Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):

1. -O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core Da quel giorno compiliamo tutto in debug
   
2. Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default

E poi vi divertite con GDB.
Quindi pure con -O2 si rischiano casini?

Beh dai, per il second punto, però, non si può dare la colpa a GCC, anzi, è un problema generale. AVX512 rimarranno segregate per un bel po', secondo me...

[cdimauro]

Lascia almeno che arrivino prima.

[fano]

Originariamente inviato da GTKM

E poi vi divertite con GDB.

Guarda usare GDB è proprio uno spasso
Almeno lasciando i simboli di debug qualcosa ci capisci, ma spesso si va più a "intuito" o a botte di printf() per capire dove il CORE è capitato

Eh ma il C è "efficiente" quindi ce lo teniamo... avevo letto una cosa divertente (credo riguardasse proprio Python vs C @cdimauro) "il tempo del programmatore è più importante di quello della CPU"

Originariamente inviato da GTKM

Quindi pure con -O2 si rischiano casini?

Dalla mia esperienza personale sì: del resto da un linguaggio che "unsafe" by design perché mai non dovrebbe essere così? I problemi sono 2:

1. Le modifiche che GCC fa per "ottimizzare" il tuo codice possono farlo andare in core (inacettabile che codice corretto vada in core perché il compilatore si permette di togliere controlli)
2. Il core generato ha dei "buchi" dove GCC ha ottimizzato il codice
3. Non è più il tuo codice quindi anche volendo cosa ci faresti per risolvere il bug? Togli l'ottimizzazione ecco cosa

Originariamente inviato da GTKM

Beh dai, per il second punto, però, non si può dare la colpa a GCC, anzi, è un problema generale. AVX512 rimarranno segregate per un bel po', secondo me...

No certo il discorso era generale anche Clang fa la stessa cosa ed ogni compilatore che fa la compilazione AOT deve decidere prima per quale generazione di CPU generare il codice e di solito è ovvio usare il minimo comun denominatore (per x86 era tipico usare 486 ).
L'unico motivo per risolvere questo è far la compilazione JIT o forse ed è una cosa che in futuro mi piacerebbe esplorare in Cosmos usare il "CPU dispatch"...

[GTKM]

Originariamente inviato da fano

Guarda usare GDB è proprio uno spasso
Almeno lasciando i simboli di debug qualcosa ci capisci, ma spesso si va più a "intuito" o a botte di printf() per capire dove il CORE è capitato

Eh ma il C è "efficiente" quindi ce lo teniamo... avevo letto una cosa divertente (credo riguardasse proprio Python vs C @cdimauro) "il tempo del programmatore è più importante di quello della CPU"

Ah guarda, non ti dico quanto mi stia divertendo a fare il debugging di quel progetto con le Pthread...

Originariamente inviato da fano

Dalla mia esperienza personale sì: del resto da un linguaggio che "unsafe" by design perché mai non dovrebbe essere così? I problemi sono 2:

1. Le modifiche che GCC fa per "ottimizzare" il tuo codice possono farlo andare in core (inacettabile che codice corretto vada in core perché il compilatore si permette di togliere controlli)
2. Il core generato ha dei "buchi" dove GCC ha ottimizzato il codice
3. Non è più il tuo codice quindi anche volendo cosa ci faresti per risolvere il bug? Togli l'ottimizzazione ecco cosa

No certo il discorso era generale anche Clang fa la stessa cosa ed ogni compilatore che fa la compilazione AOT deve decidere prima per quale generazione di CPU generare il codice e di solito è ovvio usare il minimo comun denominatore (per x86 era tipico usare 486 ).
L'unico motivo per risolvere questo è far la compilazione JIT o forse ed è una cosa che in futuro mi piacerebbe esplorare in Cosmos usare il "CPU dispatch"...

Concordo. Cosa che è un po' OT, sto pensando di usare ICC per quel progetto che ho accennato prima, tanto noi universitari lo possiamo scaricare aggratisse

[fano]

Originariamente inviato da GTKM

Ah guarda, non ti dico quanto mi stia divertendo a fare il debugging di quel progetto con le Pthread...

Te lo avevo detto che i pthread erano pure e semplice satanismo sono "intrisi" di undefined behaviour fino al midollo

Originariamente inviato da GTKM

Concordo. Cosa che è un po' OT, sto pensando di usare ICC per quel progetto che ho accennato prima, tanto noi universitari lo possiamo scaricare aggratisse

Credo qualunque cosa sia meglio del GCC noi purtroppo non possiamo cambiare compilatore perché come il kernel Linux abbiamo fatto la cappellata di dipenderà da feature che solo GCC possiede (diaboliche estensioni!):

1. __builtin_va_arg_pack / __builtin_va_arg_len (siamo costretti ad usare il C, ma alla fine nei paradigmi moderni molte cose del mondo ad oggetti sono necessario per esempio una funzione con argomenti opzionali)
2. _Decimal32 i faccio calcoli con valute: non mi serve che sia veloce, ma che sia corretto

Clang non supporta nulla di tutto questo (l'1 si può fare lo stesso ed in modo più elegante hanno messo un po' di C++ dentro al C! Il 2 mi attacco...) ICC non lo so sinceramente...

[fano]

No il codice era semplicemente:

if (var != NULL) {
      do_something_with_var();
}

Il SEGFAULT era dentro do_something_with_var() e var secondo GDB era NULL! Il compilatore aveva deciso che l'if era inutile e l'aveva raschiato via
'var' poteva senza problemi valere NULL non aveva scuse di "assumere" che fosse sempre valorizzato (era a sua volta un parametro di input di quella funzione).

Sarà stato un bug di quella specifica versione di GCC tanto ne esce una al mese e chi mai le testa?

[cdimauro]

Ma è un bug troppo strano, e soprattutto in un pattern molto comune, per essere sfuggito. Non ci posso credere. :|

[WarDuck]

Originariamente inviato da fano

Due cose riguardo GCC (Clang non l'ho ancora potuto usare seriamente nell'ambito lavorativo):
[list=1][*]-O2 / -O3: quando provammo anni fa ad abilitare l'ottimizzazione ottenemmo due belle cosine: in caso di SEGFAULT il core non aveva senso ("value optimized out"... SEGFAULT comodo!), tolse un if (x != NULL) perché non serviva secondo lui e il codice iniziò ad andare allegramente in core Da quel giorno compiliamo tutto in debug

E' chiaro che un certo tipo di ottimizzazioni rendono più ostico il debug, ma questo è normale (es. l'inlining delle funzioni).

Una delle caratteristiche di -O3 se non ricordo male è abilitare un inlining più aggressivo e una profondità maggiore per il loop unroll, oltre ad attivare (questo lo so per certo) la vettorizzazione.

Due caratteristiche che non sempre sono convenienti, banalmente perché aumentano la size del codice e quindi l'impatto sulla cache istruzioni.

E' possibile visualizzare quali flag vengono usati ad un certo livello di ottimizzazione usando il comando:

gcc -Q --help=optimizers

E passandogli il relativo flag, ad esempio:

gcc -Q --help=optimizers -O2

Ti mostra quali ottimizzazioni sono abilitate a livello O2.

Relativamente alla "rimozione" del controllo NULL, come hai verificato questa cosa? Hai visto il codice assembly che è stato generato?

Se è come dici è presumibile che il compilatore abbia determinato che x non potesse mai essere NULL e quindi ha rimosso un check inutile.

Bisognerebbe vedere il codice originale per poter dire quali assunzioni ha fatto GCC.

Detto ciò in fase di debug presumibilmente conviene compilare con -Og (è un O2 ma con meno inlining).

Originariamente inviato da fano

[*]Lo sapete vero che -march=native si riferisce alla macchina su cui stai compilando ? Chi ti garantisce per esempio che abbia AVX512 anche la macchina su cui il codice verrà poi eseguito? Penso se provi ad usare AVX512 su una CPU che non ha l'istruzione l'applicazione va bellamente in core. Quindi? Quindi o ti limiti a un safe subset (su X64 puoi sperare che SSE1 e SSE2 sono sempre supportate) o sei fritto... e AVX512? Forse lo sfrutteremo tra 10 anni quando sarà safe abiltarla di default

Certamente!!! Se vuoi distribuire un eseguibile che giri su tutte le piattaforme le strade sono due:

- ti adegui restringendo il compilatore a generare codice meno ottimizzato ma che giri su un ampio numero di macchine

- rendi il tutto dinamico, scegliendo a runtime l'implementazione ottimizzata per la CPU che trovi (vedi kernel Linux e molte librerie matematiche).

Originariamente inviato da fano

Avevo fatto un po' di test con l'auto vettorizzazione dovevi fare dei for con valori numerici e null'altro bastava una printf() dentro al for e l'auto vettorizzazione si disabilitava (che è ovvio la printf() non è di certo un'operazione vettoriale!) temo che gli ambiti in cui le istruzioni vettoriali hanno senso sia davvero limitato (codec video? Ma non è meglio far fare quel lavoro alla GPU invece che a SSE? Videogames? Di nuovo meglio far fare i conti float alla GPU...).

L'ambito in cui la vettorizzazione da il meglio di se è proprio quando devi eseguire una singola istruzione su più dati contemporaneamente (SIMD), ed in generale dunque gli ambiti di calcolo numerico sono quelli in cui i vantaggi sono più evidenti.

In realtà negli ultimi anni anche nel processamento delle stringhe, con le istruzioni di shuffle si riescono a fare cose interessanti.

Se fai una chiamata a funzione ad ogni passo di un ciclo for non c'è niente da vettorizzare, l'esecuzione dev'essere per forza di cose serializzata.

Riguardo le GPU sicuramente sono progettate appositamente per il calcolo vettoriale, ma il problema grande che ancora sussiste è la comunicazione tra CPU e GPU, e il fatto che le GPU mediamente hanno una quantità di memoria molto inferiore rispetto a quanto accessibile alla CPU.

Quindi come sempre la risposta a tutto è: dipende.

[cdimauro]

Originariamente inviato da Antonio23

appunto, quel codice è orrendo.

do_something_with_var() è una funzione che non riceve var come parametro di ingresso eppure assume che var sia valido, ed il check di validità è effettuato all'esterno della funzione.

nello scope del chiamante molto probabilmente il compilatore ha assunto che var non poteva cambiare. se volevate semplicemente evitare che il compilatore ottimizzasse quel pezzo di codice potevate semplicemente dichiarare var volatile.

bisogna stare attenti ad usare O3 (personalmente ho sempre usato O2 e solo controllando l'assembly prodotto), questo perchè le regole per poter scrivere codice solido anche dopo l'ottimizzazione sono tante e non sono conosciute.

per poter dire che era un bug di gcc si doveva indagare un po' di più, personalmente 1 volta su 50 forse in problemi di questo tipo il bug è nello strumento piuttosto che nell'utilizzatore (ci vorrebbe un disclaimer "use with care")

Rimane un fatto strano, perché se quella variabile viene scritta da qualche parte, il compilatore dovrebbe tenerne conto e non togliere di mezzo quel controllo.

Originariamente inviato da WarDuck

Detto ciò in fase di debug presumibilmente conviene compilare con -Og (è un O2 ma con meno inlining).

No no: -O0 e basta per il debug!

L'ambito in cui la vettorizzazione da il meglio di se è proprio quando devi eseguire una singola istruzione su più dati contemporaneamente (SIMD), ed in generale dunque gli ambiti di calcolo numerico sono quelli in cui i vantaggi sono più evidenti.

In realtà negli ultimi anni anche nel processamento delle stringhe, con le istruzioni di shuffle si riescono a fare cose interessanti.

Da un po' di anni sono state introdotte anche apposite istruzioni per alcune operazioni comuni con le stringhe, come il confronto.

[fano]

Originariamente inviato da Antonio23

appunto, quel codice è orrendo.

do_something_with_var() è una funzione che non riceve var come parametro di ingresso eppure assume che var sia valido, ed il check di validità è effettuato all'esterno della funzione.

nello scope del chiamante molto probabilmente il compilatore ha assunto che var non poteva cambiare. se volevate semplicemente evitare che il compilatore ottimizzasse quel pezzo di codice potevate semplicemente dichiarare var volatile.

Non mi ricordo adesso se era una funzione o se dentro l'if era inserito il codice in linea, ma dai non è difendibile che GCC ottimizzando leva i controlli che un povero programmatore C è costretto a mettere per evitare che tutto vada in core!

Originariamente inviato da Antonio23

bisogna stare attenti ad usare O3 (personalmente ho sempre usato O2 e solo controllando l'assembly prodotto), questo perchè le regole per poter scrivere codice solido anche dopo l'ottimizzazione sono tante e non sono conosciute.

Boh erano i flag di default di come compilavamo in azienda uso il passato perché le ottimizzazione le ho abolite e compiliamo sempre con -g3 invece...

Almeno se va in core (e il C primo o poi ci andrà) c'è una flebile speranza di recuperare qualcosa dal core se no era tutto un "value optimezed out"

Originariamente inviato da Antonio23

per poter dire che era un bug di gcc si doveva indagare un po' di più, personalmente 1 volta su 50 forse in problemi di questo tipo il bug è nello strumento piuttosto che nell'utilizzatore (ci vorrebbe un disclaimer "use with care")

Per me che l'ottimizzatore faccia corare codice corretto è un bug poi...

[fano]

Un sistema di ottimizzazione che io povero programmatore devo pure "aiutare" se no crea codice non valido non è che sia proprio il massimo dai!
Poi non so che tipo di programmi fate voi, ma i miei devono stare su H24 / 365 giorni all'anno appena c'è un crash tutti i telefoni iniziano a suonare

E' per questo che io inizio ad essere sempre più convinto che il C non sia più una soluzione efficace cosa me ne frega se è veloce se poi si schianta (va in SEGFAULT)?

Ritornando in topic mi è piaciuto come hanno fatto le istruzioni SSE per confrontare i double (CMPSD e CMPSS) che ritorna il valore come un array di bit 1 o 0 nella destinazione se la condizione è true o false... molto semplice da convertire nel tipo bool di .NET: un bel AND e via! Senza dover fare branch o altri casini...

Peccato che manchi l'istruzione equivalente per fare il confronto tra interi la vecchia CMP setta i flag register e lì un branch non te lo toglie nessuno (forse puoi usare l'istruzione TEST per evitarlo?). Avevo provato a cercare nelle istruzione MMX, ma mi sembra che le uniche comparazione erano tra "packed integer" e non scalari... poi MMX usa gli stessi "registri" della FPU quindi mi pare un incubo da usare (infatti mi sa non la usa più nessuno!).

Non mi piace nemmeno che SSE non abbia modo di operare su Int64 (mentre la vecchia FPU sì come è possibile?), né con valori unsigned... questo mi ruppe le uova nel paniere quando cercai di abolire ogni traccia della FPU da Cosmos

[cdimauro]

Originariamente inviato da fano

Ritornando in topic mi è piaciuto come hanno fatto le istruzioni SSE per confrontare i double (CMPSD e CMPSS) che ritorna il valore come un array di bit 1 o 0 nella destinazione se la condizione è true o false... molto semplice da convertire nel tipo bool di .NET: un bel AND e via! Senza dover fare branch o altri casini...

Peccato che manchi l'istruzione equivalente per fare il confronto tra interi la vecchia CMP setta i flag register e lì un branch non te lo toglie nessuno (forse puoi usare l'istruzione TEST per evitarlo?). Avevo provato a cercare nelle istruzione MMX, ma mi sembra che le uniche comparazione erano tra "packed integer" e non scalari... poi MMX usa gli stessi "registri" della FPU quindi mi pare un incubo da usare (infatti mi sa non la usa più nessuno!).

Non mi piace nemmeno che SSE non abbia modo di operare su Int64 (mentre la vecchia FPU sì come è possibile?), né con valori unsigned... questo mi ruppe le uova nel paniere quando cercai di abolire ogni traccia della FPU da Cosmos

Hai dato un'occhiata alle varie PCMP*?

[GTKM]

Originariamente inviato da fano

Un sistema di ottimizzazione che io povero programmatore devo pure "aiutare" se no crea codice non valido non è che sia proprio il massimo dai!
Poi non so che tipo di programmi fate voi, ma i miei devono stare su H24 / 365 giorni all'anno appena c'è un crash tutti i telefoni iniziano a suonare

E' per questo che io inizio ad essere sempre più convinto che il C non sia più una soluzione efficace cosa me ne frega se è veloce se poi si schianta (va in SEGFAULT)?

Sì però non è che va all'improvviso va tutto in SEGFAULT così, senza un motivo. Quando succede è perché c'è un errore nella gestione delle memoria eh.

[fano]

Originariamente inviato da cdimauro

Hai dato un'occhiata alle varie PCMP*?

Si le ho viste, ma appunto funzionano con "packed integers" e non con "scalar integers" cioè non possono essere usati per fare il semplice:

   int a = 42;
   int b = 69;

   bool res = (a == b); // res = false;

Giusto?

[cdimauro]

E tu usa solo la parte bassa / primo elemento.