Link all'Articolo: https://www.hwupgrade.it/articoli/cpu/5288/amd-ryzen-threadripper-2970wx-e-2920x-le-cpu-enthusiast-a-24-e-12-core_index.html

AMD completa la gamma di processori Ryzen Threadripper con le due proposte 2970WX a 24 core e 2920X a 12 core, rivolte una al pubblico dei creatori e l'altra agli utenti appassionati. Tanti core, con un prezzo molto interessante e la necessità di abbinarvi applicazioni che sfruttino al meglio tutta questa potenza di elaborazione

Click sul link per visualizzare l'articolo.

Mah.. gran belle bestie per carità.. ma in generale non è che l'entusiasmo sia alle stelle.

Siamo in piena guerra a chi ha più cores.. tuttavia la realtà dei fatti è che sfruttare la potenza a disposizione è sempre più difficile e solo in rare e determinate situazioni si riesce a tirare fuori la potenza di queste cpu.

Persino software che notoriamente traggono grande vantaggio dalla presenza di tanti cores fanno fatica a sfruttare tutti i cores presenti.

Praticmante sono CPU da server.. :mbe:

Praticmante sono CPU da server.. :mbe:

esatto, e riproporre in test del genere giochi FHD è nonsense

per uso casalingo non si sa nemmeno se siano mai sfruttati gli 8/16 figurarsi cpu del genere, ma il futuro è questo: quello che manca adesso è ottimizzazione sul MT per ogni applicazione dove paradossalmente in alcune vanno meglio cpu con meno core ma più mhz

Anche perchè non sono molti gli ambiti consumer dove c'è realmente vantaggio ad avere CPU più potenti di un Ryzen qualsiasi

Beh, non sono ovviamente CPU da videogiocatori (nonostante il packaging che, gusto personale, mi piace parecchio).

queste CPU non sono chiaramente dedicate all'utente casalingo medio, ma all'appassionato o al lavoratore che ha bisogno di tutta questa potenza… Rendering, simulazioni, multitasking pesante (es. Unity, Photoshop e Premiere aperti contemporaneamente)…

Secondo me hanno un notevole mercato, solamente che non e' quello casalingo/videoludico.

Beh, non sono ovviamente CPU da videogiocatori (nonostante il packaging che, gusto personale, mi piace parecchio).

queste CPU non sono chiaramente dedicate all'utente casalingo medio, ma all'appassionato o al lavoratore che ha bisogno di tutta questa potenza… Rendering, simulazioni, multitasking pesante (es. Unity, Photoshop e Premiere aperti contemporaneamente)…

Secondo me hanno un notevole mercato, solamente che non e' quello casalingo/videoludico.

Di fatto no.. nemmeno il "LAVORATORE" riesce a ricreare uno scenario da cui trae vantaggio da tutti sti cores. (l'appassionato manco lo conteggio)
Di programmi pesanti puoi aprirne pure dieci ma o usi uno o usi l'altro.. i cores sono comunque lì a far nulla.
Persino i software più votati al multicore arrancano. :mbe:

In sontanza un botto di potenza teorica ma che di fatto non usi mai.

Di fatto no.. nemmeno il "LAVORATORE" riesce a ricreare uno scenario da cui trae vantaggio da tutti sti cores. (l'appassionato manco lo conteggio)
Di programmi pesanti puoi aprirne pure dieci ma o usi uno o usi l'altro.. i cores sono comunque lì a far nulla.
Persino i software più votati al multicore arrancano. :mbe:

In sontanza un botto di potenza teorica ma che di fatto non usi mai.Potresti creare una workstation su cui far girare 4 macchine virtuali, una per lavoratore. Nel caso di grossi progetti usi la principale sfruttando tutti i core, mettendo in pausa le VM. Qualcuno mi dica se ha un senso.
Altrimenti non saprei. È un multipackage quindi in tutte le applicazioni che sfruttano massimo 8 core risulta meno performante di un "semplice" 2700X.

Di fatto no.. nemmeno il "LAVORATORE" riesce a ricreare uno scenario da cui trae vantaggio da tutti sti cores. (l'appassionato manco lo conteggio)
Di programmi pesanti puoi aprirne pure dieci ma o usi uno o usi l'altro.. i cores sono comunque lì a far nulla.
Persino i software più votati al multicore arrancano. :mbe:

In sontanza un botto di potenza teorica ma che di fatto non usi mai.

Se usi un programma come COMSOL o Ansys ti garantisco che li utilizzi tutti.. Se non li utilizzi la possibilita' di fare calcoli pesanti con tanti core mentre ne lasci un paio liberi per fare altro, come web, scrivere documenti o continuare a progettare, e' una cosa che fa solo bene...

Potresti creare una workstation su cui far girare 4 macchine virtuali, una per lavoratore. Nel caso di grossi progetti usi la principale sfruttando tutti i core, mettendo in pausa le VM. Qualcuno mi dica se ha un senso.
Altrimenti non saprei. È un multipackage quindi in tutte le applicazioni che sfruttano massimo 8 core risulta meno performante di un "semplice" 2700X.

Se usi un programma come COMSOL o Ansys ti garantisco che li utilizzi tutti.. Se non li utilizzi la possibilita' di fare calcoli pesanti con tanti core mentre ne lasci un paio liberi per fare altro, come web, scrivere documenti o continuare a progettare, e' una cosa che fa solo bene...

Si parlavo in generale gente.
Poi è chiaro che se ci mettiamo di impegno lo troviamo pure un modo per sparare a cannone tutti i cores in contemporanea.

Resta il fatto che sono situazioni talmente rare e/o specifiche che alla fine sono quasi esercizi di stile.

Cioè.. in un mondo reale ed un uso reale quattro cores li occupi spesso.. sei anche.. otto comincia già ad essere difficile ma volendo lo fai.. TRENTADUE li usa solo un server che deve distribuire il carico di cinquecento utenti collegati..

Ha ragione demon77. Sfruttare queste CPU nella maggior parte dei casi è praticamente impossibile. Già per quanto riguarda quella da 12 core.

Si ragazzi in ambito home sono overkill ma in ambito prosumer/pro 32 core sono molto comodi, per tutto il resto basta un 2700X o un 9700/9900k.

Non sono cpu per tutti ovviamente ma hanno un target ben specifico :)

paradossalmente in alcune vanno meglio cpu con meno core ma più mhz

Beh, nella mia ignoranza...mi sembra più che ovvio...e per nulla paradossale.
Già anni or sono, le applicazioni che sfruttano codici a 64 bit erano pochissime, quindi acquistare cpu a 64 bit era paradossale...idem dicasi con i multicore..a meno che il ragionamento non si basi su un discorso di uso a lungo termine ed aggiornamento di un hw datato.

Attualmente in una cpu si dovrebbe guardare cache, bus e frequenza di lavoro, anzi personalmente ci metterei anche l'Hypertrading che su alcune cpu coffee lake ad esempio era scomparsa....comincio a rileggerne l'uso con il modello i9 della serie 9....per me fondamentale per sfruttare i core in un uso più immediato. Mio parere si intende...

Si ragazzi in ambito home sono overkill ma in ambito prosumer/pro 32 core sono molto comodi, per tutto il resto basta un 2700X o un 9700/9900k.

Non sono cpu per tutti ovviamente ma hanno un target ben specifico :)

Mah, anche in ambito pro 32 core non so in quanti casi li si sfrutta come si deve.
I software che sfruttano abbondantemente calcoli matriciali, per dire, traggono maggior vantaggio dall'utilizzo della GPU con CUDA, piuttosto che da una CPU a 64 core.

Di fatto no.. nemmeno il "LAVORATORE" riesce a ricreare uno scenario da cui trae vantaggio da tutti sti cores. (l'appassionato manco lo conteggio)
Di programmi pesanti puoi aprirne pure dieci ma o usi uno o usi l'altro.. i cores sono comunque lì a far nulla.
Persino i software più votati al multicore arrancano. :mbe:

In sontanza un botto di potenza teorica ma che di fatto non usi mai.

Sei abituato a ragionare da utente domestico, come siamo tutti.
Pensa a un'azienda che si occupa della computer grafica (per film, serie, commercial,) e a un certo punto renderizza ore di roba... credi che facciano chon i7 7700K e Quadro P2000 come può avere un utente che ci lavora ma che ha capacità di investimento molto più basse?
O ricerca scientifica, altro ambito in cui immagino che la potenza non sia mai troppa... o credi che al CERN abbiano degli i5 8600 "perchè non abbiamo le applicazioni per sfruttare i core"?
O in ambito server? Lo so che lo hai scritto nel tuo primo post quindi chiedo, cosa ti stai domandando? Gli scenari di utilizzo esistono, poi poco importa se li abbiamo visti recensiti con 4 giochini... quello non c'entra nulla con quello che possono fare queste cpu.

Sei abituato a ragionare da utente domestico, come siamo tutti.
Pensa a un'azienda che si occupa della computer grafica (per film, serie, commercial,) e a un certo punto renderizza ore di roba... credi che facciano chon i7 7700K e Quadro P2000 come può avere un utente che ci lavora ma che ha capacità di investimento molto più basse?
O ricerca scientifica, altro ambito in cui immagino che la potenza non sia mai troppa... o credi che al CERN abbiano degli i5 8600 "perchè non abbiamo le applicazioni per sfruttare i core"?
O in ambito server? Lo so che lo hai scritto nel tuo primo post quindi chiedo, cosa ti stai domandando? Gli scenari di utilizzo esistono, poi poco importa se li abbiamo visti recensiti con 4 giochini... quello non c'entra nulla con quello che possono fare queste cpu.

Infatti (server a parte) render node e applicativi scientifici (specifici) sono gli unici ambiti dove puoi immaginare un impiego sensato di queste CPU.
Ma parliamo di cosa? Uno per cento dell'utenza?
Il restante 99% quando ne ha a disposizione otto è già altro che sereno.

Più aumenta il numero di cores più diventa difficile riuscire ad usarli. Adesso siamo già a livello "difficilissimo".

Quindi mi sto domandando: vendi una CPU con trentadue cores " per mercato enthusuast". Ma chi cacchio te la compra? :stordita: :stordita:

Sei abituato a ragionare da utente domestico, come siamo tutti.
Pensa a un'azienda che si occupa della computer grafica (per film, serie, commercial,) e a un certo punto renderizza ore di roba... credi che facciano chon i7 7700K e Quadro P2000 come può avere un utente che ci lavora ma che ha capacità di investimento molto più basse?
O ricerca scientifica, altro ambito in cui immagino che la potenza non sia mai troppa... o credi che al CERN abbiano degli i5 8600 "perchè non abbiamo le applicazioni per sfruttare i core"?
O in ambito server? Lo so che lo hai scritto nel tuo primo post quindi chiedo, cosa ti stai domandando? Gli scenari di utilizzo esistono, poi poco importa se li abbiamo visti recensiti con 4 giochini... quello non c'entra nulla con quello che possono fare queste cpu.

Pensi che sia più conveniente fare calcoli matriciali con queste CPU o con le GPU?

Più aumenta il numero di cores più diventa difficile riuscire ad usarli. Adesso siamo già a livello "difficilissimo".

Questo è sempre stato lapalissiano a chiunque abbia almeno per sbaglio letto qualcosa sulla programmazione parallela.
Tanto per cominciare, bisogna vedere se un determinato algoritmo sia, di per sè, parallelizzabile. Poi bisogna vedere se il gioco valga la candela (a livello di prestazioni proprio, oltre che di "costo" dovuto alla riscrittura del codice).

Pensi che sia più conveniente fare calcoli matriciali con queste CPU o con le GPU?

Dipende da come e' progettato il programma… Direi che per un computer desktop il calcolo GPU e' piu' indicato, anche perche' parallelizza molto di piu' di una CPU, fosse solo per i blocchi paralleli.

Programmare per GPU tuttavia e' molto diverso dalla programmazione per CPU, e se uno vuole parallelizzare un programma esistente e' possibile che utilizzi prima la CPU.

Poi si tratta di parallelizzazioni diverse, con le GPU parallelizzi in pratica calcoli matriciali e poco altro. I thread CPU sono molto piu' variegati. Ad esempio puoi fare un thread per riceve dati da una connessione di rete, un thread per elaborarli ed un thread per spedire i risultati, con un'altro thread the visualizza i dati su un'interfaccia grafica, cosa che con in thread GPU non puoi fare. Dipende quindi dall'architettura del programma e da come vuoi gestire i thread.

Infatti (server a parte) render node e applicativi scientifici (specifici) sono gli unici ambiti dove puoi immaginare un impiego sensato di queste CPU.
Ma parliamo di cosa? Uno per cento dell'utenza?
Il restante 99% quando ne ha a disposizione otto è già altro che sereno.

Più aumenta il numero di cores più diventa difficile riuscire ad usarli. Adesso siamo già a livello "difficilissimo".

Quindi mi sto domandando: vendi una CPU con trentadue cores " per mercato enthusuast". Ma chi cacchio te la compra? :stordita: :stordita:

Non capisco perche' il livello e' difficilissimo.. In generale gli algoritmi che possono essere parallelizzati sono implementati con un meccanismo per i quali definisci il numero di thread come parametro di ingresso, quindi modificare il numero di thread e' semplicissimo… Se uno sa programmare fare un programma con due o venti thread e' uguale; e' la progettazione del software che ti fa decidere di quanti thread hai bisogno. I thread per parallelizzare i calcoli possono essere teoricamente quanti vuoi, poi devono essere in numero tale da massimizzare l'efficienza della CPU/GPU. I thread logici dipendono dall'applicazione ed in genere ne bastano pochi..
Quindi non e' che e' difficile utilizzare molti thread: si fa semplicemente se serve.

Il mercato ora è variegato: CPU consumer 8 core, cpu HEDT fino a 32 e server fino a 64: ce n'è per tutti.

Per come la vedo io, personale parere, in ambito "pro" più core ci sono meglio è , ovviamente dipende dal programma che si usa.

Mi sto avvicinando al mondo BIM e, a parte la totale assenza di benchmark di quel tipo di software (Revit MEP, in collaborazione con studi che usano archicad, allplan etc), sembra che siano rimasti clamorosamente indietro come stile di programmazione. Da quel che capisco anche in questo settore non si riesce a trovare un software che sfrutti pesantemente codice parallelizzato, al punto che alla fine la differenza tra un computer casalingo ben messo e una macchina da qualche migliaio di euro è piccola e difficilmente giustifica l'esborso extra. Fossi sempre impegnato a far girare dei modelli risparmiare mezz'ora al giorno si paga in fretta, ma non sarà così. E comunque di questo si tratta purtroppo...

Non so, di software particolari ne uso anche, ma sinceramente trovarne uno che all'atto pratico ti fa risparmiare molto tempo è dura..soprattutto poi se lavori su progetti condivisi e deve passare dati in rete...hai voglia.

Credo che queste cpu siano una panacea nel momento in cui si va a fare rendering o video editing, ci sono alcuni user del forum che per lavorare hanno dovuto mettere su dei nodi, con una WS con il 2990WX si avrebbe un bel risparmio su tutti i fronti: spazio, consumi, tempo, infrastruttura, tutto. Per chi ci lavora e ci campa è un bel vantaggio immagino.

Personalmente la userei per virtualizzare dove i core, ma soprattutto la ram, non sono mai troppi.

Mi sto avvicinando al mondo BIM e, a parte la totale assenza di benchmark di quel tipo di software (Revit MEP, in collaborazione con studi che usano archicad, allplan etc), sembra che siano rimasti clamorosamente indietro come stile di programmazione. Da quel che capisco anche in questo settore non si riesce a trovare un software che sfrutti pesantemente codice parallelizzato, al punto che alla fine la differenza tra un computer casalingo ben messo e una macchina da qualche migliaio di euro è piccola e difficilmente giustifica l'esborso extra. Fossi sempre impegnato a far girare dei modelli risparmiare mezz'ora al giorno si paga in fretta, ma non sarà così. E comunque di questo si tratta purtroppo...

Non so, di software particolari ne uso anche, ma sinceramente trovarne uno che all'atto pratico ti fa risparmiare molto tempo è dura..soprattutto poi se lavori su progetti condivisi e deve passare dati in rete...hai voglia.Nel professionale inoltre molto spesso si privilegia l'uso di server dedicati.
Fra lo spendere quanti... 5000 euro? per un 32 core da poi anche mantenere e spendere 200 euro al mese per uno sempre pronto all'uso, manutenzione compresa... decisamente meglio la seconda. Ci sono anche dei superpc (altro che 32 core...) disponibili per l'affitto (giornaliero, settimanale, mensile).
Più che altro mi aspetto che chi offre questi servizi si aggiorni. Vedere Aruba con la sua offerta massima che si ferma a un Intel 8/16 core a 32nm... Nel 2019 spererei nel rinnovo con questo 2970WX e una riduzione a 150 euro mensili!

Dipende da come e' progettato il programma… Direi che per un computer desktop il calcolo GPU e' piu' indicato, anche perche' parallelizza molto di piu' di una CPU, fosse solo per i blocchi paralleli.

Programmare per GPU tuttavia e' molto diverso dalla programmazione per CPU, e se uno vuole parallelizzare un programma esistente e' possibile che utilizzi prima la CPU.

Poi si tratta di parallelizzazioni diverse, con le GPU parallelizzi in pratica calcoli matriciali e poco altro. I thread CPU sono molto piu' variegati. Ad esempio puoi fare un thread per riceve dati da una connessione di rete, un thread per elaborarli ed un thread per spedire i risultati, con un'altro thread the visualizza i dati su un'interfaccia grafica, cosa che con in thread GPU non puoi fare. Dipende quindi dall'architettura del programma e da come vuoi gestire i thread.



Non capisco perche' il livello e' difficilissimo.. In generale gli algoritmi che possono essere parallelizzati sono implementati con un meccanismo per i quali definisci il numero di thread come parametro di ingresso, quindi modificare il numero di thread e' semplicissimo… Se uno sa programmare fare un programma con due o venti thread e' uguale; e' la progettazione del software che ti fa decidere di quanti thread hai bisogno. I thread per parallelizzare i calcoli possono essere teoricamente quanti vuoi, poi devono essere in numero tale da massimizzare l'efficienza della CPU/GPU. I thread logici dipendono dall'applicazione ed in genere ne bastano pochi..
Quindi non e' che e' difficile utilizzare molti thread: si fa semplicemente se serve.

Avendo realizzato (e lavorandoci ancora) una libreria multi-threaded che analizza reti markoviane so che il numero di thread è semplicemente un parametro. Però è anche vero che non sempre puoi comunque sfruttare tutti i core a disposizione, perché il tutto dipende anche dalla architettura del tuo programma. Poi la verità è che ci sono tanti software, anche importanti, ma vecchi che le aziende dovrebbero riscrivere quasi da zero. E non lo faranno. :D

Non capisco perche' il livello e' difficilissimo.. In generale gli algoritmi che possono essere parallelizzati sono implementati con un meccanismo per i quali definisci il numero di thread come parametro di ingresso, quindi modificare il numero di thread e' semplicissimo… Se uno sa programmare fare un programma con due o venti thread e' uguale; e' la progettazione del software che ti fa decidere di quanti thread hai bisogno. I thread per parallelizzare i calcoli possono essere teoricamente quanti vuoi, poi devono essere in numero tale da massimizzare l'efficienza della CPU/GPU. I thread logici dipendono dall'applicazione ed in genere ne bastano pochi..
Quindi non e' che e' difficile utilizzare molti thread: si fa semplicemente se serve.

Non è assolutamente così semplice.
Un conto è spezzettare il lavoro su due o quattro cores (quando si può), ben altro farlo su trentadue.
Come detto sopra poi non è scontato che lo spezzettamento porti poi a dei vantaggi concreti in termini di velocità.

Avere dei cores più veloci porta vantaggio diretto e garantito a qualsiasi applicativo in qualunque situazione, viceversa avere a disposizione tanti cores su cui spartire il carico non è detto che sia sempre vantaggioso.. anzi di fatto lo è in rare situazioni.

Facendo un paragone forse non proprio perfetto ma che rende l'idea: puoi avere mille cavalli con due ferrari o con venti panda.
Ora, se devi trainare un pesante rimorchio lo puoi fare con gli stessi risultati sia con le due ferrari che con le venti panda.. ma se devi arrivare in fretta in un posto le due ferrari saranno sempre superiori alle venti panda. Anche trenta o cinquanta.

Mi chiedo come i threadripper WX si comportino con le macchine virtuali. Il caso d'uso che ho in mente e' un host con non meno di 3 macchine virtuali che girano. Il compito delle macchine virtuali e' compilare codice.

Qualcuno degli scenari descritti nei test si avvicina a questo tipo di utilizzo?

Nel professionale inoltre molto spesso si privilegia l'uso di server dedicati.
Fra lo spendere quanti... 5000 euro? per un 32 core da poi anche mantenere e spendere 200 euro al mese per uno sempre pronto all'uso, manutenzione compresa... decisamente meglio la seconda. Ci sono anche dei superpc (altro che 32 core...) disponibili per l'affitto (giornaliero, settimanale, mensile).
Più che altro mi aspetto che chi offre questi servizi si aggiorni. Vedere Aruba con la sua offerta massima che si ferma a un Intel 8/16 core a 32nm... Nel 2019 spererei nel rinnovo con questo 2970WX e una riduzione a 150 euro mensili!

Ma nemmeno tanto ...
Con 2000e arrivi easy ad una Workstation MB+2920+32GB+SSD da 512G +2HD da 4T in RAID10: per un sistema che ti dura minimo 3 anni. Aggiungici 300E di spese all'anno, esagerando, e si arriva a 3000

Con 3000 euro incluso IVA all'anno in Italia arrivi ad avere una configurazione simile ma con un 10 core E5-2640 v4 ... x 3 sono 9000 euro

La differenza è e resterà sempre tanta perché il costo dei server bene o male è quello e la gestione si paga

Di fatto no.. nemmeno il "LAVORATORE" riesce a ricreare uno scenario da cui trae vantaggio da tutti sti cores. (l'appassionato manco lo conteggio)
Di programmi pesanti puoi aprirne pure dieci ma o usi uno o usi l'altro.. i cores sono comunque lì a far nulla.
Persino i software più votati al multicore arrancano. :mbe:

In sontanza un botto di potenza teorica ma che di fatto non usi mai.

A me capita di usare contemporaneamente Photoshop, autopano giga e photomatix su un Ryzen 2700 con 32 di ram e sfrutto tutti e 8 i core al 100% e praticamente tutta la ram. Se avevo 24 core di sicuro li sfruttavo.

Se usi un programma come COMSOL o Ansys ti garantisco che li utilizzi tutti.. Se non li utilizzi la possibilita' di fare calcoli pesanti con tanti core mentre ne lasci un paio liberi per fare altro, come web, scrivere documenti o continuare a progettare, e' una cosa che fa solo bene...

bravo
esattamente
applicazioni di quel tipo giovano molto di tanti core.
stavo valutando TR per una installazione ANSYS fluent, ma ho dovuto ripiegare sui "soliti" xeon per via appunto del fatto che due CCX sono orfani della connessione diretta alla memoria, e i TR con applicazioni che spingono molto sulla banda si siedono.
peccato, ero molto carico nel provare questo HW

Mi sto avvicinando al mondo BIM e, a parte la totale assenza di benchmark di quel tipo di software (Revit MEP, in collaborazione con studi che usano archicad, allplan etc), sembra che siano rimasti clamorosamente indietro come stile di programmazione. Da quel che capisco anche in questo settore non si riesce a trovare un software che sfrutti pesantemente codice parallelizzato, al punto che alla fine la differenza tra un computer casalingo ben messo e una macchina da qualche migliaio di euro è piccola e difficilmente giustifica l'esborso extra. Fossi sempre impegnato a far girare dei modelli risparmiare mezz'ora al giorno si paga in fretta, ma non sarà così. E comunque di questo si tratta purtroppo...

Non so, di software particolari ne uso anche, ma sinceramente trovarne uno che all'atto pratico ti fa risparmiare molto tempo è dura..soprattutto poi se lavori su progetti condivisi e deve passare dati in rete...hai voglia.

gente, software da DECINE DI MIGLIAIA di € come Solidworks 2018 usano, quando va bene, 2 core...non sai che rabbia dotare le workstation di HW della madonna, x poi dover attendere i comodi del software per messe in tavole infinite.
Stessa musica circa x Inventor e co (non ho mai provato NX)

Il CAD infatti sfrutta pochissimi core, quello che sfrutta tutti i core è l'analisi FEA: provate MSC Nastran (o Apex) con 8 core, e poi con 16/24 core, per analisi modali su assiemi di grandi dimensioni, poi ditemi che è la stessa cosa.....

gente, software da DECINE DI MIGLIAIA di € come Solidworks 2018 usano, quando va bene, 2 core...non sai che rabbia dotare le workstation di HW della madonna, x poi dover attendere i comodi del software per messe in tavole infinite.
Stessa musica circa x Inventor e co (non ho mai provato NX)

Perdonami, ma s.o. come Solid Works e Solid Edge non sono utilizzati per applicazioni intensive, in campo automotive/aereospace ad esempio si utilizzano prettamente NX/Catia (di cui S.E e S.W. non sono altro che i fratelli "scemi" visto che le case di produzione sono rispettivamente le stesse: Siemens e Dassault), e di sicuro NX a seconda del tipo di licenza supporta il multicore su più di 8 thread.
Se poi parliamo di simulazioni ad elementi finiti lì credo che non ci siano limiti, noi in azienda per le simulazioni più pesanti (ad esempio impattori che penetrano unità motore e cambio ad alta velocità) utilizziamo la nostra farm interna che impiega una frazione di tempo rispetto alla mia WS a portare a termine tutti gli scenari.
Il problema è che nessuno dell'IT acquisterebbe macchine del genere per fartici lavorare su visto che non godono di certificazioni da quello che so.

Perdonami, ma s.o. come Solid Works e Solid Edge non sono utilizzati per applicazioni intensive, in campo automotive/aereospace ad esempio si utilizzano prettamente NX/Catia (di cui S.E e S.W. non sono altro che i fratelli "scemi" visto che le case di produzione sono rispettivamente le stesse: Siemens e Dassault), e di sicuro NX a seconda del tipo di licenza supporta il multicore su più di 8 thread.
Se poi parliamo di simulazioni ad elementi finiti lì credo che non ci siano limiti, noi in azienda per le simulazioni più pesanti (ad esempio impattori che penetrano unità motore e cambio ad alta velocità) utilizziamo la nostra farm interna che impiega una frazione di tempo rispetto alla mia WS a portare a termine tutti gli scenari.
Il problema è che nessuno dell'IT acquisterebbe macchine del genere per fartici lavorare su visto che non godono di certificazioni da quello che so.

Certo che si
Catia e NX sono i corrispettivi alta gamma (così come maya), ed utilizzano e soprattutto parallelizzano di + i processi.
resta il fatto che solidworks nello specifico non te lo regalano, e resta il fatto che è ancorato ad un motore di render dei primi 2000, monothread e con nessuna accelerazione cuda/opencl

Esatto

Certo che si
Catia e NX sono i corrispettivi alta gamma (così come maya), ed utilizzano e soprattutto parallelizzano di + i processi.
resta il fatto che solidworks nello specifico non te lo regalano, e resta il fatto che è ancorato ad un motore di render dei primi 2000, monothread e con nessuna accelerazione cuda/opencl

Hai provato ad utilizzare solid edge?
Mi sembra che ai tempi della ST1 (saranno passati 10 anni dall'ultima volta che l'ho usato) scalasse abbastanza bene su più thread, o almeno su un "vecchio" phenom x4 sfruttasse tutti e 4 i cores.

Certo che si
Catia e NX sono i corrispettivi alta gamma (così come maya), ed utilizzano e soprattutto parallelizzano di + i processi.
resta il fatto che solidworks nello specifico non te lo regalano, e resta il fatto che è ancorato ad un motore di render dei primi 2000, monothread e con nessuna accelerazione cuda/opencl

Confermo, SW a livello di sfruttamento hw fa schifo.
Quando vado in tavola a volte non è fluido, indipendentemente da se sia con l'i3 e l'integrata o l'i7 e una P2000. :muro:

Mi chiedo come i threadripper WX si comportino con le macchine virtuali. Il caso d'uso che ho in mente e' un host con non meno di 3 macchine virtuali che girano. Il compito delle macchine virtuali e' compilare codice.

Qualcuno degli scenari descritti nei test si avvicina a questo tipo di utilizzo?

L'uso di virtual machines è senza dubbio il migliore per sfruttare a dovere così tanti cores.
Se poi devi farne convivere addirrittura tre che devono macinare calcoli per lungo tempo direi che sei nella situazione migliore per sfruttare le potenzialità di una CPU come questa.

Hai provato ad utilizzare solid edge?
Mi sembra che ai tempi della ST1 (saranno passati 10 anni dall'ultima volta che l'ho usato) scalasse abbastanza bene su più thread, o almeno su un "vecchio" phenom x4 sfruttasse tutti e 4 i cores.

si usato, ma alla fine la zuppa mi sembrava quella
riproverò, certo migrare qualche centinaio di migliaia di modelli fa salire la febbre

Nel professionale inoltre molto spesso si privilegia l'uso di server dedicati.
Fra lo spendere quanti... 5000 euro? per un 32 core da poi anche mantenere e spendere 200 euro al mese per uno sempre pronto all'uso, manutenzione compresa... decisamente meglio la seconda. Ci sono anche dei superpc (altro che 32 core...) disponibili per l'affitto (giornaliero, settimanale, mensile).
Più che altro mi aspetto che chi offre questi servizi si aggiorni. Vedere Aruba con la sua offerta massima che si ferma a un Intel 8/16 core a 32nm... Nel 2019 spererei nel rinnovo con questo 2970WX e una riduzione a 150 euro mensili!

"nel professionale" non significa niente.
Parlo di avere una postazione di lavoro dove far girare software comunque abbastanza pesanti (per i modelli che faccio il minimo di RAM che non fa addormentare Revit è 16 GB). Non sono cose che abbia mai visto fare anche in altri studi con un terminale che si appoggia ad un server con virtualizzazione delle macchine.
Che vantaggi ci sarebbero? Nel mio caso in ufficio ho 4 postazioni tutte in grado di poter far girare questi software.
Per avere un beneficio prestazionale mantenendo i costi allo stesso livello che soluzione alternativa si potrebbe ipotizzare?

"nel professionale" non significa niente.
Parlo di avere una postazione di lavoro dove far girare software comunque abbastanza pesanti (per i modelli che faccio il minimo di RAM che non fa addormentare Revit è 16 GB). Non sono cose che abbia mai visto fare anche in altri studi con un terminale che si appoggia ad un server con virtualizzazione delle macchine.
Che vantaggi ci sarebbero? Nel mio caso in ufficio ho 4 postazioni tutte in grado di poter far girare questi software.
Per avere un beneficio prestazionale mantenendo i costi allo stesso livello che soluzione alternativa si potrebbe ipotizzare?Non è il mio campo. Posso dirti che molti grossi gruppi si affidano a fornitori di servizi, non si comprano di certo un Epyc per tenerselo sotto la scrivania.
Per esempio ho trovato "Garage Farm", la quale mette a disposizione una superfarm da 15'000 CPU e 256GB di RAM; ma la sua lista di applicativi forniti è incentrata sulla grafica e non l'ingegneria, quindi niente Revit.
Se avete un IT administrator, queste sono le cose di cui lui si dovrebbe occupare, in collaborazione con l'ufficio di ragioneria che valuterà i costi/benefici delle diverse soluzioni.
In alternativa potrebbe essere considerato anche, invece che fare 4 sistemi threadripper, fare un unico sistema Epyc (dalla forza computazionale pari alla somma dei sopracitati 4 sistemi), che faccia da serverfarm locale per tali applicativi, a cui poi gli utenti accedono (redigendo un calendario con time-slot) in caso di simulazioni computazionalmente più complesse. Tramite VPN puoi permetterne anche una gestione in mobilità, per esempio dall'ufficio del cliente o in trasferta di lavoro (con anche un semplice portatile).

Confermo, SW a livello di sfruttamento hw fa schifo.
Quando vado in tavola a volte non è fluido, indipendentemente da se sia con l'i3 e l'integrata o l'i7 e una P2000. :muro:

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..

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.

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.

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ì...

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.

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?

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).

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.

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..

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)

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.

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.

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

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. :mc:

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/technical/video-encoding-performance.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".

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.

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

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 milleCome 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.

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

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)

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.

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.

cut

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.

Trasformare un codice esistente che è nato mono th e man mano aggiornato ( o forse meglio dire adattato) per usare più core?
E chi si sognerebbe di fare un lavoro simile, credo che riscrivere tutto d'accapo sia molto meno complicato e dispendioso economicamente ( ma sempre molto costoso).
Va da se che software riscritti per usare 50 o 60 th siano quelli che gia costicchiano di loro adesso, e non i vari handbrake o image resizer dei test, ma software molto più specifici e di nicchia ( ed a riscrivere da zero software complessi richiede comunque molto tempo).
Quindi non mi aspetto di vedere revit multicore nextgen tra 1 anno o due, ma tutti stanno gia provvedendo perchè un software da svariate migliaia di euro ( magari di solo noleggio annuo) che rende più rapido il lavoro su workstation da 50 o più th ( che sarebbero comunque la spesa più bassa da affrontare) può affossare software che attualmente sono standard de facto nel giro di due anni di ritardo.
Quindi si oggi una nicchia nella nicchia può sfruttare questi mostri ( a meno di usare le cpu su server da usare per pilotare terminali stupidi in uffici di contabilità, ragioneria, anagrafe, incidendo comunque molto in energia, gestione, affidabilità sul totale di server classico più singoli pc)

Confronto impietoso per il 7960X.... costa il doppio e nell'MT va' uguale se non peggio del 2950X... :asd:

Mah.. gran belle bestie per carità.. ma in generale non è che l'entusiasmo sia alle stelle.

Siamo in piena guerra a chi ha più cores.. tuttavia la realtà dei fatti è che sfruttare la potenza a disposizione è sempre più difficile e solo in rare e determinate situazioni si riesce a tirare fuori la potenza di queste cpu.

Persino software che notoriamente traggono grande vantaggio dalla presenza di tanti cores fanno fatica a sfruttare tutti i cores presenti.

Praticmante sono CPU da server.. :mbe:

Ma che vai dicendo?

Mi pare di test dove questi 12/16/24/32 core decollino rispetto agli 8 core ce ne siano a iosa.

E' ovvio che se non usi il pc per lavoro queste cpu non ti servono.

Il 24C lo trovo a 1300 euro online.

Va oltre il doppio della cpu di riferimento in ambito (pro?)sumer ovvero la 9900k nei calcoli che ne costa 700.

Se devi fare calcoli queste cpu son belle bestie, altrochè, pochi cavoli.

Se leggete la recensione e pensate "a che mi serve?" è ovvio che non siete il target di queste cpu, no?

Mi chiedo come i threadripper WX si comportino con le macchine virtuali. Il caso d'uso che ho in mente e' un host con non meno di 3 macchine virtuali che girano. Il compito delle macchine virtuali e' compilare codice.

