Link all'Articolo: https://www.hwupgrade.it/articoli/cpu/5233/amd-ryzen-threadripper-2990wx-e-2950x-ora-fino-a-32-core_index.html

Iniziano quest'oggi le vendite del primo processore desktop dotato di ben 32 core: AMD Ryzen Threadripper 2990WX vanta una potenza di calcolo ai vertici dell'attuale produzione, ma necessita di applicazioni in grado di scalare su così tanti core per poter offrire il meglio di cui è capace.

Click sul link per visualizzare l'articolo.

Come mai è una delusione nelle conversioni H265? Compilatore o codice sorgente inadeguato?

Devi considerare che ci son stati 10 anni di programmatori e compilatori che hanno lavorato per INTEL, su INTEL, con INTEL e nessun'altro.

Lo stesso scheduler di Windows 10 non è ottimizzato per il Ryzen normale, figuriamoci per i Threadripper.

Posso solo sperare che tra un paio di anni si avranno programmi compilati anche per il mondo AMD e questo potrebbe portare a prestazioni del 10-15% in più senza cambiare nulla. Praticamente gratis si potrebbero avere gli stessi vantaggi prestazionali che si sono avuti con 3 generazioni di INTEL (e relativi esborsi per cambi di socket, RAM e relative MotherBoard).

E' bello, veramente bello... però 250W di TDP sono troppi.. a sto giro penso convenga aspettare l'anno prox la versione a 7nm che si spera avere sui 170W di tpd come l'attuale 1950x

64 thread!! :sbavvv:
Lo voglio!!!

Come mai è una delusione nelle conversioni H265? Compilatore o codice sorgente inadeguato?

Perchè chi scrive i software lo fa non come dovrebbe..

Allo stato attuale questi proci.. questi come anche i corrispettivi intel con molti core potrebbero essere spinti ancora in più.. ma se guardi i grafici del task manager con delusione si vede come il 90% dei software in circolazione non sfrutta bene multicore (qualche volta accelerazioni gpu ma sempre cosi' cosi' a macchia di leopardo)

No ma poi a parte questo scusate redazione ma che fate i test benchmark h265 con RIDIMENSIONAMENTO dell'immagine O_o..

lo scale è gestito in molti software o come filtro grafico sulla cpu o eseguito male con pochi core..

fate una conversione di un video in h265 e basta senza upscale, downscale, etc... altrimenti i risultati sono appiattiti tra una cpu e un altra perchè i dati non sono pronti ed i core aspettano il passaggio dello scaling

Come mai è una delusione nelle conversioni H265? Compilatore o codice sorgente inadeguato?

Nessuno dei 2 è la CPU stessa che non è adeguata per quel tipo di carico

Perchè chi scrive i software lo fa non come dovrebbe..

ne caso della compressione non è vero è ovvio che le CPU non possono andare al 100% fa parte dell algoritmo che deve eseguire non molto paralellizavile in varie sue parti

Nessuno dei 2 è la CPU stessa che non è adeguata per quel tipo di carico

ma quando mai.. la conversione in h264 o h265 viaggia benissimo in multithread.. piuttosto il file risultante non è finemente ottimizzato come dimensione rispetto a come potrebbe in single thread ma parliamo di differenze irrisorie.. roba di qualche MB su files di quasi un GB..

quei bench sull'h265 a naso credo siano influenzati in modo negativo dallo scale, andava fatta una conversione pura e basta senza resize in hd o 1280..

ma quando mai.. la conversione in h264 o h265 viaggia benissimo in multithread.. piuttosto il file risultante non è finemente ottimizzato come dimensione rispetto a come potrebbe in single thread ma parliamo di differenze irrisorie.. roba di qualche MB su files di quasi un GB..

Premetto che ad oggi ho compresso circa 6000 film quindi di task manager ne ho visto a decine e ti assicuro che non ne ho mai visto 1 al 100 su cpu con molti core, ed è normale e se sapessi che calcoli servono per comprimere un video. Inoltre più core uso meno efficiente è la compressione

Premetto che ad oggi ho compresso circa 6000 film quindi di task manager ne ho visto a decine e ti assicuro che non ne ho mai visto 1 al 100 su cpu con molti core, ed è normale e se sapessi che calcoli servono per comprimere un video. Inoltre più core uso meno efficiente è la compressione

Ribadisco chissenefrega che è meno efficiente la compressione, parliamo di differenze di pochi MB su GB di convertito. Se ti serve encodare rapidamente e qui parliamo di ricerca della performance data la tipologia di macchina ti accontenti di un file leggermente più grande ma tempi più veloci.

Conosco i calcoli che vengon fatti dietro e spesso imposto manualmente tutti i parametri degli encoders..

Se poi metti come param per la conversione preset normal o slow non avrai mai il 100% dei core occupati..

Ho fatto un botto di conversioni con il 1950x con tutti i core vicini al 100%

Rimango della mia idea che le performances di questa review siano tutte influenzate dal resize a monte, ma nemmeno per volontà di chi ha fatto la recensione quanto piuttosto che avranno usato un preset standard di handbrake (con resize) che non andava usato per fare un confronto realmente utile.

Ribadisco chissenefrega che è meno efficiente la compressione, parliamo di differenze di pochi MB su GB di convertito. Se ti serve encodare rapidamente e qui parliamo di ricerca della performance data la tipologia di macchina ti accontenti di un file leggermente più grande ma tempi più veloci.

Conosco i calcoli che vengon fatti dietro e spesso imposto manualmente tutti i parametri degli encoders..

Se poi metti come param per la conversione preset normal o slow non avrai mai il 100% dei core occupati..

Ho fatto un botto di conversioni con il 1950x con tutti i core vicini al 100%

Rimango della mia idea che le performances di questa review siano tutte influenzate dal resize a monte, ma nemmeno per volontà di chi ha fatto la recensione quanto piuttosto che avranno usato un preset standard di handbrake (con resize) che non andava usato per fare un confronto realmente utile.

I risultati su handbrake sono anche peggiori su altre recensioni che hanno fatto il test senza resize come su anandtech e altri. È la cpu che nel modello a 32 core è mal bilanciata per certi carichi questo è chiaro è ovvio dallo schema a blocci

I risultati su handbrake sono anche peggiori su altre recensioni che hanno fatto il test senza resize come su anandtech e altri. È la cpu che nel modello a 32 core è mal bilanciata per certi carichi questo è chiaro è ovvio dallo schema a blocci

ma che vuol dire è mal bilanciata per certi carichi? Argomenta perfavore..

ma che vuol dire è mal bilanciata per certi carichi? Argomenta perfavore..

