C'è chi crede che ......

Eh si Egregi … ci son diversi individui che pensano che un OS Linux , windows , bsd based … sian così intelligenti da capire che processore usa l’hardware quindi “crede” che il sistema sarà ottimizzato per proprio hardware (in primis CPU)
Nulla di più falso.

Esistono si programmi che evolvendosi “abbracciano le istruzioni più avanzate” dalle SSE* alle AVX*. però questo è un processo secondario in quanto dipendente dal software in questione che può o meno sfruttare determinate caratteristiche; ma qui siamo sempre nell’ambito del “generico” '.

Quel che intendo io è ottimizzare intero sistema sfruttando tutte le istruzioni per propria cpu. certo … non è “semplice” … ma non per noi; Noi possiamo dichiarare di usare appunto il “native” … poi dipende da compilatore che sia GCC o LLVM di “sfruttare” le varie “estensioni” / “innovative istruzioni”.

Ricompoilare kernel senza usufruire per esempio del “-march=native” (in HOSTCFLAGS e HOSTCXXFLAGS) … kernel verrà si ricompilato ma per “generic”.

Spero venga compreso questo … inoltre dico … chi condivide questa affermazione ha compreso…
Chi crede “nelle favole” ovvero che kernel sarà ottimizzato senza precisare il tipo di cpu … beh sarà “lavoro inutile ed insensato”.

-march=native

La migliore soluzione per ottimizzare kernel o anche altri softwares su propria cpu :stuck_out_tongue:

Se sbaglio correggete.

Ma … mi spiace su questo non sbaglio per nulla !!!

E’ così; ho ragione io

Buon tutto.

Mandatemi pure al diavolo … bannatemi se sbaglio.

Parlo a livello “assembly” … hehehehehehe :smiley:

senza istruzioni specifiche … nessun software sarà realizzzato sfruttando le istruzioni di propria cpu.
Non è la I volta che lo dico.

per vedere le flags abilitate, aprite 2 terminali
Uno con

echo 'int main(){return 0;}' > test.c && gcc -v -Q -march=native -O2 test.c -o test && rm test.c test

Versus

echo 'int main(){return 0;}' > test.c && gcc -v -Q -O2 test.c -o test && rm test.c test

Quindi valutate le differenze …

Questa comunque è una cosa da bambini dell’asilo … ma vanno chiarificate le idee fra un software per “generic” (ovvero compatibile con la maggior parte dei sistemi sul pianeta) ed una versione otimizzata per proprio hardware (cpu in primis).

Se ho sbagliato … eliminatemi dal forum.

Se ho parlato correttamente … beh spero qualcuno appogggi il mio discorso.

Non capisco perché debba far tanta fatica per questi “concetti basilari” …

Ci gioco tutto …
se ho sbagliato rispondetemi e bannatemi.

…ma io credo di non aver esternato “sciocchezze informatiche” !!!

Quindi … o arrivederci oppure … “Addio” non mi offenderò …

Ci gioco tutto :frowning:

Se sbaglio eliminatemi pure.

Buon tutto.

La differenza si nota come dici tu quando c’è AVX/SSE/simili di mezzo, come si vede nei vari test di Phoronix riguardanti i software multimediali/calcolo/rendering/simulazione.
In altri casi la differenza si sente meno… Dipende :smiley:

Ottima deduzione, tieni presente però che molti programmi, per evitare tali problemi, rilevano a tempo di esecuzione il tipo di CPU utilizzata, abilitando o meno funzionalità avanzate del set di istruzioni disponibili.
Ad esempio darktable:

[quote][17:37] what about recompiling darktable on localhost with -march=native active? Any improvements on CPUs with AVX?
[17:38] and some new instruction sets stuff
[17:40] <L.> unless the compiler is smart enough to distill our direct sse intrinsic calls, and recompile(? wrong word probably) then into AVX/whatever, i don’t think so
[17:40] <L.> there are ofcourse the plain sse-less variants, but at the very least one needs to manually mess with darktablerc to enable them
[17:41] <L.> there, compiler would be able to take advantage of anything, including AVX, but last time i checked, things are still bad on auto-vectorization front
[17:42] LebedevRI: can’t darktable detect on runtime the kind of CPU and be able to use the most powerful x86_64 istruction sets of lastest CPU generations?
[17:42] <L.> sure it can, the obvious thing is, we only have SSE and opencl codepaths
[17:43] <L.> well, and sse-less/plain
[17:43] <L.> i.e. they would need to be implemented first
[17:43] <L.> bbl
[17:43] ok
[/quote]