Qualcuno degli scenari descritti nei test si avvicina a questo tipo di utilizzo?

L'uso di virtual machines è senza dubbio il migliore per sfruttare a dovere così tanti cores.
Se poi devi farne convivere addirrittura tre che devono macinare calcoli per lungo tempo direi che sei nella situazione migliore per sfruttare le potenzialità di una CPU come questa.

Ripropongo una domanda collegata: tra i benchmark proposti nell'articolo ce ne sono che replicano lo scenario d'uso di più VM? :O
Se la risposta fosse no, quali sono i benchmark specifici di riferimento in questo caso specifico di uso multiplo di VM?

Ripropongo una domanda collegata: tra i benchmark proposti nell'articolo ce ne sono che replicano lo scenario d'uso di più VM? :O
Se la risposta fosse no, quali sono i benchmark specifici di riferimento in questo caso specifico di uso multiplo di VM?

Provo a risponderti io dato che uso abitualmente vmware sia workstation sia Esxi, non sono molto esperto ma ci provo.

https://www.vmware.com/products/vmmark.html

Questo potrebbe fare al caso tuo.

Da mia esperienza, una VM offre delle prestazioni leggermente più lente rispetto all'host se si usa VMWare workstation, al contrario la situazione migliora molto con esxi andando, di fatto, come se la macchina fosse fisica.
Usare ESXI però di preclude l'uso della macchina ovvero non puoi usarla stand-alone ma diventa un vero e proprio server accessibile solo da una postazione remota della stessa rete.
Io al lavoro uso ESXI sui server e VMWare workstation sul portatile per preparare le immagini da importare cosi posso farle quando ho tempo e sperimentare al bisogno.

Se hai qualche programma di riferimento faccio 2 prove con il dell e ti dico.

EDIT: @bonzoxxx: molto gentile; ho apprezzato la risposta. grazie.

https://www.vmware.com/products/vmmark.html
Se esiste un tale benchmark per VMware perchè non viene utilizzato per le recensioni di queste CPU?
:O

Capisco la differenza tra ESXi vs VM su Workstation ma allora nel primo caso non si usa più l'host con 3/4 VM che era appunto lo scenario descritto dall'altro utente. (https://www.hwupgrade.it/forum/showpost.php?p=45849420&postcount=25)

No, non ho programmi di riferimento da far girare all'interno delle VM.

Ma che vai dicendo?

Mi pare di test dove questi 12/16/24/32 core decollino rispetto agli 8 core ce ne siano a iosa.

E' ovvio che se non usi il pc per lavoro queste cpu non ti servono.

Il 24C lo trovo a 1300 euro online.

Va oltre il doppio della cpu di riferimento in ambito (pro?)sumer ovvero la 9900k nei calcoli che ne costa 700.

Se devi fare calcoli queste cpu son belle bestie, altrochè, pochi cavoli.

Se leggete la recensione e pensate "a che mi serve?" è ovvio che non siete il target di queste cpu, no?

Non fraintendiamo, non stavo parlando ne di una cpu nello specifico nè di prezzi o confronti tra intel ed AMD.
Sto facendo un discorso generale sulla nuova tendenza dell'aumeto dei cores perchè di fatto non si riesce più a salire di clock e di prestazioni col singolo core.
La questione che ho sollevato è che di fatto diventa difficile sfruttare la potenza teorica di una cpu come questa. Perchè come si è detto non solo non è semplice spezzettare il lavoro su più cores se non in specifiche attività e soprattutto non è detto che spezzettare voglia anche dire velocizzare.
E ovvimante questo fattore divneta sempre più marcato più aumenta il numero di cores.

Ripropongo una domanda collegata: tra i benchmark proposti nell'articolo ce ne sono che replicano lo scenario d'uso di più VM? :O
Se la risposta fosse no, quali sono i benchmark specifici di riferimento in questo caso specifico di uso multiplo di VM?

Il mio discorso è puramente logico:
Se hai 32 cores da sfruttare (e relativa adeguata ram) la cosa più facile da fare per tirargli il collo al meglio è avere esigenza di usare delle VM per attività varie.

crei ad esempio quattro virtual a cui affidi 8 cores ciascuna e poi ci fai girare qualche software di clacolo o altro su ognuna mentre tu vai avanti a fare altro senza timore di interferire con le vm in attività.
E' più facile trovare software che sfruttano quattro o otto cores che uno che ne usi decentemente 32.

poi se entriamo nello specifico credo sia giusto rimandare a quanto già indicato da bonzoxxx

Scientificamente parlando, per quel che mi riguarda, non hanno senso. Solo in pochissimi casi ho tempi di elaborazione di minuti e di certo lanciare un analisi e fare altro non è che faccia male alla produttività.
Vero che una ICA su 256 elettrodi e 20 soggetti è lunga ore, ma tanto non abbiamo quell'atrezzatura.
Servono a chi servono. Per me un i5 è già oltre le necessità.
Ovvio dipende dalle esigenze.

@demon77: grazie per la tua analisi.

Il punto è che quello che avevo chiesto in origine: esistono recensioni di queste CPU stile server di AMD in cui sono valutati gli scenari con le VM in ambiente Virtual Box / VmWare?

Vedo solo tanto 3D, multi-threading generico, editing video, compressione, giochi, ecc..

Oppure da quei benchmark si riesce ad ottenere un sotto-indice sintetico rappresentativo del modo in cui queste CPU lavorano con le VM? Capisco il discorso generico ci assegnare tot cores ad una CPU ma si tratta poi di verificare come funzionano ma mano che si 'scala' con il numero di VM...

Un po' come gli SSD: sembrano spesso uguali, poi se vai in quelli enterprise ti rendi conto della loro capacità di mantenere costante l'I/O / SQL nel corso di tutto lo spazio disponibile mentre magari il modello retail non ce l'ha... cose del genere.

:O

Qualcosa si trova ma nulla di specifico, se hai in mente un programma specifico faccio 2 test e te li giro

Non conosco un programma specifico per testare CPU a 24 cores :)
Se lo sapessi avrei già consigliato la redazione per programmare recenzioni completo di quel benchmark.

Credevo esistesse uno standard di riferimento di testing VM, al pari di tanti altri benchmark che cercano di simulare certe condizioni d'uso specifiche o combinate tra loro.

E' di questo che mi stupisco e per questo chiedevo lumi sulla ragione per cui test del genere non vengono mostrati nelle recensioni quando trovi PCMark, 3DMark, VRmark e tutti gli altri benchmark.

Nemmeno il Servermark sembra testare direttamente questo tipo utilizzo.

Forse perché è un settore troppo di nicchia oppure perché queste sono si cpu molto potenti ma non sono da server ovvero il loro utilizzo è dentro una WS ma non in un server benché supportino le ram ECC: nulla vieta mettere su un server su piattaforma x399 ma a quel punto si andrebbe a utilizzare esxi 6.7 per dedicare tutto il server alle macchine virtuali.

Dai stasera se riesco faccio una vm con 10 core vedo come in rendering e programmi di calcolo.

Dai stasera se riesco faccio una vm con 10 core vedo come in rendering e programmi di calcolo.

In realtà, come anche richiesto dall'altro utente, non si tratta di prendere 1 VM con 10 cores e vedere cosa succede ma semmai prendere 3/4 VM e vedere come scala assegnando i vari cores alle VM e come l'host si mantiene efficiente nel gestire il tutto.


E' più facile trovare software che sfruttano quattro o otto cores che uno che ne usi decentemente 32.

:cincin:

In realtà, come anche richiesto dall'altro utente, non si tratta di prendere 1 VM con 10 cores e vedere cosa succede ma semmai prendere 3/4 VM e vedere come scala assegnando i vari cores alle VM e come l'host si mantiene efficiente nel gestire il tutto.

:cincin:

Se usi ESXI le performance sono molto vicine alla macchina fisica, l'hypervisor gestisce dinamicamente la CPU fisica in modo da far andare la macchina virtuale al suo massimo tant'è che, sempre usando esxi, si possono far andare più macchina virtuali di quanti core ha il server: al lavoro ne ho uno 4core/8thread che ha fatto girare 7 host windows7 e 2 server virtuali win2008r2 senza alcun problema :) Per la RAM è un discorso diverso perché non viene assegnata dinamicamente ma è "fissa".

in teoria potresti tranquillamente fare un cluster virtuale di 4 macchine e farle lavorare assieme come fossero 4 distinte collegate il lan :)

Non capisco/conosco direttamente la differenza tra un ambiente con VMWorkstation ed il tuo ESXi ma anche con il primo puoi far girare 3 VM con 4 cores assegnati a ciascuna in contemporanea (totale 12 cores impegnati) anche se l'host ha solo 4 core fisici/8 virtuali grazie ad hyperthreading.

Certo non avvieno lo scenario dei "7 hosts windows 7" perchè l'host è solo 1. La RAM è assegnata fissa ad ogni VM ovviamente.

Comunque è di questo genere di test di cui non trovo traccia quando si vanno a valutare queste CPU con tanti cores, anche per capire l'impatto di Spectre in ambiente VMware con utilizzo contemporaneo di VM concorrenti. E tutto il discorso vale anche con Virtual Box o altri hypervisors :O

@Rubberick: ti ho già spiegato in passato, e con dovizia di particolari, come stiano le cose per quanto riguarda il software e il melodramma (perché ormai questo è divenuto) della problematica che riguarda la parallelizzazione (e con ciò intendo coprire sia il fatto di poter processare più dati alla volta facendo uso di unità SIMD "ciccione", sia il poter distribuire il carico di lavoro a più core, perché entrambi gli approccio soffrono di simili problematiche).

Purtroppo vedo che continui a riportare come un disco rotto le stesse cose: segno che o non capisci o non vuoi capire.

Aggiungo soltanto un altro esempio: Python. E' ben noto essere schifosamente single core/thread, causa adozione della famigerata GIL (se cerchi Python + GIL troverai carrettate di articoli/blog/discussioni) che sostanzialmente blocca l'esecuzione su un solo core & thread.
Considerata l'enorme diffusione di Python, sarebbe utile poter fare in modo che sfrutti più core. Pensi che non c'abbiano già pensato? Non solo pensato: anni fa è stata presentata una patch (per CPython: l'implementazione mainstream di questo linguaggio) che finalmente rimuoveva la GIL e, facendo uso di appositi lock (istruzioni utilizzati per gestire la contesa di risorse comuni fra più processori), consentiva di sfruttare tutti i core/thread hardware a disposizione.
Sai perché questa patch non è diventata parte ufficiale di Python? Perché DIMEZZAVA le prestazioni in single core/thread. Tu mi dirai: e qual è il problema? Basta avere almeno un paio di core e le prestazioni sarebbero bilanciate, per cui a partire dal terzo core ci sarebbero via via dei netti guadagni
Sbagliato! Perché questo succederebbe soltanto per applicazioni/codice in grado di sfruttare effettivamente tutti i core, il che ricade nella precedente discussione in cui ti ho mostrato che, per quanto ci si possa impegnare, non è possibile parallelizzare qualunque codice.
Per cui, visto che uccideva le prestazioni nella maggior parte dei casi, la patch non è mai stata integrata nel ramo principale di Python.
Se vuoi divertirti a sfruttare tutti i core con Python hai comunque la possibilità di farlo, SCRIVENDO CODICE AD HOC con la già integrata libreria multiprocessing oppure con una delle tante librerie che da anni consentono di farlo. Ma, ripeto ancora una volta: accomodati pure.

Si torna sempre allo stesso discorso: la parallelizzazione è, prima di tutto, un problema algoritmico. Poi, è una questione di costi e benefici.

Assolutamente sì. Il problema è farlo capire ai non addetti ai lavori, che sono "duri d'orecchio".

Provo a risponderti io dato che uso abitualmente vmware sia workstation sia Esxi, non sono molto esperto ma ci provo.

https://www.vmware.com/products/vmmark.html

Questo potrebbe fare al caso tuo.

Da mia esperienza, una VM offre delle prestazioni leggermente più lente rispetto all'host se si usa VMWare workstation, al contrario la situazione migliora molto con esxi andando, di fatto, come se la macchina fosse fisica.
Usare ESXI però di preclude l'uso della macchina ovvero non puoi usarla stand-alone ma diventa un vero e proprio server accessibile solo da una postazione remota della stessa rete.
Io al lavoro uso ESXI sui server e VMWare workstation sul portatile per preparare le immagini da importare cosi posso farle quando ho tempo e sperimentare al bisogno.

Se hai qualche programma di riferimento faccio 2 prove con il dell e ti dico.

A chi mi chiedeva di sentire l'IT e il responsabile commerciale, pare che un ufficio di 4 persone abbia un IT e un responsabile commerciale in grado di fare analisi costi benefici su un sistema virtualizzato? No, niente di tutto questo.

Qualcuno di volenteroso mi spiega a grandi linee come si configura un server (Anche "cieco", non utilizzabile) connesso in rete in modo che una o più postazioni possano usare il suo hardware? In questo modo si beneficierebbe, oltretutto, di mantenere le macchine per 10 anni senza problemi e aggiornare solo il server. Come dicevo l'applicazione ideale per me sarebbe Revit Mep. Per mantere bassi i costi si potrebbe avere anche una o al limite due licenze in modo da poter usare tutte le macchine ma non contemporaneamente. Non servono time slot o che, siamo in un open space e sappiamo tutti cosa si sta facendo, ci si gestirebbe il tutto senza programmazione (come facciamo ora con i software con chiave hardware)