Allora non hai letto le review perché li hai pagine di argomentazioni e non posso scrivere un posti di pagine. Riassumendo solo 2 dei dei 4 accede alla memoria e quindi capirai dove sta il problema in elaborazioni legate a grandi molo di dati. È ribadisco che i benchmark parlano da soli perché mettono nero su bianco dove sono i pregi e i difetti. Ovviamente se uno decide che i difetti non esistono ma sono causa dei programmatori allora meglio non discutere avanti

Nulla da dire, bestiazza notevole.
32 cores fisici sono una marea.. roba che fino ad ora si è vista solo su server o ws top multisocket.

Naturalmente serve anche potenza e dissipazione adeguata considerando che sta mattonella va a 400 watt sotto stress.. dovessi realizzare una ws così andrei senza pensarci su un bel dissi a liquido con radiatore a 3 moduli.

Nulla da dire, bestiazza notevole.
32 cores fisici sono una marea.. roba che fino ad ora si è vista solo su server o ws top multisocket.

Naturalmente serve anche potenza e dissipazione adeguata considerando che sta mattonella va a 400 watt sotto stress.. dovessi realizzare una ws così andrei senza pensarci su un bel dissi a liquido con radiatore a 3 moduli.


volendo puoi anche andare di Aria top gamma come il Silver Arrow TR4;

certamente se uno vuole fare OC deve andare ben oltre il liquido a 3 moduli, visto che a 4 GHz sei sui 500W e a 4,1 sei a 600W; quando uscirono i test a 6000 di cinebench lo dissi subito che erano tirati.... e alla fine è cosi, con un AIO a 4 Ghz duri giusto il tempo del bench....

volendo puoi anche andare di Aria top gamma come il Silver Arrow TR4;

certamente se uno vuole fare OC deve andare ben oltre il liquido a 3 moduli, visto che a 4 GHz sei sui 500W e a 4,1 sei a 600W; quando uscirono i test a 6000 di cinebench lo dissi subito che erano tirati.... e alla fine è cosi, con un AIO a 4 Ghz duri giusto il tempo del bench....

Visto come è precisa la gestione del clock in funzione della temperatura di esercizio penso che, lasciando stare l'overclock, sia piuttosto importante cercare di tenerlo più fresco possibile soprattutto in condizioni difficili (estate e lavoro pieno carico)

Ragiono sul fatto che una simile CPU finisce di certo in WS di lato livello che si dedicano a render, montaggio video, calcolo scientifico o simulazioni.. quindi facile che debbano macinare a manetta per molte ore.
Nessuno prende una bestia del genere se non deve tirargli il collo. :D

Ho fatto un botto di conversioni con il 1950x con tutti i core vicini al 100%
che programma utilizzi? Io adopero handbrake con h264 e sul 1700x che ho, raramente vado oltre l'80% di media, anche usando impostazioni personalizzate come la RD, cabac, 8x8, ecc..

così pochi commenti ?


a parte l' accesso alla memoria limitato (condiviso) è una grande vittoria per per i sostenitori amd.

non ne vedo abbastanza qui

Visto come è precisa la gestione del clock in funzione della temperatura di esercizio penso che, lasciando stare l'overclock, sia piuttosto importante cercare di tenerlo più fresco possibile soprattutto in condizioni difficili (estate e lavoro pieno carico)

Ragiono sul fatto che una simile CPU finisce di certo in WS di lato livello che si dedicano a render, montaggio video, calcolo scientifico o simulazioni.. quindi facile che debbano macinare a manetta per molte ore.
Nessuno prende una bestia del genere se non deve tirargli il collo. :D

si, e con questa CPU diventa ancora piu importante avere un bel case, un bel ricircolo di aria in modo tale da guadagnare piu gradi possibili, senza contare una MB con un bel sistema di alimentazione.

comunque gran bella CPU.

Nessuno dei 2 è la CPU stessa che non è adeguata per quel tipo di carico

non tirare fuori la fregnaccia della parallelizzazione perchè nei video si va a blocchi definiti, quindi puoi avanzare di tanti blocchi quanti core hai...

è solo che i programmi sono ottimizzati fino a 10 core, quanto erano i core degli xeon HEDT intel.

handbrake 1.1.1 è con codice scritto dalla stessa intel in AVX512:
https://software.intel.com/en-us/articles/accelerating-x265-with-intel-advanced-vector-extensions-512-intel-avx-512

Premetto che ad oggi ho compresso circa 6000 film quindi di task manager ne ho visto a decine e ti assicuro che non ne ho mai visto 1 al 100 su cpu con molti core, ed è normale e se sapessi che calcoli servono per comprimere un video. Inoltre più core uso meno efficiente è la compressione

cambia programma (e soprattutto CPU).

l'inversione del coseno è un thread che puoi sminuzzare in forma infinetesimale, essendo tutto basato sul logaritmo.

non tirare fuori la fregnaccia della parallelizzazione perchè nei video si va a blocchi definiti, quindi puoi avanzare di tanti blocchi quanti core hai...

è solo che i programmi sono ottimizzati fino a 10 core, quanto erano i core degli xeon HEDT intel.

handbrake 1.1.1 è con codice scritto dalla stessa intel in AVX512:
https://software.intel.com/en-us/articles/accelerating-x265-with-intel-advanced-vector-extensions-512-intel-avx-512
Falso e te lo dice uno che segue giornalmente da anni lo sviluppo direttamente nel espositori ufficiale
Quindi mi fido più di quello che scrivono i 4 sviluppatori ufficiali che seguiji il progetto è che sento spesso

Allora non hai letto le review perché li hai pagine di argomentazioni e non posso scrivere un posti di pagine. Riassumendo solo 2 dei dei 4 accede alla memoria e quindi capirai dove sta il problema in elaborazioni legate a grandi molo di dati. È ribadisco che i benchmark parlano da soli perché mettono nero su bianco dove sono i pregi e i difetti. Ovviamente se uno decide che i difetti non esistono ma sono causa dei programmatori allora meglio non discutere avanti

Non è scritto proprio cosi' eh.. nel 2990WX tutti e 4 accedono alla memoria ma con 25 GB/s invece che 50 come nel caso del 2590X

Ora non saprei quanto questo vada ad inficiare sulla resa finale, se la resa è come avere due 16 core / 32 threads affiancati il discorso cambia..

Gli unici scenari a non avere rallentamenti sarebbero moltissimi threads in parallelo che hanno funzioni indipendenti tipo chessò server web o altro.. paradossale perchè è più uno scenario da server farm dove ci sono gli EPYC però che questa limitazione non ce l'hanno

Mi chiedo, sul 1950X erano 25 o 50 ?

L'uscita sull'ottimizzazione dei sw è riferita in generale, c'e' una bruttissima piega ancora da parte dei programmatori di ragionare tutto in single thread negli ambiti computazionali, non si pensa a riscrivere un bel nulla però qualsiasi pc oggi ha almeno 8 threads..