Di fatto … non velevo elogiar spuderatanente il “-march=native”.
Semplicemente intendevo che se una perswona ricompila kernl per esempio … e non aggiunge le istruzioni avanzate … non potrà godere di alcun migloramento :slight_smile:
tutti qua :smiley:
Era "solo per “sfatare” alcune convinzioni di alcuni utenti:)

Buon _Tutto :slight_smile:

[quote=Caterpillar]Ottima deduzione, tieni presente però che molti programmi, per evitare tali problemi, rilevano a tempo di esecuzione il tipo di CPU utilizzata, abilitando o meno funzionalità avanzate del set di istruzioni disponibili.
Ad esempio darktable:

[quote][17:37] what about recompiling darktable on localhost with -march=native active? Any improvements on CPUs with AVX?
[17:38] and some new instruction sets stuff
[17:40] <L.> unless the compiler is smart enough to distill our direct sse intrinsic calls, and recompile(? wrong word probably) then into AVX/whatever, i don’t think so
[17:40] <L.> there are ofcourse the plain sse-less variants, but at the very least one needs to manually mess with darktablerc to enable them
[17:41] <L.> there, compiler would be able to take advantage of anything, including AVX, but last time i checked, things are still bad on auto-vectorization front
[17:42] LebedevRI: can’t darktable detect on runtime the kind of CPU and be able to use the most powerful x86_64 istruction sets of lastest CPU generations?
[17:42] <L.> sure it can, the obvious thing is, we only have SSE and opencl codepaths
[17:43] <L.> well, and sse-less/plain
[17:43] <L.> i.e. they would need to be implemented first
[17:43] <L.> bbl
[17:43] ok
[/quote][/quote]

ugh … è un discorso dqavvero molto interessante.

Non a caso alcune “source-based” per determinati pacchetti disabilitano / abuilitano flags in modo da non aver “scompigli” bypassando le “dichiarazioni”.

Mi torna in mente quando anni fa Arch sembrava insuperabile … e li la cosa avvenne in quanto come LDFLAGS, furono forse i primi ad implemerntare:

-Wl,--as-needed

Comunque Fedora scelse anch’esssa di usare questa LDFLAG

Infatti le performances migliorarono moltissimo :slight_smile:

  •  ] cpudetection
    

    media-sound/jack-audio-connection-kit: Enables runtime cpudetection
    - ] 0.121.3-r1
    0.124.1
    0.124.1-r1
    0.125.0

  •  ] cpudetection
    

    media-video/ffmpeg: Enables runtime CPU detection (useful for
    bindist, compatibility on other CPUs)
    - ] (0/54.56.56) 2.8.10
    - ] (0/54.56.56) 2.8.11
    - ] (0/55.57.57) 3.2.4
    - ] (0/55.57.57) 9999

  •  ] cpudetection
    

    media-video/libav: Enables runtime CPU detection (useful for bindist,
    compatibility on other CPUs).
    - ] (0/9) 9.17
    - ] (0/11) 11.3
    - ] (0/11) 11.3-r1
    - ] (0/11) 11.4
    - ] (0/11) 11.6
    - ] (0/11) 11.7
    - ] (0/11) 11.8
    - ] (0/11) 11.9999
    - ] (0/12) 12
    - ] (0/12) 9999

  •  ] cpudetection
    

    media-video/mplayer: Enables runtime CPU detection (useful for
    binpkgs, compatibility on other CPUs)
    - ] 1.2.1
    - ] 1.3.0
    - ] 9999

  •  ] cpudetection
    

    sci-libs/mpir: Enables runtime cpudetection (useful for bindist,
    compatability on other CPUs)
    - ] (0/11) 2.6.0-r2
    - ] (0/16) 2.7.2

Intendevi questo ?

(Chiaramente usando la flag
“cpudetection” penso possa riallacciarsi il discorso che stavi facendo; se invece non è questo ma qualcosa di più “profondo” … grazie per eventuali delucidazioni ^^

Purtroppo non me ne intendo molto di questo lato della programmazione, però se vuoi chiedere informazioni puoi rivolgerti direttamente agli sviluppatori di darktable sul canale IRC #darktable

Sicuramente … comunque ora sembra “a posto” :slight_smile:

Thx :slight_smile: