AMD Ryzen Threadripper 2970WX e 2920X: le CPU enthusiast a 24 e 12 core

[GTKM]

Originariamente inviato da Rubberick

Si ma infatti gente vi rendete conto dei commenti di chi dice: Ah non saranno mai sfruttati?

Ma non è ridicolo ?

Siamo stati per anni con max 4 core in croce ed il mercato software si è seduto su questa situazione da tempo permettendosi di non andare a sviluppare sw in parallelo in tanti casi.

Ma è ora che la situazione cambi.. a meno di non andare sul grafene in tempi ridottissimi ( e dubito che succederà ) i limiti del silicio sono quelli, siamo sui 4ghz per core escludendo OC mostruosi, quindi il progresso va avanti in orizzontale sui core/threads.

Io la vedo come ottima discriminante da parte degli utenti per dare un calcio nel culo agli sviluppatori software che non aggiornano un cavolo e non migliorano 2-3 algoritmi, c'e' poco da fare oramai si va verso il multicore spinto E FINALMENTE..

Tutti a dire che molta roba non è parallelizzabile.. non è vero niente, si può paralllelizzare tantissima roba, sopratutto nel multimedia. Non lo fanno perchè si scocciano di riscrivere il sw, anche se basta che riscrivano solo la parte di rendering il resto non ne ha veramente bisogno..

Probabilmente l'unica cosa che hai scritto è un "Hello World" in JavaScript, per dire così.

Le software house riscrivono il software quando gli conviene. E rendere multithreaded un software in C/C++ bello grosso non questione di spuntare un flag e aspettare che il compilatore faccia tutto.

Ci sono tanti casi in cui i costi della parallelizzazione non vengono adeguatamente compensati dallo "spezzettamento" del lavoro. Soprattutto se i vari thread devono sincronizzarsi tra di loro.

[lucusta]

ma, vedi, generalmente è così, perchè di solito si è software centrici, ossia ci si mette su un software e si lavora; quando serve la CPU si sfrutta al massimo, quando serve la testa la CPU sta ferma, quindi abbreviare i tempi significa avere la CPU giusta per il software che stai usando (ad esempio per il CAD basta un dual core, sempre che sia tirato a 5ghz ed oltre, però).

ma nessuno t'impedisce di superare i limiti del software.
ad esempio, in Handbrake, il 2990WX arriva a 21.8fps; il migliore è il 7980Xe con 18 core e 26.5fps.
se devo convertire un filmato da 2 ore con Handbrake che dovrei fare, prendere il 7980Xe?
io prendo il 2990WX, perchè Handbrake usa al massimo 8 core, ma su un filmato 4K@30fps di 2 ore da convertire, a 21 o 26fps ci metterei dalle 2 ore e 50 alle 2 ore e 20, se lo facessi in unica istanza...
se con il 2990WX lo faccio a 4 istanze, ogniuna che tratta 30 minuti di filmato, il lavoro di cropping lo farei in 40 minuti, più altri 5 per legare gli spezzoni, mentre con il 7980Xe potrei fare 3 spezzoni, 2 per 8 core ed uno per 2 core (ossia due spezzoni da 53 minuti da dare in pasto a due istanze con 8 core ed uno da 14 minuti da dare in pasto ad una ulteriore istanza per soli 2 core), quindi il lavoro me lo fa il 60 minuti, più i 5 minuti per rilegare il tutto.
siamo passati da mezz'ora in più a 20 minuti in meno accorciando il lavoro di 1/3.
magari non sarà proprio così, ma l'idea è che i limiti dei software non sono invalicabili e puoi anche fare multi istanze sul medesimo lavoro, in modo da massimizzare il computo... basta saperlo fare.

io, quando mi divertivo a rippare i miei DVD, lo facevo su due PC, uno per il primo e l'altro per il secondo tempo (ne avevo due simili e li usavo contemporaneamente, anche perchè al tempo ci mettevi una vita anche con 2).

quindi sono sicuramente macchine particolari per esigenze particolari, ma messe nelle giuste mani sono realmente tanta roba da poter utilizzare.

con un 2990WX puoi croppare un video, zippare terabyte di dati , fare un rendering ed allo stesso momento giocare, senza avere problemi...
mi dirai che un utente normale non fa tutti i giorni queste cose tutte insieme, e io ti risponderei dicendoti che queste CPU non sono per uso normale.

[MiKeLezZ]

Se ti compri un 2990WX (1935 euro solo CPU) per "croppare" i video, "zippare" e videogiocare, la CPU di problemi non ne ha, ma te qualcheduno sì...

[coschizza]

Originariamente inviato da lucusta

ma nessuno t'impedisce di superare i limiti del software.
ad esempio, in Handbrake, il 2990WX arriva a 21.8fps; il migliore è il 7980Xe con 18 core e 26.5fps.
se devo convertire un filmato da 2 ore con Handbrake che dovrei fare, prendere il 7980Xe?
io prendo il 2990WX, perchè Handbrake usa al massimo 8 core, ma su un filmato 4K@30fps di 2 ore da convertire, a 21 o 26fps ci metterei dalle 2 ore e 50 alle 2 ore e 20, se lo facessi in unica istanza...
se con il 2990WX lo faccio a 4 istanze, ogniuna che tratta 30 minuti di filmato, il lavoro di cropping lo farei in 40 minuti, più altri 5 per legare gli spezzoni, mentre con il 7980Xe potrei fare 3 spezzoni, 2 per 8 core ed uno per 2 core (ossia due spezzoni da 53 minuti da dare in pasto a due istanze con 8 core ed uno da 14 minuti da dare in pasto ad una ulteriore istanza per soli 2 core), quindi il lavoro me lo fa il 60 minuti, più i 5 minuti per rilegare il tutto.
siamo passati da mezz'ora in più a 20 minuti in meno accorciando il lavoro di 1/3.
magari non sarà proprio così, ma l'idea è che i limiti dei software non sono invalicabili e puoi anche fare multi istanze sul medesimo lavoro, in modo da massimizzare il computo... basta saperlo fare.

non funziona cosi perche l'overhead del software ti fa crollare le performance quindi 4 istanze non vanno come dici tu sopratutto per la configurzione esoterica dei canali di memoria della cpu amd che ti ammazzerebbero le performance

Handbrake usa al massimo 8 core? ma dove noi usiamo istanze anche con 32 o 64 core è scala linearmente

Senza considerare che il 100% dei test su Handbrake che trovi in giro si basano su versioni vecchie mentre le ultime build possono abilitare le avx512 dando un ulteriore boost alle cpu intel soprattutto della serie core-x, insomma la cpu amd in quel campo non ha storia prendendo i numeri reali.

quindi IMHO "con un 2990WX puoi croppare un video, zippare terabyte di dati , fare un rendering ed allo stesso momento giocare, senza avere problemi" è l'esatto opposto visto la configurazione della memoria è la cpu meno adatta per quello che dici e i benchmark lo confermano, molto veglio la cpu a 16 core amd che non soffre di questi problemi o gli epyc o gli intel, la 2990WX è una cpu di nicchia che eccelle in una nicchia di situazioni.

[igiolo]

Originariamente inviato da Rubberick

Si ma infatti gente vi rendete conto dei commenti di chi dice: Ah non saranno mai sfruttati?

Ma non è ridicolo ?

Siamo stati per anni con max 4 core in croce ed il mercato software si è seduto su questa situazione da tempo permettendosi di non andare a sviluppare sw in parallelo in tanti casi.

Ma è ora che la situazione cambi.. a meno di non andare sul grafene in tempi ridottissimi ( e dubito che succederà ) i limiti del silicio sono quelli, siamo sui 4ghz per core escludendo OC mostruosi, quindi il progresso va avanti in orizzontale sui core/threads.

Io la vedo come ottima discriminante da parte degli utenti per dare un calcio nel culo agli sviluppatori software che non aggiornano un cavolo e non migliorano 2-3 algoritmi, c'e' poco da fare oramai si va verso il multicore spinto E FINALMENTE..

Tutti a dire che molta roba non è parallelizzabile.. non è vero niente, si può paralllelizzare tantissima roba, sopratutto nel multimedia. Non lo fanno perchè si scocciano di riscrivere il sw, anche se basta che riscrivano solo la parte di rendering il resto non ne ha veramente bisogno..

beh c'è da dire anche che il paradosso deve essere cambiato da una delle due parti.
alla fine non compri la station wagon se il tuo garage è lungo 4 metri.
ergo adesso le cpu offrono la possibilità diffusa di paralelizzare, in teoria è necessaria questa offerta ORA, per smuovere i programmatori.
se non si innesca questo processo, perlomeno lato hw e disponibilità, chi investirebbe?

[Piedone1113]

Originariamente inviato da coschizza

non funziona cosi perche l'overhead del software ti fa crollare le performance quindi 4 istanze non vanno come dici tu sopratutto per la configurzione esoterica dei canali di memoria della cpu amd che ti ammazzerebbero le performance

Handbrake usa al massimo 8 core? ma dove noi usiamo istanze anche con 32 o 64 core è scala linearmente

Senza considerare che il 100% dei test su Handbrake che trovi in giro si basano su versioni vecchie mentre le ultime build possono abilitare le avx512 dando un ulteriore boost alle cpu intel soprattutto della serie core-x, insomma la cpu amd in quel campo non ha storia prendendo i numeri reali.

quindi IMHO "con un 2990WX puoi croppare un video, zippare terabyte di dati , fare un rendering ed allo stesso momento giocare, senza avere problemi" è l'esatto opposto visto la configurazione della memoria è la cpu meno adatta per quello che dici e i benchmark lo confermano, molto veglio la cpu a 16 core amd che non soffre di questi problemi o gli epyc o gli intel, la 2990WX è una cpu di nicchia che eccelle in una nicchia di situazioni.

Hai reso bene il concetto con i paradigmi attuali.
Tutto il software attuale ( tutto) è scritto per sfruttare pochi core ( davvero ha antenati che sfruttavano un solo core e successivamente si è cercato di distribuire il lavoro su più core)
Ma il fatto di avere tanti core non significa distribuire lo stesso lavoro su più core spezzettandolo, piuttosto il software dovrebbe agire sui core come organizzatore di una catena di montaggio ( lo so che sembra astruso come concetto).
Questo tipo di concatenazione ( adesso un processo fa a+b+c*d domani dovrebbe essere a+b core0 risultato+c core1 risultato *d core2) sarebbe controproducente per cpu con pochi core ( 6 o meno) ma riuscirebbe a scalare bene ( comunque non linearmente) in presenza di più core.
Ps i salti tra i th dovrebbero essere gestiti in modo tale da dover attingere dati alla cache più affine.
Oggi questo non esiste, ma domani lo sarà perchè se prima alle carrozze se aggiungevi 2 cavalli ai due che avevi miglioravi la velocità ma raddoppiandoli ancora non avevi vantaggi cambiando la la carrozza in autovettore l'aumento di cavalli è stato un bel boost fino a spostare il collo di bottiglia su altre questioni ( dove avere 500 o 5000cv praticamente non porta benefici, ma magari peggiora il risultato).

[GTKM]

Originariamente inviato da Piedone1113

Hai reso bene il concetto con i paradigmi attuali.
Tutto il software attuale ( tutto) è scritto per sfruttare pochi core ( davvero ha antenati che sfruttavano un solo core e successivamente si è cercato di distribuire il lavoro su più core)
Ma il fatto di avere tanti core non significa distribuire lo stesso lavoro su più core spezzettandolo, piuttosto il software dovrebbe agire sui core come organizzatore di una catena di montaggio ( lo so che sembra astruso come concetto).
Questo tipo di concatenazione ( adesso un processo fa a+b+c*d domani dovrebbe essere a+b core0 risultato+c core1 risultato *d core2) sarebbe controproducente per cpu con pochi core ( 6 o meno) ma riuscirebbe a scalare bene ( comunque non linearmente) in presenza di più core.
Ps i salti tra i th dovrebbero essere gestiti in modo tale da dover attingere dati alla cache più affine.
Oggi questo non esiste, ma domani lo sarà perchè se prima alle carrozze se aggiungevi 2 cavalli ai due che avevi miglioravi la velocità ma raddoppiandoli ancora non avevi vantaggi cambiando la la carrozza in autovettore l'aumento di cavalli è stato un bel boost fino a spostare il collo di bottiglia su altre questioni ( dove avere 500 o 5000cv praticamente non porta benefici, ma magari peggiora il risultato).

Anche oggi si sfuttano i core come una catena di montaggio, il discorso è sempre lo stesso:
* se il tuo algoritmo può essere scomposto in n parti indipendenti, hai un enorme vantaggio nel distribuirlo su n core (esempio banale: somma tra due vettori);
* se il tuo algoritmo può essere scomposto in n parti, che comunque ad un certo punto devono sincronizzarsi, hai un discreto vantaggio, purché ci sia una buona distribuzione del carico su tutti i core;
* se il tuo algoritmo non si può scomporre in n parti, matematicamente, l'unica cosa che puoi fare è provare a cercare un altro algoritmo che sia parallelizzabile, ammesso (e non concesso) che esista.

Poi, ovviamente se il tuo è un programma enorme che fa n cose (indipendenti tra loro) diverse, allora è banale renderlo multithreaded.

Ma il mondo non è né bianco, né nero.

[Rubberick]

Originariamente inviato da GTKM

Probabilmente l'unica cosa che hai scritto è un "Hello World" in JavaScript, per dire così.

Le software house riscrivono il software quando gli conviene. E rendere multithreaded un software in C/C++ bello grosso non questione di spuntare un flag e aspettare che il compilatore faccia tutto.

Ci sono tanti casi in cui i costi della parallelizzazione non vengono adeguatamente compensati dallo "spezzettamento" del lavoro. Soprattutto se i vari thread devono sincronizzarsi tra di loro.

Ho capito però vedi, di software che non scalano in multithread in quasi nessuna delle loro funzioni ne è pieno il mondo.

Oggi come oggi trovare sw che vanno in mt è ancora troppo raro.

Ora dico: Ci saranno ALCUUUNE situazioni in cui l'algoritmo non è parallelizzabile o in cui il beneficio non vale la candela date le troppe sincronizzazioni necessarie tra più threads..

MA ALCUNE...

Cioè io non ci credo che il 98% dei problemi li fuori non è parallelizzabile nemmeno un pò, inoltre col fatto che ora siamo a 16/32/64 threads non 4-6 per cui il mt con sync non conveniva

A mio avviso le sw house la tirano decisamente troppo con sta storia perchè gli ruga riscrivere codice.. però capisci che d'altro canto non ha manco senso avere macchine oggi AMD ma anche INTEL (perchè pure intel ha proci belli con + di 50 threads) ferme li a guardarsi negli occhi con il task manager che ti indica un 4% di cpu utilizzata..

[Piedone1113]

Originariamente inviato da GTKM

Anche oggi si sfuttano i core come una catena di montaggio, il discorso è sempre lo stesso:
* se il tuo algoritmo può essere scomposto in n parti indipendenti, hai un enorme vantaggio nel distribuirlo su n core (esempio banale: somma tra due vettori);
* se il tuo algoritmo può essere scomposto in n parti, che comunque ad un certo punto devono sincronizzarsi, hai un discreto vantaggio, purché ci sia una buona distribuzione del carico su tutti i core;
* se il tuo algoritmo non si può scomporre in n parti, matematicamente, l'unica cosa che puoi fare è provare a cercare un altro algoritmo che sia parallelizzabile, ammesso (e non concesso) che esista.

Poi, ovviamente se il tuo è un programma enorme che fa n cose (indipendenti tra loro) diverse, allora è banale renderlo multithreaded.

Ma il mondo non è né bianco, né nero.

Guarda che non ho detto che sia semplice ed immediato farlo, ma fatto sta che i software attuali non lavorano in catena di montaggio, ma spalmano in lavoro in più parti. I lavori necessari di sincronizzazione finale sono dovuti a questo ( so benissimo che prima di applicare un determinato calcolo aspetti le dipendenze di due, o più, calcoli in essere).
Considera che fin'ora si è cercato di sfruttare una concatenazione confusionaria perchè più efficiente a causa della limitata capacità di calcolo complessiva, ma domani credo che la possibilità di avere più core disponibili renderà i presupposti di progettazione software molto diversi dagli attuali ( fermo restando che alcune cose non si possano fare diversamente da ora)

[GTKM]

Originariamente inviato da Piedone1113

Guarda che non ho detto che sia semplice ed immediato farlo, ma fatto sta che i software attuali non lavorano in catena di montaggio, ma spalmano in lavoro in più parti. I lavori necessari di sincronizzazione finale sono dovuti a questo ( so benissimo che prima di applicare un determinato calcolo aspetti le dipendenze di due, o più, calcoli in essere).
Considera che fin'ora si è cercato di sfruttare una concatenazione confusionaria perchè più efficiente a causa della limitata capacità di calcolo complessiva, ma domani credo che la possibilità di avere più core disponibili renderà i presupposti di progettazione software molto diversi dagli attuali ( fermo restando che alcune cose non si possano fare diversamente da ora)

Ripeto: "spalmare" i calcoli significa spezzare il lavoro in più parti, far eseguire ogni parte ad un core (o thread), "fondere" i risultati.

Non vedo in che modo sia diverso da quello che, secondo te, si dovrebbe fare in futuro.
Il codice da scrivere è sempre quello.
Tra l'altro, già ora (come detto in precedenza), il numero di core è un semplice parametro che puoi passare in ingresso al tuo software e generare un adeguato numero di thread.

[MiKeLezZ]

Originariamente inviato da Rubberick

Ho capito però vedi, di software che non scalano in multithread in quasi nessuna delle loro funzioni ne è pieno il mondo.

Oggi come oggi trovare sw che vanno in mt è ancora troppo raro.

Ora dico: Ci saranno ALCUUUNE situazioni in cui l'algoritmo non è parallelizzabile o in cui il beneficio non vale la candela date le troppe sincronizzazioni necessarie tra più threads..

MA ALCUNE...

Cioè io non ci credo che il 98% dei problemi li fuori non è parallelizzabile nemmeno un pò, inoltre col fatto che ora siamo a 16/32/64 threads non 4-6 per cui il mt con sync non conveniva

A mio avviso le sw house la tirano decisamente troppo con sta storia perchè gli ruga riscrivere codice.. però capisci che d'altro canto non ha manco senso avere macchine oggi AMD ma anche INTEL (perchè pure intel ha proci belli con + di 50 threads) ferme li a guardarsi negli occhi con il task manager che ti indica un 4% di cpu utilizzata..

Le istruzioni interne della CPU sono tutte parallelizzate, chi più, chi meno, e questo è uno dei modi per guadagnare IPC (oltre l'aumento di frequenza). Per esempio in uno stesso ciclo di clock si può fare sia un'addizione che una moltiplicazione, calcolare prima un'operazione di un'altra successiva, etc. Un CPU architect lo saprà spiegare meglio.

In linea di massima è tutto più o meno parallelizzabile (a meno ovviamente di calcoli ricorsivi, i quali necessitano del risultato precedente per il calcolo successivo).

Il problema è che parallelizzare un codice è un casino e come minimo costringe a un lavoro doppio, come già esplicitato. Questo perché richiede più parti di codice che girino in parallelo e che si sincronizzino fra loro, così che se una parte di codice richiede l'output di un'altra parte di codice, possa riceverlo senza aspettare troppi cicli di clock. Già questo ti fa capire che uno stesso codice se lo spezzi in due avrà sicuramente un deficit prestazionale più o meno grande.

Quindi se sviluppare un codice costa 500 mila dollari, ottimizzarlo per calcoli paralleli ne costa 1 milione. Uno sviluppatore a queste cose ci deve pensare. Come un contadino pensa se sia più conveniente coltivare cipolle oppure carote e in che quantità.

Inoltre solo in pochissimi casi puoi aspettarti di scalare "all'infinito", in genere la parallelizzazione con i calcoli general purpose (e quindi né la grafica dei giochini né l'encoding) implica che tu decida anticipatamente il numero di pezzi in cui spezzettare il codice. E' ancora un sistema manuale. Per esempio in un giochino puoi suddividere i carichi, una cpu per la IA, una per la fisica, una per l'audio, una per l'engine... ma non è che puoi spezzettare più di tanto. Come fai a troncare l'engine in due? Visto che magari un calcolo richiede un risultato precedente? C'è il rischio di perdere un mare di tempo a sincronizzare i risultati. Inoltre avrai sempre uno squilibrio, il codice per l'engine sarà il più lento a completare le proprie operazioni di calcolo e le altre parti di codice, appese a diversi processori, attenderanno che questo abbia finito prima di sincronizzare i risultati e quindi effettuare il calcolo della scena successiva.

Quindi già devi scrivere un codice che ha come "target" un numero di core. Questo girerà anche su un sistema a meno core o a più, ma avrà risultati altalenanti. Il che ti costringe anche a pensarci bene a cosa stai facendo. Se i videogiocatori hanno tutti CPU da 4 core e te gli fornisci un software che gira bene con minimo 6 core... vedrai gente inferocita che brucia nel camino il tuo gioco, a loro dire "scritto con i piedi".

Mentre invece con la grafica dei giochini è tutta una festa di parallelizzazione perché basta suddividere l'immagine e dare in pasto i calcoli, più o meno equamente, ad ogni core. Se hai più core suddividi l'immagine in un maggior numero di pezzi, ognuno avrà meno lavoro da fare e quindi nello stesso arco di tempo calcolerà più frame.

In definitiva se questi 32 core non li usi con software pensato per funzionare con tale numero di core, non te ne fai di nulla. A meno di non spezzettarli a tua volta, creando 4 PC da 8 core ognuno, che facciano girare software pensato per funzionare con 8 core.

Perché solo ora si pensa al multicore? Perché le CPU sono arrivate al limite e più di così non vanno. In realtà oramai è da 10 anni che ci siamo. Le istruzioni le hanno tutte parallelizzate, ci hanno aggiunto algoritmi di predizione, sono state imbottite di cache, tirate a frequenze da 5GHz, ovvero spremute come un limone. Quindi l'unico modo per aumentare la potenza di calcolo è metterci più core. Stessa cosa che ha fatto ARM. E' obbligatorio? No. Se si fosse potuto scegliere, qualsiasi programmatore avrebbe preferito una singola CPU da 30GHz invece che 8 da 4GHz. Ma male non fanno, visto che siamo arrivati a consumi in idle trascurabili e quindi non si sente il loro peso. Ma non possiamo neppure aspettarci miglioramenti lineari con l'aumento dei core e/o che magicamente da oggi tutti i software siano parallelizzabili e parallelizzati.

[Rubberick]

Ho capito.. ma facciamo un esempio classico di quello che ho in mente..

Prendiamo un simpatico programma che deve fare un batch resize di 2000 jpg.. non parlo di TIFF gigantiche da 4 GB l'uno o chissà che..

Dai l'ho tirata semplice..

Avvii il programma.. lui parte.. le fa una alla volta.. ZZzzz... aspetti, occupazione cpu 2%-3%..

FIX PROPOSTO

Quante sono le jpg, 2000? Quanti thread hai, 32?

Facciamo che decido di tenerne 4 liberi per non usarli proprio tutti..

2000/28 = ~ 71.4

Sono file diversi, non hanno correlazione in un processo unico insieme, posso ampiamente sfruttare tutti i core che voglio..

Avvio 28 threads ognuno che chiama la libreria che processa i jpg, quanto potrò occupare ma facciamo anche 1-2 GB di memoria con 28 thread sommati? Oramai il pc più sfigato quanti ne ha, 8 dovrei farcela ?

Il programma a questo punto processa la bellezza di 28 immagini in parallelo, con i threads ognuno nel suo spazio memoria e mi salva il tutto nella cartellina che ho chiesto.. Alla fine del processo il programma principale mi dice "OK lavoro completato"

Ecco cavolate del genere ce ne sono a MILIONI nel mondo software..

Implementare ciò che ho detto è un insulto all'intelligenza da un punto di vista software.. non comporta certo 500mila euro di spesa

EPPURE NON LO FANNO

E' questo il problema di tantissimi software.. si possono parallelizzare situazioni come questa a PACCHI ma ciò non viene fatto.. potrei partire a listarti esempi a mille

[lucusta]

Originariamente inviato da MiKeLezZ

Se ti compri un 2990WX (1935 euro solo CPU) per "croppare" i video, "zippare" e videogiocare, la CPU di problemi non ne ha, ma te qualcheduno sì...

dipende sempre se c'è un guadagno...
puoi avere anche un dual core e fare un mucchio di soldi, come avere un i9-9900K per scrivere solo stupide risposte su un forum.

Originariamente inviato da coschizza

non funziona cosi perche l'overhead del software ti fa crollare le performance quindi 4 istanze non vanno come dici tu sopratutto per la configurzione esoterica dei canali di memoria della cpu amd che ti ammazzerebbero le performance

Handbrake usa al massimo 8 core? ma dove noi usiamo istanze anche con 32 o 64 core è scala linearmente

Senza considerare che il 100% dei test su Handbrake che trovi in giro si basano su versioni vecchie mentre le ultime build possono abilitare le avx512 dando un ulteriore boost alle cpu intel soprattutto della serie core-x, insomma la cpu amd in quel campo non ha storia prendendo i numeri reali.

quindi IMHO "con un 2990WX puoi croppare un video, zippare terabyte di dati , fare un rendering ed allo stesso momento giocare, senza avere problemi" è l'esatto opposto visto la configurazione della memoria è la cpu meno adatta per quello che dici e i benchmark lo confermano, molto veglio la cpu a 16 core amd che non soffre di questi problemi o gli epyc o gli intel, la 2990WX è una cpu di nicchia che eccelle in una nicchia di situazioni.

dipende dal codec in uso, ed i codec free sono generalmente a 4, 6 o 8 istanze.
stessa cosa per le AVX512... se usi un codec (che oggi mi risulta essere proprietario) che le sfrutta, le usi, ma anche qui dipende dalla parallelizzazione che hanno apportato.

"L'hardware su cui si esegue può avere un grande impatto sulle prestazioni. HandBrake può scalare bene fino a 6 core della CPU con rendimenti decrescenti da quel momento in poi.
Quindi una CPU a 4 core può essere quasi due volte più veloce di un equivalente Dual Core."

fonte: https://handbrake.fr/docs/en/latest/...rformance.html

tra l'altro hadbrake lavora con peso sulla L3, non tanto sulla ram (dove una singola istanza riesce a raggiungere solo qualche centinaio di MB se settata con certi parametri, ma senza tutto questo traffico che credi; è solo per sfruttare le letture da disco in istanza unica e non con millelila accessi).
sono i filtri che causano elevato uso della RAM e del suo sfruttamento:

"I filtri sono un'altra cosa che ha un grande effetto (sulle prestazioni). Soprattutto se usi Denoise NLMeans. Questa operazione richiede molta memoria, quindi può rallentare drasticamente le tue codifiche. Ancora una volta, ci sono impostazioni per i filtri che le sintonizzano per la velocità rispetto alla qualità in modo da poter vedere risultati molto diversi a seconda di quale preset / tune usi."

usare handbreak in singola istanza su questi processori per testarne le qualità è una stupidaggine, e saperlo usare è un'altro aspetto che può complicare il lavoro dei "faciloni".

[lucusta]

Originariamente inviato da GTKM

Ripeto: "spalmare" i calcoli significa spezzare il lavoro in più parti, far eseguire ogni parte ad un core (o thread), "fondere" i risultati.

Non vedo in che modo sia diverso da quello che, secondo te, si dovrebbe fare in futuro.
Il codice da scrivere è sempre quello.
Tra l'altro, già ora (come detto in precedenza), il numero di core è un semplice parametro che puoi passare in ingresso al tuo software e generare un adeguato numero di thread.

tu parli comunque di mero sviluppo di una funzione, ma non del lavoro generale che può apportare il lavoro.
l'esempio lampante è proprio la codifica video, dove da key frame a key frame non hai nessuna relazione con altri spezzoni che puoi avere 4, 5 o 10 gruppi dopo, quindi puoi tranquillamente codificare anche da li per una nuova istanza della medesima funzione.
la questione è però che l'istanza deve essere univoca ed isolata, cosa che molte volte non succede perchè non è pensata in questo modo.

[coschizza]

Originariamente inviato da Rubberick

Ho capito.. ma facciamo un esempio classico di quello che ho in mente..

Prendiamo un simpatico programma che deve fare un batch resize di 2000 jpg.. non parlo di TIFF gigantiche da 4 GB l'uno o chissà che..

Dai l'ho tirata semplice..

Avvii il programma.. lui parte.. le fa una alla volta.. ZZzzz... aspetti, occupazione cpu 2%-3%..

FIX PROPOSTO

Quante sono le jpg, 2000? Quanti thread hai, 32?

Facciamo che decido di tenerne 4 liberi per non usarli proprio tutti..

2000/28 = ~ 71.4

Sono file diversi, non hanno correlazione in un processo unico insieme, posso ampiamente sfruttare tutti i core che voglio..

Avvio 28 threads ognuno che chiama la libreria che processa i jpg, quanto potrò occupare ma facciamo anche 1-2 GB di memoria con 28 thread sommati? Oramai il pc più sfigato quanti ne ha, 8 dovrei farcela ?

Il programma a questo punto processa la bellezza di 28 immagini in parallelo, con i threads ognuno nel suo spazio memoria e mi salva il tutto nella cartellina che ho chiesto.. Alla fine del processo il programma principale mi dice "OK lavoro completato"

Ecco cavolate del genere ce ne sono a MILIONI nel mondo software..

Implementare ciò che ho detto è un insulto all'intelligenza da un punto di vista software.. non comporta certo 500mila euro di spesa

EPPURE NON LO FANNO

E' questo il problema di tantissimi software.. si possono parallelizzare situazioni come questa a PACCHI ma ciò non viene fatto.. potrei partire a listarti esempi a mille

faccio spesso quello che scrivi basta che usi software che fa quello che dici ci sono tanti, il primo che mi viene in mente che uso è Light Image Resizer

[MiKeLezZ]

Originariamente inviato da Rubberick

Ho capito.. ma facciamo un esempio classico di quello che ho in mente..

Prendiamo un simpatico programma che deve fare un batch resize di 2000 jpg.. non parlo di TIFF gigantiche da 4 GB l'uno o chissà che..

Dai l'ho tirata semplice..

Avvii il programma.. lui parte.. le fa una alla volta.. ZZzzz... aspetti, occupazione cpu 2%-3%..

FIX PROPOSTO

Quante sono le jpg, 2000? Quanti thread hai, 32?

Facciamo che decido di tenerne 4 liberi per non usarli proprio tutti..

2000/28 = ~ 71.4

Sono file diversi, non hanno correlazione in un processo unico insieme, posso ampiamente sfruttare tutti i core che voglio..

Avvio 28 threads ognuno che chiama la libreria che processa i jpg, quanto potrò occupare ma facciamo anche 1-2 GB di memoria con 28 thread sommati? Oramai il pc più sfigato quanti ne ha, 8 dovrei farcela ?

Il programma a questo punto processa la bellezza di 28 immagini in parallelo, con i threads ognuno nel suo spazio memoria e mi salva il tutto nella cartellina che ho chiesto.. Alla fine del processo il programma principale mi dice "OK lavoro completato"

Ecco cavolate del genere ce ne sono a MILIONI nel mondo software..

Implementare ciò che ho detto è un insulto all'intelligenza da un punto di vista software.. non comporta certo 500mila euro di spesa

EPPURE NON LO FANNO

E' questo il problema di tantissimi software.. si possono parallelizzare situazioni come questa a PACCHI ma ciò non viene fatto.. potrei partire a listarti esempi a mille

Come ho già detto è un discorso di soldi. Il freeware scritto da un singolo sviluppatore non usa il multicore (a meno che non adotti "pappa pronta", ovvero librerie che lo sfruttino).

Se vuoi ottimizzare i tempi, sarai tu che manualmente apri più istanze del programma e per ognuna allochi una parte dei tuoi JPG.

Se invece guardiamo lato software professionale, ad esempio Lightroom, il multicore effettivamente viene GIA' usato.

Però ha un target di 4 core, ovvero è ottimizzato per sistemi che siano dotati di quel numero di core. Da 4 fino a 8 core i benefici diminuiscono, mentre con 32 core le prestazioni ottenute sono identiche a quelle di un 8 core, in quanto non vengono sfruttati.

Lo sfruttamento del multicore piuttosto che di un singolo core a frequenze aumentate porta, nel caso di Lightroom, ad un'efficienza di solo il 60%.

Ovvero, partendo da una base di un singolo core a 4GHz, aggiungere un secondo core sempre a 4GHz non apporta un miglioramento paragonabile ad avere un singolo core a 4+4=8GHz, bensì come uno a 6,4 GHz.

Ecco perché le performance single core in ambito general purpose computing sono sempre molto importanti.

[Rubberick]

Originariamente inviato da coschizza

faccio spesso quello che scrivi basta che usi software che fa quello che dici ci sono tanti, il primo che mi viene in mente che uso è Light Image Resizer

Era solo un esempio.. non mi serve quello nello specifico.. era per far capire che c'e' un buon 60-70 % di situazioni dove i problemi nel passare al multhitread sono cavolate di questa risma...

Perchè ogni volta che si parla di multithread arriva sempre quello giu li a dirti NOO ma non hai fatto teoria degli algoritmi dove in pochissimi casi le cose sono parallelizzabili bla bla...

il 70 % dei software commerciali non implementa parti in multithread stupide come questa..

poi c'e' un 30% che ha parti che richiedono maggiore impegno è vero..

ma il 70% sono robe di sto genere facilmente fattibili, è che gli sviluppatori stanno con le @@ in mano

[Piedone1113]

Originariamente inviato da lucusta

tu parli comunque di mero sviluppo di una funzione, ma non del lavoro generale che può apportare il lavoro.
l'esempio lampante è proprio la codifica video, dove da key frame a key frame non hai nessuna relazione con altri spezzoni che puoi avere 4, 5 o 10 gruppi dopo, quindi puoi tranquillamente codificare anche da li per una nuova istanza della medesima funzione.
la questione è però che l'istanza deve essere univoca ed isolata, cosa che molte volte non succede perchè non è pensata in questo modo.

io invece parto dal presupposto di creare th più semplice da dare in pasto alle molte unità logiche:
prendiamo l'esempio della simulazione di un flusso di particelle:
oggi si divide l'area in zone e si calcola, successivamente si controllano le eventuali correlazioni tra le varie aree ( una particella può passare da un area ad un'altra pe).
bene questo paradigma va bene per pochi core, dove le aree sono più vaste e le correlazioni impattano poco. ma aumentare il numero di core implica diminuire le aree di competenza ed aumentare la verifiche di correlazione ed avremo che probabilmente superato un certo numero di th ( a parità di ips dei core) le prestazioni invece di aumentare diminuiscono ( perchè la verifica di correlazione per forza di cose deve essere mono th).
con un elevato numero di core i th non verranno distribuiti per aree, ma per funzione:
un th darà i vettori di movimento, un th incrocerà le traiettorie, un th misurerà l'energia cinetica della singola particella, un altro th gestirà la fisica degli urti ecc.
man mano che arrivano i risultati il primo th riempierà la nuova mappa e passerà i dati agli altri th etc. tutto in modo sequenziale.
Aumentando il numero dei th si riusciranno a gestire più collisioni contemporaneamente ed il primo th formerà prima la mappa completa delle traiettorie.
Tutto questo è sconveniente per cpu con pochi core, ma all'aumentare dei core la simulazione andrà molto più spedita piuttosto che dividendo il lavoro in aree.
per i video invece questo è relativamente poco efficiente perchè tra 2 keyframe assegni il lavoro al th e non devono aspettare correlazioni con gli altri th ( quindi la scomposizione in aree andrebbe anche bene, a patto che la marcature dei keyframe sia sufficientemente rapida da saturare la capacità di calcolo dei core)

[GTKM]

Originariamente inviato da lucusta

tu parli comunque di mero sviluppo di una funzione, ma non del lavoro generale che può apportare il lavoro.
l'esempio lampante è proprio la codifica video, dove da key frame a key frame non hai nessuna relazione con altri spezzoni che puoi avere 4, 5 o 10 gruppi dopo, quindi puoi tranquillamente codificare anche da li per una nuova istanza della medesima funzione.
la questione è però che l'istanza deve essere univoca ed isolata, cosa che molte volte non succede perchè non è pensata in questo modo.

Guarda che alla fine si tratta comunque di eseguire delle funzioni, solo che devi passarle come argomenti a chiamate di sistema che le eseguano in nuovi thread, usare mutex per proteggere i dati "condivisi" e semafori per sincronizzarli.

Le funzioni che codificano i frame dovranno eseguire le stesse operazioni matematiche in entrambi i casi.

Quello che costa (a livello di tempo, e quindi, denaro) è riscrivere il codice in modo da avere una corretta gestione del multithreading.

[GTKM]

Originariamente inviato da Piedone1113

io invece parto dal presupposto di creare th più semplice da dare in pasto alle molte unità logiche:
prendiamo l'esempio della simulazione di un flusso di particelle:
oggi si divide l'area in zone e si calcola, successivamente si controllano le eventuali correlazioni tra le varie aree ( una particella può passare da un area ad un'altra pe).
bene questo paradigma va bene per pochi core, dove le aree sono più vaste e le correlazioni impattano poco. ma aumentare il numero di core implica diminuire le aree di competenza ed aumentare la verifiche di correlazione ed avremo che probabilmente superato un certo numero di th ( a parità di ips dei core) le prestazioni invece di aumentare diminuiscono ( perchè la verifica di correlazione per forza di cose deve essere mono th).
con un elevato numero di core i th non verranno distribuiti per aree, ma per funzione:
un th darà i vettori di movimento, un th incrocerà le traiettorie, un th misurerà l'energia cinetica della singola particella, un altro th gestirà la fisica degli urti ecc.
man mano che arrivano i risultati il primo th riempierà la nuova mappa e passerà i dati agli altri th etc. tutto in modo sequenziale.
Aumentando il numero dei th si riusciranno a gestire più collisioni contemporaneamente ed il primo th formerà prima la mappa completa delle traiettorie.
Tutto questo è sconveniente per cpu con pochi core, ma all'aumentare dei core la simulazione andrà molto più spedita piuttosto che dividendo il lavoro in aree.
per i video invece questo è relativamente poco efficiente perchè tra 2 keyframe assegni il lavoro al th e non devono aspettare correlazioni con gli altri th ( quindi la scomposizione in aree andrebbe anche bene, a patto che la marcature dei keyframe sia sufficientemente rapida da saturare la capacità di calcolo dei core)

Ma non stai dicendo nulla di nuovo. E ti spiego perché.

Chi sa programmare, già di suo dovrebbe scomporre tutte quelle operazioni in funzioni "semplici", con ognuna un suo compito stabilito. La differenza tra single e multithread e che, in quest'ultimo caso, devi passare tali funzioni a delle chiamate di sistema che le fanno eseguire, appunto, da thread separati. Con in più l'aggiunta di mutex e semafori per la gestione di sincronizzazione e protezione dei dati condivisi.

Da un punto di vista concettuale non è particolarmente complicato, è vero, ma all'atto pratico, se parti da un software pensato per eseguire eseguito in maniera sequenziale, tutto questo può voler dire doverne riscrivere gran parte. E a volte è più facile scrivere una cosa da zero, piuttosto che "trasformare" codice già esistente.