non tirare fuori la fregnaccia della parallelizzazione perchè nei video si va a blocchi definiti, quindi puoi avanzare di tanti blocchi quanti core hai...

è solo che i programmi sono ottimizzati fino a 10 core, quanto erano i core degli xeon HEDT intel.

handbrake 1.1.1 è con codice scritto dalla stessa intel in AVX512:
https://software.intel.com/en-us/articles/accelerating-x265-with-intel-advanced-vector-extensions-512-intel-avx-512
cambia programma (e soprattutto CPU).

l'inversione del coseno è un thread che puoi sminuzzare in forma infinetesimale, essendo tutto basato sul logaritmo.
Dov'è la DCT qui: HVEC (https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Coding_efficiency)
https://upload.wikimedia.org/wikipedia/commons/1/13/HEVC_Block_Diagram.png
?

Mi fai vedere come "sminuzzare in forma infinetesimale" questo: CABAC (Context-adaptive binary arithmetic coding) (https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding) ?
Falso e te lo dice uno che segue giornalmente da anni lo sviluppo direttamente nel espositori ufficiale
Quindi mi fido più di quello che scrivono i 4 sviluppatori ufficiali che seguiji il progetto è che sento spesso
*

Poi giustamente riappare TombinoMan ...
Tanto a sto giro non può tirare fuori ne IPC ne Avx 512 ne le mitologiche predizioni che lo hanno riempito di /laugh:
Peccato che nel mentre se invece di usare una sessione di "handbraga" si usano gia 3 sessioni (se uno fa 6000 conversioni e con un processore a 64 thread lancia un solo handb qualche problema c'è): questo con un 1800 ...

https://www.youtube.com/watch?v=NhvL3cHntDA&t=1s

Giusto per spiegare ad un monotread come cdmauro che forse il multicore ha un senso (ma tanto che ne parliamo a fare)

Ripeto con un 1800 ...

https://www.youtube.com/watch?v=NhvL3cHntDA&t=1s


Oppure guardarsi le prestazioni di Premiere 2018 ...

https://www.youtube.com/watch?v=pnFKYFewOlg


Oppure eseguire Handbrake usando un test piu serio ...

https://wccftech.com/review/amd-ryzen-threadripper-2990wx-32-core-cpu-review/5/

Ma tanto.
Di cosa stiamo parlando.

PS
E ripeto ... se con un 32 core 64 thread converto 6000 video e lancio una sessione di conversione alla volta o sono un idiota o sono fazioso.

Benchmark più seri, ma aspetto i proci dell'anno prossimo con Zen 3 per avere un raffronto con quelli attuali

PS
E ripeto ... se con un 32 core 64 thread converto 6000 video e lancio una sessione di conversione alla volta o sono un idiota o sono fazioso.

* this

Poi giustamente riappare TombinoMan ...
E riappare puntualmente il fanboy che deve immediatamente partire con le offese personali, altrimenti non riesce ad appagare il proprio ego violato che ancora gli brucia.
Tanto a sto giro non può tirare fuori ne IPC
Purtroppo per te la codifica CABAC, di cui ho postato un link in precedenza, è estremamente sensibile proprio all'IPC, visto che questo tipo di algoritmo è strettamente sequenziale e particolarmente sensibile alla bontà del branch predictor.

Ma queste son cose note a chi ha lavorato su codec. Ho sviluppato un decoder JPEG 2000 da implementare in hardware, circa 13/14 anni fa, per conto di STMicroelectronic (stage & tesi di laurea), per cui sono particolarmente ferrato sulle pipeline dei codec, i tipi di algoritmi che si usano, e le loro problematiche.

Tu, invece, a parte sbandierare un inutile PhD, che hai fatto di interessante in questo campo?
ne Avx 512
A questo (e alle AVX-2) c'ha pensato lucusta (di cui tutto si può dire fuorché che si tratti di un fanboy Intel), fornendo un link che ti smentisce, sebbene l'abbia riportato per motivazioni diametralmente opposte.
ne le mitologiche predizioni che lo hanno riempito di /laugh:
Quelle di cui vi riempite la bocca, ma di cui "stranamente" non fornite mai link: chissà come mai...
Peccato che nel mentre se invece di usare una sessione di "handbraga" si usano gia 3 sessioni (se uno fa 6000 conversioni e con un processore a 64 thread lancia un solo handb qualche problema c'è): questo con un 1800 ...

https://www.youtube.com/watch?v=NhvL3cHntDA&t=1s
E questo chi l'avrebbe negato, di grazia?
Giusto per spiegare ad un monotread come cdmauro che forse il multicore ha un senso (ma tanto che ne parliamo a fare)
Ah, vero. Dimenticavo che ho qui davanti la mancata medaglia Fields che pontificava sulla mancanza di parallelizzazione degli algoritmi puntando il dito contro gli inetti programmatori.

Aspettiamo ancora tue copiose dimostrazioni in merito, sebbene siano passati un paio d'anni ormai, e "stranamente" non ci fai il piacere di mostrare il frutto del tuo genio (incompreso).
Ripeto con un 1800 ...

https://www.youtube.com/watch?v=NhvL3cHntDA&t=1s


Oppure guardarsi le prestazioni di Premiere 2018 ...

https://www.youtube.com/watch?v=pnFKYFewOlg


Oppure eseguire Handbrake usando un test piu serio ...

https://wccftech.com/review/amd-ryzen-threadripper-2990wx-32-core-cpu-review/5/

Ma tanto.
Di cosa stiamo parlando.
Si stava parlando di precise questioni che erano state sollevate, e a cui hai risposto cambiando completamente argomento. Chissà come mai...
PS
E ripeto ... se con un 32 core 64 thread converto 6000 video e lancio una sessione di conversione alla volta o sono un idiota o sono fazioso.
Francamente non m'è mai capitato uno scenario del genere. Non ho mai convertito BluRay, perché preferisco infilarli nel lettore e godermeli così come sono.
Al massimo, se volessi farmi una copia di backup, sarei costretto a effettuare UNA conversione alla volta, perché in genere sul PC si ha un solo lettore BluRay (nei miei PC nemmeno uno: non uso supporti ottici da anni). E, dunque, potrei procedere a una sola conversione alla volta.

Convertire una enorme libreria di video è, quindi, uno scenario abbastanza inusuale. Ma se hai esempi ove potrebbe essere utile (nonché comune), non hai che da riportarli.

Poi giustamente riappare TombinoMan ...
Tanto a sto giro non può tirare fuori ne IPC ne Avx 512 ne le mitologiche predizioni che lo hanno riempito di /laugh:
Peccato che nel mentre se invece di usare una sessione di "handbraga" si usano gia 3 sessioni (se uno fa 6000 conversioni e con un processore a 64 thread lancia un solo handb qualche problema c'è): questo con un 1800 ...

https://www.youtube.com/watch?v=NhvL3cHntDA&t=1s



https://www.youtube.com/watch?v=pnFKYFewOlg



https://wccftech.com/review/amd-ryzen-threadripper-2990wx-32-core-cpu-review/5/

Ma tanto.
Di cosa stiamo parlando.

PS
E ripeto ... se con un 32 core 64 thread converto 6000 video e lancio una sessione di conversione alla volta o sono un idiota o sono fazioso.

Non posso che sottoscrivere.
Leggere di gente che sostiene di fare 6000 conversioni e non essere capace di capire l'A B C del multitasking fa cadere le braccia.
Peggio ancora chi si ritiene esperto e si arrampica sugli specchi per difendere una posizione stupida e faziosa.

E riappare puntualmente il fanboy che deve immediatamente partire con le offese personali, altrimenti non riesce ad appagare il proprio ego violato che ancora gli brucia.

Purtroppo per te la codifica CABAC, di cui ho postato un link in precedenza, è estremamente sensibile proprio all'IPC, visto che questo tipo di algoritmo è strettamente sequenziale e particolarmente sensibile alla bontà del branch predictor.

Ma queste son cose note a chi ha lavorato su codec. Ho sviluppato un decoder JPEG 2000 da implementare in hardware, circa 13/14 anni fa, per conto di STMicroelectronic (stage & tesi di laurea), per cui sono particolarmente ferrato sulle pipeline dei codec, i tipi di algoritmi che si usano, e le loro problematiche.

Tu, invece, a parte sbandierare un inutile PhD, che hai fatto di interessante in questo campo?

A questo (e alle AVX-2) c'ha pensato lucusta (di cui tutto si può dire fuorché che si tratti di un fanboy Intel), fornendo un link che ti smentisce, sebbene l'abbia riportato per motivazioni diametralmente opposte.

Quelle di cui vi riempite la bocca, ma di cui "stranamente" non fornite mai link: chissà come mai...

E questo chi l'avrebbe negato, di grazia?

Ah, vero. Dimenticavo che ho qui davanti la mancata medaglia Fields che pontificava sulla mancanza di parallelizzazione degli algoritmi puntando il dito contro gli inetti programmatori.

Aspettiamo ancora tue copiose dimostrazioni in merito, sebbene siano passati un paio d'anni ormai, e "stranamente" non ci fai il piacere di mostrare il frutto del tuo genio (incompreso).

Si stava parlando di precise questioni che erano state sollevate, e a cui hai risposto cambiando completamente argomento. Chissà come mai...

Francamente non m'è mai capitato uno scenario del genere. Non ho mai convertito BluRay, perché preferisco infilarli nel lettore e godermeli così come sono.
Al massimo, se volessi farmi una copia di backup, sarei costretto a effettuare UNA conversione alla volta, perché in genere sul PC si ha un solo lettore BluRay (nei miei PC nemmeno uno: non uso supporti ottici da anni). E, dunque, potrei procedere a una sola conversione alla volta.

Convertire una enorme libreria di video è, quindi, uno scenario abbastanza inusuale. Ma se hai esempi ove potrebbe essere utile (nonché comune), non hai che da riportarli.

Ma ti pagano ... ops, vero, ti pagano per dire queste faziosità.

okyZ;45699259']Non posso che sottoscrivere.
Leggere di gente che sostiene di fare 6000 conversioni e non essere capace di capire l'A B C del multitasking fa cadere le braccia.
Forse perché le 6000 conversioni le ha fatte durante l'arco di anni?

Ciò che fa cascare le braccia è la mancanza di apertura mentale.
Peggio ancora chi si ritiene esperto e si arrampica sugli specchi per difendere una posizione stupida e faziosa.
Qui di esperti non non mi pare di averne visti molti.

Molti ciechi fanboy sì, quelli non mancano mai, ma in genere sono tutt'altro che esperti, e si vede subito da quel che scrivono.
okyZ;45699261']Ma ti pagano ... ops, vero, ti pagano per dire queste faziosità.
A te invece ti pagano per non capire quello che scrivono gli altri, o è un dono di natura?

Sono state sollevate PRECISE questioni, a cui ho risposto, visto che almeno io un po' di esperienza in merito di codec video ce l'ho, e non perché mi sono limitato a usare qualche programma.

Se non ti piace quello che ho scritto sei liberissimo di quotarmi e farmi vedere esattamente dove starebbero le incorrettezze.

Se non ti piaccio io, esiste l'ignore list: aggiungimi e vivi tranquillo.

Come vedi c'è una soluzione a tutto.

Sono state sollevate PRECISE questioni, ...
In effetti è stata sollevata una questione interessante, che però non è stata sviluppata.
Si è detto che il problema della codifica è legato alla struttura in CCX di Zen, perchè due moduli del 32 core non hanno accesso diretto alla memoria aumentando le latenze.
Sarebbe quindi interessante vedere qualche studio a riguardo, magari dei test mirati per capire se e quanto l'architettura modulare influisce in questo specifico contesto, dato che ci sono altri fattori che potrebbero contribuire ai risultati dei benchmark.

PS: certo che "6000" conversioni sono tante, fossero anche dieci anni sarebbero quasi due al giorno, e dubito che stia a fare conversioni tutti i giorni. Insomma i margini per lanciarne più di una in parallelo dovrebbero esserci, a meno che non sia un numerone sparato li per dire che ne ha fatte tante.

il rischio è che alcuni thread vengano abbinati non tutti a core fisici, ma in parte a core fisici e in parte a core virtuali resi accessibili dalle tecnologie di simultaneous multithreading.
Non sarebbe più corretto dire che il sistema vede solo i core virtuali e che la differenza di prestazioni risiede essenzialmente nel fatto che quando si caricano due thread sullo stesso core questi devono condividerne le risorse?
I core fisici sono quelli che stanno "sotto", ossia in uno strato logico inferiore, mentre il sistema vede solo i core virtuali, in questo caso due per ogni core fisico.

In questa recensione viene messo ancora più sotto anche dallo stesso Threadripper 1950x

https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/10

Secondo me è evidente che c'è qualcosa che non và: o nei metodi di test o nel modo in cui sono stati compilati o scritti, ma può essere anche il processore stesso. Aldilà delle supposizioni e speculazioni fatte, qualuno sà effettivamente dove stà il problema (o i problemi)?

Com'è possibile che ci sia così tanta differenza fra il rendering, dove svetta incima a tutti gli altri processori, e l'encoding, dov'è addirittura peggio della precedente generazione a meno cores leggendo quella recensione (vedi 1950x).

7zip x264 x265 winrar ... qualcosa che non và c'è; sarà anche il discorso dell'IPC ma non può essere solo quello... il 2990wx ha il doppio dei tread del 7980xe e và la metà secondo l'ultimo test della recensione che ho linkato.

Io se dovessi scegliere questo 2990wx lo farei per fare rendering ma anche per fare un successivo encoding. Non credo che AMD sia così ingenua da darsi la zappa sui piedi. Sarà anche il processore ad essere "inadeguato al tipo di carico" ma secondo me è anche il tipo di carico che non vuol essere adeguato al tipo di processore.

okyZ;45699259']Non posso che sottoscrivere.
Leggere di gente che sostiene di fare 6000 conversioni e non essere capace di capire l'A B C del multitasking fa cadere le braccia.
Peggio ancora chi si ritiene esperto e si arrampica sugli specchi per difendere una posizione stupida e faziosa.

il problema non è leggere ma comprendere :asd:

guarda che il discorso era meramente tecnico.... non era incentrato su quello che quello che fa le conversioni, che le fa una alla volta perchè è masochista...

il punto del discorso è che il 32 core è una CPU fantastica ma che si porta dietro delle ovvie limitazioni rispetto agli EPYC che in alcuni scenari non lo fanno brillare... ma è una cosa d'altra parte ovvia, visto che non esiste la CPU idilliaca.... e per mostrare queste limitazioni ha preso come esempio la codifica...

Vedo che le scatole diventano sempre più grandi.
Quando è iniziata la crisi si erano ridotte a tal punto che quasi te li davano avvolti in un foglio di giornale.

Tutto quelche volete. Ma dio santo è possibile che in 3 recensioni diverse saltano fuori 3 risultati diversi solo per quanto riguarda l'encoding ?

In effetti è stata sollevata una questione interessante, che però non è stata sviluppata.
Si è detto che il problema della codifica è legato alla struttura in CCX di Zen, perchè due moduli del 32 core non hanno accesso diretto alla memoria aumentando le latenze.
Sarebbe quindi interessante vedere qualche studio a riguardo, magari dei test mirati per capire se e quanto l'architettura modulare influisce in questo specifico contesto, dato che ci sono altri fattori che potrebbero contribuire ai risultati dei benchmark.
Nella recensione di AnandTech è presente anche EPYC, e dunque stesso numero di core e thread hardware, ma TR gli è sempre davanti (al momento ho visionato solo i risultati di HandBrake, perché in questa parte della discussione si sta parlando solo di quest'applicazione).

Immagino che a questo punto sia dovuto a eventuali maggiori frequenze di TR, e ai miglioramenti microarchitetturali di questa revisione di Zen (EPYC usa la prima versione di Zen).

Sarebbe necessario un test con EPYC avente le stesse caratteristiche dell'attuale TR per essere sicuri che si tratti effettivamente della struttura dei CCX di Zen, ma dovremo ancora aspettare.
PS: certo che "6000" conversioni sono tante, fossero anche dieci anni sarebbero quasi due al giorno, e dubito che stia a fare conversioni tutti i giorni. Insomma i margini per lanciarne più di una in parallelo dovrebbero esserci, a meno che non sia un numerone sparato li per dire che ne ha fatte tante.
Potrebbe anche aver usato più PC. Comunque son dettagli che potrà fornire soltanto lui.
Non sarebbe più corretto dire che il sistema vede solo i core virtuali e che la differenza di prestazioni risiede essenzialmente nel fatto che quando si caricano due thread sullo stesso core questi devono condividerne le risorse?
I core fisici sono quelli che stanno "sotto", ossia in uno strato logico inferiore, mentre il sistema vede solo i core virtuali, in questo caso due per ogni core fisico.
Infatti è così. L'articolo risulta errato in questo punto.
In questa recensione viene messo ancora più sotto anche dallo stesso Threadripper 1950x

https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/10

Secondo me è evidente che c'è qualcosa che non và: o nei metodi di test o nel modo in cui sono stati compilati o scritti, ma può essere anche il processore stesso. Aldilà delle supposizioni e speculazioni fatte, qualuno sà effettivamente dove stà il problema (o i problemi)?
Intanto vedi sopra per HandBrake. Ma se ti riferisci a tutti i test, è difficile poter fare delle valutazioni usando core con versioni diverse di Zen, come dicevo prima.

Riuscire a isolare eventuali problemi è difficile quando ci sono più variabili in gioco.
Com'è possibile che ci sia così tanta differenza fra il rendering, dove svetta incima a tutti gli altri processori, e l'encoding, dov'è addirittura peggio della precedente generazione a meno cores leggendo quella recensione (vedi 1950x).
Perché il rendering è un algoritmo che scala praticamente linearmente, in quanto lo puoi tranquillamente suddividere in tante parti quanto sono i pixel da renderizzare, e procedere in parallelo.

L'encoding, invece, è molto diverso, e lo puoi vedere dall'immagine che ho postato prima, che mostra la pipeline del codec HVEC con tutte le operazioni che sono necessarie. Si tratta di operazioni che non puoi suddividere tutte in maniera uniforme sul numero di core/thread hardware a disposizione, e che a valle del processo presenta la codifica CABAC che di per sé non è parallelizzabile (vedi il mio precedente commento in merito) e rappresenta una sorta di "imbuto" che "strozza" l'esecuzione (tutto passa da lì).

CABAC si può comunque suddividere in base al numero di parti in cui è stata divisa l'immagine, ma nella codifica del bitstream finale il risultato sarà meno ottimizzato; quindi se vuoi cercare di sfruttare di più i core/thread hardware a disposizione, c'è un prezzo da pagare. In ogni caso CABAC è estremamente sensibile alla bontà della micro-architettura (è un processo seriale che stressa particolarmente il branch predictor. Inoltre l'algoritmo di predizione di cui fa uso fa anche parecchi accessi alla memoria, sebbene sia abbastanza locali).

In sintesi: c'è un abisso fra il rendering e l'encoding. Sono due algoritmi totalmente diversi, e con una scalabilità completamente diversa.
7zip x264 x265 winrar ... qualcosa che non và c'è; sarà anche il discorso dell'IPC ma non può essere solo quello... il 2990wx ha il doppio dei tread del 7980xe e và la metà secondo l'ultimo test della recensione che ho linkato.
L'IPC c'entra (vedi sopra), ma a mio avviso ci potrebbero anche essere problemi dovuti all'accesso ai due soli controller della memoria da parte di CCX che sono più lontani.

x264 e x265 (HVEC) sono simili, per cui vedi le mie risposte in merito.

Riguardo 7-zip e WinRAR, la compressione può essere abbastanza parallelizzata (ma c'è sempre una parte seriale) e sono chi più, chi meno, sensibili alla banda di memoria. Il tallone d'Achille d'entrambi è rappresentato dalla decompressione, che per ovvie ragioni è scarsamente parallelizzabile.
Io se dovessi scegliere questo 2990wx lo farei per fare rendering ma anche per fare un successivo encoding. Non credo che AMD sia così ingenua da darsi la zappa sui piedi. Sarà anche il processore ad essere "inadeguato al tipo di carico" ma secondo me è anche il tipo di carico che non vuol essere adeguato al tipo di processore.
E invece sì: un processore rende più o meno bene in base alla tipologia di algoritmi che gli viene fatta eseguire.
il problema non è leggere ma comprendere :asd:

guarda che il discorso era meramente tecnico.... non era incentrato su quello che quello che fa le conversioni, che le fa una alla volta perchè è masochista...

il punto del discorso è che il 32 core è una CPU fantastica ma che si porta dietro delle ovvie limitazioni rispetto agli EPYC che in alcuni scenari non lo fanno brillare... ma è una cosa d'altra parte ovvia, visto che non esiste la CPU idilliaca.... e per mostrare queste limitazioni ha preso come esempio la codifica...
*
Tutto quelche volete. Ma dio santo è possibile che in 3 recensioni diverse saltano fuori 3 risultati diversi solo per quanto riguarda l'encoding ?
Perché vengono usate sorgenti (video, immagini, audio, ecc.) diversi e/o parametri diversi, pur usando lo stesso programma, per cui è ovvio che i risultati saranno diversi e non confrontabili.

Ho capito. Allora tristezza :( Non riesco a pensare a chi possa far comodo un processore così, forse con le virtual machine; per una postazione workstation di rendering ed encoding resta cmq preferibile intel stando così le cose ad oggi.

Il modello di punta e difficile da consigliare, visto il prezzo e le prestazioni si adatta solo a pochi ambiti particolari, mentre il modello 2950 va molto meglio del vecchio 1950, e costa meno, non capisco perché dovrebbe essere consigliabile Intel, che non ha presentato nulla di nuovo e vende il 7980 a prezzo assurdo, anche se non e il top... Però come al solito vince sempre la squadra blu

Il vero best buy è il 2950. Viaggia di più, costa e consuma meno del precedente. Che altro volere?

Allora non hai letto le review perché li hai pagine di argomentazioni e non posso scrivere un posti di pagine. Riassumendo solo 2 dei dei 4 accede alla memoria e quindi capirai dove sta il problema in elaborazioni legate a grandi molo di dati. È ribadisco che i benchmark parlano da soli perché mettono nero su bianco dove sono i pregi e i difetti. Ovviamente se uno decide che i difetti non esistono ma sono causa dei programmatori allora meglio non discutere avanti
questo non è di per sè un grosso problema....
con la gestione della memoria come quella di threadripper a 16 core, i core anche se avessero tutti la possibilità di accedere ad un proprio MC, avrebbero comunque accesso a RAM di altri die per il 75% del tempo....la penalità in termini di tempi di accesso non sono comunque così alti rispetto ad una risoluzione simmetrica...se esistono problemi questi sono riproposti in misura quasi del tutto analoga dalle CPU epyc.

i bench, dicono solo che ci sono problemi di compatibilità, che possono essere dovuti a tanti fattori:
difficoltà nella gestione di 64 threads: per verificarlo basterebbe disattivare il SMT.
limitata potenza nel ST: il turbo nel 2990x potrebbe non funzionare correttamente...quindi potremmo per quel che si sa, confrontare una CPU a 16 core, che ha core a 4GHz, ed un altra vincolata alla frequenza base...
gestione problematica della memoria/core da parte del SO/software.

EDIT...
test interessanti, da fare ad una frequenza fissa per confrontare il 2950x al 2990x sono:
1. scaling thread (16/32 vs 32c/32t vs 32c/64t, mantenendo la asimmetria con soluzione con 2 die attivi)
3. asimmetria memoria, 16 core attivi, un die collegato al MC e un altro che ne orfano attivi e confrontarli con una soluzione simmetrica con il doppio della bandwidth con il 2950x.

comunque i risultati usando altri software per la conversione video sono più incoraggianti, con un +10-15% per le CPU da 32 core sul 2950x

Riguardo 7-zip e WinRAR, la compressione può essere abbastanza parallelizzata (ma c'è sempre una parte seriale) e sono chi più, chi meno, sensibili alla banda di memoria. Il tallone d'Achille d'entrambi è rappresentato dalla decompressione, che per ovvie ragioni è scarsamente parallelizzabile.
Nell'articolo di anandtech riportato sopra (questo (https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/10)) i 32 core AMD sembra si comportino piuttosto bene proprio in compressione 7z, mentre arrancano in decompressione (in particolare il 2990WX).
Intendevi il contrario di quel che hai scritto o c'è qualcosa che non ti torna nei test di anandtech?

Il modello di punta e difficile da consigliare, visto il prezzo e le prestazioni si adatta solo a pochi ambiti particolari, mentre il modello 2950 va molto meglio del vecchio 1950, e costa meno, non capisco perché dovrebbe essere consigliabile Intel, che non ha presentato nulla di nuovo e vende il 7980 a prezzo assurdo, anche se non e il top... Però come al solito vince sempre la squadra blu

dove lo vedi che il 2950 va tanto meglio del 1950 ?

dove lo vedi che il 2950 va tanto meglio del 1950 ?

Non ho mica messo i numeri, ho preso paro paro le conclusioni della review di anandtech. Anche fossero pochi punti percentuali, va di più e costa meno. Non si può pretendere di meglio

Il modello di punta e difficile da consigliare, visto il prezzo e le prestazioni si adatta solo a pochi ambiti particolari, mentre il modello 2950 va molto meglio del vecchio 1950, e costa meno, non capisco perché dovrebbe essere consigliabile Intel, che non ha presentato nulla di nuovo e vende il 7980 a prezzo assurdo, anche se non e il top... Però come al solito vince sempre la squadra blu
http://mammaperfetta.it/wp-content/uploads/2015/05/bambino-che-piange-298x300.png
Nell'articolo di anandtech riportato sopra (questo (https://www.anandtech.com/show/13124/the-amd-threadripper-2990wx-and-2950x-review/10)) i 32 core AMD sembra si comportino piuttosto bene proprio in compressione 7z, mentre arrancano in decompressione (in particolare il 2990WX).
Intendevi il contrario di quel che hai scritto o c'è qualcosa che non ti torna nei test di anandtech?
No, intendevo proprio che in compressione dovrebbero essere avvantaggiati sistemi con più core, e viceversa in decompressione.

Ma nei test di AnandTech con 7-Zip si verifica l'esatto contrario. Stranissimo... :mbe:

http://mammaperfetta.it/wp-content/uploads/2015/05/bambino-che-piange-298x300.png

No, intendevo proprio che in compressione dovrebbero essere avvantaggiati sistemi con più core, e viceversa in decompressione.

Ma nei test di AnandTech con 7-Zip si verifica l'esatto contrario. Stranissimo... :mbe:
è sicuramente un bug di 7zip su windows...su linux i risultati sono questi
https://techgage.com/wp-content/uploads/2018/08/AMD-Ryzen-Threadripper-2950X-2990WX-Performance-in-Compression-Linux.png

e su windows anche il test di compressione di AIDA è favorevole al 2990wx
https://techreport.com/r.x/2018_08_13_AMD_s_Ryzen_Threadripper_2990WX_CPU_reviewed/Graphs_aida64zlib.png


sulle scarse prestazioni nella codifica video, appena 10-15% in più con handbrake sempre su linux per il 2990x,
https://techgage.com/wp-content/uploads/2018/08/AMD-Ryzen-Threadripper-2950X-2990WX-Performance-in-HandBrake-Linux-680x451.png
c'è da dire che il software non scala oltre i 32 thread....praticamente il 2950x riesce quasi del tutto ad annullare il gap con il modello maggiore grazie all'utilizzo del SMT e alla maggiore frequenza operativa (avendo il 2990wx tutti i core occupati avrà certamente una frequenza ben più bassa).
https://techgage.com/wp-content/uploads/2018/08/Ubuntu-HandBrake-Test-with-AMDs-Threadripper-2990WX.png
di fatto stiamo confrontando una soluzione a 16c/32t@3,5GHz vs 32c/32t@3GHz (anzi il SMT attivo potrebbe portare anche ad un leggero calo delle prestazioni)

Ne consegue che come detto che i software vanno migliorati punto e basta.. in generale.. tutti

Ne consegue che come detto che i software vanno migliorati punto e basta.. in generale.. tutti
questo si sapeva da parecchio, il miglioramento dello scheduler di windows potrebbe essere un primo passo, su linux alemno su quello sono più avanti, ma il kernel viene aggiornato più spesso, e di base è più adattabile... quanto al resto.. una cpu da 1700 e passa euro con una difficiel collocazione di utilizzo non farà certo muovere le acque nello sviluppo software.. handbrake è free, se li paghi ottimizzano tutto senza problemi.

questo si sapeva da parecchio, il miglioramento dello scheduler di windows potrebbe essere un primo passo, su linux alemno su quello sono più avanti, ma il kernel viene aggiornato più spesso, e di base è più adattabile... quanto al resto.. una cpu da 1700 e passa euro con una difficiel collocazione di utilizzo non farà certo muovere le acque nello sviluppo software.. handbrake è free, se li paghi ottimizzano tutto senza problemi.

è una CPU dalla semplicissima collocazione di utilizzo e i software per i quali è indicata funzionano gia benissimo.

Qui la risposta Amd al problema sw con 2990wx https://m.hardocp.com/article/2018/08/13/amd_ryzen_threadripper_2990wx_2950x_cpu_review/3
Ci sono aggiornamenti da fare perché 16,32 ed ora 64 threads sono un inedito in ambito consumer. La vera CPU vincente è il 2950x, per gestire il quad die occorre un potenziamento dell'if..

https://techgage.com/article/amd-ryzen-threadripper-2990wx-32-core-workstation-processor-review/6/. Ci sono altri test ed in particolare spiega i problemi di handbrake 1.1.1 in Windows vs 1.1.0. anche su Adobe premiere ci sono task ottimizzati ed altri no.

è sicuramente un bug di 7zip su windows...su linux i risultati sono questi
https://techgage.com/wp-content/uploads/2018/08/AMD-Ryzen-Threadripper-2950X-2990WX-Performance-in-Compression-Linux.png

e su windows anche il test di compressione di AIDA è favorevole al 2990wx
https://techreport.com/r.x/2018_08_13_AMD_s_Ryzen_Threadripper_2990WX_CPU_reviewed/Graphs_aida64zlib.png
OK. Questo conferma quanto avevo detto in merito. Meno male, perché era veramente illogico che i risultati della compressione fossero quelli.
sulle scarse prestazioni nella codifica video, appena 10-15% in più con handbrake sempre su linux per il 2990x,
https://techgage.com/wp-content/uploads/2018/08/AMD-Ryzen-Threadripper-2950X-2990WX-Performance-in-HandBrake-Linux-680x451.png
Visto. E ho letto anche l'altro link che ha riportato Mparlav, che contribuiscono a chiarire meglio la situazione.
c'è da dire che il software non scala oltre i 32 thread....praticamente il 2950x riesce quasi del tutto ad annullare il gap con il modello maggiore grazie all'utilizzo del SMT e alla maggiore frequenza operativa (avendo il 2990wx tutti i core occupati avrà certamente una frequenza ben più bassa).
https://techgage.com/wp-content/uploads/2018/08/Ubuntu-HandBrake-Test-with-AMDs-Threadripper-2990WX.png
di fatto stiamo confrontando una soluzione a 16c/32t@3,5GHz vs 32c/32t@3GHz (anzi il SMT attivo potrebbe portare anche ad un leggero calo delle prestazioni)
E' veramente molto strano, altrimenti non si spiegherebbe il 10-15% che s'è visto proprio col 2990WX. Magari c'è un problema in quel sistema.
Ne consegue che come detto che i software vanno migliorati punto e basta.. in generale.. tutti
In tal caso proponiti tu per migliorarli e facci vedere come fare.
è una CPU dalla semplicissima collocazione di utilizzo e i software per i quali è indicata funzionano gia benissimo.
*

In tal caso proponiti tu per migliorarli e facci vedere come fare.

Su Adobe Acrobat nonostante siano stati fatti 100mila aggiornamenti quando apri un pdf di un libro scansionato le pagine sono caricate una alla volta e in single thread, le immagini non sono cachate in ram nonostante tu abbia anche svariati GB disponibili e quando scrolli in velocità cosa comunissima dato che i pdf sono uno standard de facto e Acrobat Reader è il lettore ufficiale praticamente va a scatti e non è fluido come potrebbe essere. -> caricando le pagine in parallelo e precachandole si potrebbe avere un miglioramento in performance ottimo

Su Adobe Audition un banale filtro, salvataggio di file, export in mp3 o qualsiasi altro formato viene runnato in single o al massimo in dual thread quando si potrebbe spezzettare e parallelizzare per tanti i threads che hai

Su vari software video la quasi totalità dei filtri è in single thread o leggermente accelerato via video incluse roba tipo lo scale, il che fa da collo di bottiglia su tutto

Su Photoshop trovali i filtri o passaggi che sono realmente in multithread..

La cosa divertente che ho notato è che i software generalmente più grossi e più pagati tendono a migliorare tecnologicamente più lentamente di un software scemo open source su linux per dire..

Perchè nel mondo linux e open si tende più facilmente a ragionare in multi-thread.. i software iconici del passato sono gestiti da capocce che spesso cercano di aggiungere roba, fare scena ma quando si tratta di riscrivere in multithread qualcosa probabilmente per loro è tempo tolto ad altro

I'm so sorry ma non ho i codici sorgenti di tutta sta roba..

Però anche non essendo una cima un preload delle jpg in parallelo e intendo 1 thread -> 1 pagina + la messa in memoria delle pagine per scrollarle velocemente non dovrebbe essere una cosa impossibile da fare..

Su Adobe Acrobat nonostante siano stati fatti 100mila aggiornamenti quando apri un pdf di un libro scansionato le pagine sono caricate una alla volta e in single thread, le immagini non sono cachate in ram nonostante tu abbia anche svariati GB disponibili e quando scrolli in velocità cosa comunissima dato che i pdf sono uno standard de facto e Acrobat Reader è il lettore ufficiale praticamente va a scatti e non è fluido come potrebbe essere. -> caricando le pagine in parallelo e precachandole si potrebbe avere un miglioramento in performance ottimo
Non so se questo sia possibile. Il parsing di un documento è generalmente un processo strettamente sequenziale, per cui non c'è nulla di parallelizzabile.

Non so nello specifico come sia strutturato un PDF, ma se NON ha una struttura simile ai file IFF di Amiga (che hanno una struttura composta da tag + dimensione del tag + eventuali dati del tag) o qualcosa di simile che consenta velocemente di raggiungere le varie parti del documento (supponendo che le pagine abbiano appositi tag/marker, ovviamente), allora ciò che chiedi non è possibile.

Ovviamente una volta effettuato il parsing si può eseguire il cache di qualsivoglia cosa.

Specificamente, non uso Acrobat Reader, ma Foxit Reader per i PDF.
Su Adobe Audition un banale filtro, salvataggio di file, export in mp3 o qualsiasi altro formato viene runnato in single o al massimo in dual thread quando si potrebbe spezzettare e parallelizzare per tanti i threads che hai
Il filtri generalmente sono parallelizzabili. Per il salvataggio in certi formati dipende dallo specifico formato.
Su vari software video la quasi totalità dei filtri è in single thread o leggermente accelerato via video incluse roba tipo lo scale, il che fa da collo di bottiglia su tutto

Su Photoshop trovali i filtri o passaggi che sono realmente in multithread..
I filtri che fanno uso di convoluzioni et similia generalmente sono parallelizzabili, ma ci possono essere filtri di altro tipo che non lo sono.

Comunque Photoshop mi pare che consenta di importare/utilizzare filtri esterni. Potrebbero essere scritti da altri sviluppatori in modo da sfruttare più thread.
La cosa divertente che ho notato è che i software generalmente più grossi e più pagati tendono a migliorare tecnologicamente più lentamente di un software scemo open source su linux per dire..

Perchè nel mondo linux e open si tende più facilmente a ragionare in multi-thread.. i software iconici del passato sono gestiti da capocce che spesso cercano di aggiungere roba, fare scena ma quando si tratta di riscrivere in multithread qualcosa probabilmente per loro è tempo tolto ad altro
Il mondo open source in generale soffre di altri problemi: dovrebbero imparare a mettere l'utente (comune) al centro e sviluppare software di conseguenza.

Finché continueranno a procedere come gli pare ignorando le aspettative/esigenze dei loro "clienti" (ogni riferimento a GIMP non è casuale), resteranno sempre dietro ai software proprietari.
I'm so sorry ma non ho i codici sorgenti di tutta sta roba..
Molti delle applicazioni usate nei test/benchmark sono open source.

Ovviamente non mi aspetto che tu possa metter mani su tutto e parallelizzare, ove possibile, il codice. Però se la situazione è quella che è anche col software open source, qualche riflessione potresti farla.
Però anche non essendo una cima un preload delle jpg in parallelo e intendo 1 thread -> 1 pagina + la messa in memoria delle pagine per scrollarle velocemente non dovrebbe essere una cosa impossibile da fare..
Sì, se il formato del file d'origine lo consente, come dicevo sopra.

questo giro a intel tocchera segare i prezzi di brutto :D

Belle bestioline, niente da dire, nel segmento HTPC hanno spazzato via Intel in un solo colpo, mi farebbe gola un 2950x a lavoro (anche se acquistiamo solo WS certificate e ci fanno scegliere parte dell'hw non credo che permetterebbero l'utilizzo di hw "consumer" non certificato), già adesso con assiemi 3d complessi (unità motore e cambio) nelle varie simulazioni ad elementi finiti devo farlo fare nella nostra farm e non in locale.
Il 2990WX mi sembra esagerato, quel numero di thread non credo che sia neanche supportato dal tipo di licenza che ho sulla "mia" WS.

No, intendevo proprio che in compressione dovrebbero essere avvantaggiati sistemi con più core, e viceversa in decompressione.

Ma nei test di AnandTech con 7-Zip si verifica l'esatto contrario. Stranissimo... :mbe:

Questo cambierà a breve, i produttori ( inclusa amd ed anzi lei per prima) inizieranno a tagliare le frequenze max alle cpu con meno core in modo da incentivare le cpu top di gamma.
Con i turbo così fini ( e che si evolveranno ancora meglio con i 7 nm) sarà gioco facile spingere il turbo su cpu 8/16 core a 5- 5.2 ghz su due core mentre limiterebbe il turbo su cpu da 6 core a scendere ai "soli" 4.6/4.8 ghz.
Questo incentiverebbe ancora più all'acquisto di cpu di fascia alta anche a chi usa programmi da 1 o 2 th massimo.

Ps bentornato Cesare e auguri per la promozione.

Questo cambierà a breve, i produttori ( inclusa amd ed anzi lei per prima) inizieranno a tagliare le frequenze max alle cpu con meno core in modo da incentivare le cpu top di gamma.
Con i turbo così fini ( e che si evolveranno ancora meglio con i 7 nm) sarà gioco facile spingere il turbo su cpu 8/16 core a 5- 5.2 ghz su due core mentre limiterebbe il turbo su cpu da 6 core a scendere ai "soli" 4.6/4.8 ghz.
Questo incentiverebbe ancora più all'acquisto di cpu di fascia alta anche a chi usa programmi da 1 o 2 th massimo.
Infatti è proprio questa la fregatura. A me interessano frequenze elevate (e IPC elevato), ma pochi core, e per le mie esigenze sono costretto a comprare CPU top di gamma anziché qualche Pentium o, al massimo, i3.
Ps bentornato Cesare e auguri per la promozione.
Grazie. :)

Purtroppo le vacanze sono finite :cry: , per cui avrò pochissimo tempo da dedicare al forum. :(