Workstation di calcolo

[monticelli]

Ciao Traven.
L'AMD 9900x dovrebbe in effetti avere un guadagno prestazionale di circa il 200% su benchmark aggregati rispetto alla CPU notebook che hai ora: in altre parole, dovrebbe effettivamente garantirti la riduzione di un fattore 3 dei tempi che vorresti.
Pero' anche il tuo notebook sta andando troppo lento, il 12% di utilizzo CPU non si puo' vedere: mi verrebbe da pensare che sia un problema memory-constrained. RIesci a misurare anche l'utilzzo di memoria (e magari anche di disco) quando fai quei run con CPU 12%?
C'è effettivamente il rischio che questo SW sia poco o niente ottimizzato, purtroppo è abbastanza comune :-/

PS: ma le tue matrici che dimensioni hanno? Sopra o sotto il milione di righe/colonne?

 

[Ottoore]

Sicuramente limitato dalla memoria, naturale per quel tipo di software, ma non dal quantitativo. Ecco perché non comprerei una piattaforma consumer, men che meno un dodecacore su una piattaforma consumer.

avevo trovato una workstation fatta di Lenovo con un Intel Xeon Dodecacore W5-3423.

Ecco, questa mi pare un'opzione percorribile.

 

[Traven]

Allora ho trovato cose interesanti
Studi su ResearchGate e articoli accademici (es. "Performance of Sparse Matrix Solvers on Multi-core CPUs") indicano che i solver FEM come PARDISO sono spesso memory-bound. Passare da dual-channel a quad-channel può migliorare le prestazioni del 20-40% per problemi di medie dimensioni, e fino al 50% per problemi grandi.
Un test su Abaqus (simile a Sismicad) ha mostrato che un sistema quad-channel (Intel Xeon E5-2699 v4) era ~35% più veloce di un dual-channel (Core i7-8700K) su un'analisi non lineare.
Un test su ANSYS (fonte: Puget Systems) ha mostrato che passare da dual-channel DDR4-3200 a quad-channel DDR4-3200 ha ridotto i tempi di calcolo del 25% su un modello FEM di medie dimensioni. Un octa-channel DDR5-4800 (come nel Xeon w5-3423) ha offerto un ulteriore 15% di miglioramento per modelli grandi.
Quindi come dice Ottoore il collo di bottiglia è la memoria. Aquesto punto otterrei un leggero miglioramento anche con un 9600x. Oppure passo agli Xeon W, che i piu recenti hanno octa-channel, ma anche octa prezzo.

 

[Ottoore]

Perché non hai visto gli Epyc con 12 canali di memoria, altro che octa prezzo! L'opzione in assoluto migliore per te sarebbe l'Epyc 9184x (impatto positivo della cache maggiorata sul tuo workload).

In realtà ora che ci penso c'è anche l'octacore Epyc 9015 che costa poco più di 500€ (~900 per il 9115, 16 cores) e condivide il controller 12-channels con l'intera lineup Epyc Turin (quindi Zen5). Ovviamente rimane il costo della piattaforma (compresi 12 moduli di DDR5).

 

[monticelli]

Si' ma Xeon E5-2699 v4 e i7-8700K sono CPU vecchie (poi lo Xeon ha 22 core, l'i7 ne ha 6, il prezzo di lancio del primo era piu' di 10 volte il secondo, che test è? ), secondo me la situazione è diversa ora. Non ho trovato il confronto esatto tra 9900x e lo xeon che citi, qui c'è il confronto con uno xeon un po' piu' potente, con 16 core.
Comunque, a prescindere, il 12% di CPU è troppo poco, secondo me non si spiega con il dual-channel. Hai provato a monitorare l'utilizzo della memoria quando fai quei run dove la CPU va al 12%?
Per esperienza personale ti posso dire che il parallelismo multicore per i codici FEM funziona bene sulle CPU consumer di ultima generazione: l'unico problema è che io utilizzo codici ottimizzati in C/C++ con OpenMP su Linux, tu SW commerciali black box su Windows, e non vorrei che questo contribuisse a creare il deficit di prestazioni che osservi.

 

[Traven]

Ho registrato una sessione ieri pomeriggio. Domani mattina controllo e posto qualche screen

 

[Traven]

Buon pomeriggio ragazzi, ho fatto alcuni teest, tanto che dovevo rifare due pushover. vi dico come le ho impostate
1° pushover con Solver Intel MKL pardiso + modello ad aste + driver radeon adrenalin
GPU CPU+RAM la ram non si muove, al masssimo 100MB e un 2% della cpu se lo prende lo screen
Tempi 33 min.

2° pushover con Solver Intel MKL pardiso + modello a Gusci+ driver radeon adrenalin
Tutto invariato ma tempi sulle 3 ore (non terminata).

3° pushover con Solver AspenTech MA57 + modello ad aste+ driver radeon pro
GPU CPU+RAM
Lieve riduzione del carico CPU di 2% (penso grazie ai driver) (gli screen danno un lieve balzo)
ma Tempi di 26min (dovuto alle Aspen).

4° pushover con Solver AspenTech MA57 + modello a gusci+ driver radeon pro
Tempi sulle 2 ore (non terminata).

Per avere i tempi di mezz'ora ho lanciato i modelli con gli interventi di progetto. in situazioni invece di stati attuali, con piani non rigidi le matrici si complicano e anche per analisi ad aste si comincia a salire sui 60/90 minuti molto facilmente, ed è dove vorrei risparmiare. Cmq la differenza dei solver non l'avevo mai percepita in modo cosi netto. Diciamo che è un buon inizio.
Prima di spendere in Hardware credo che farò un aggiornamento del software, ho letto che la versione successiva della mia beneficia di un importante aggiornamento sul calcolo parallelo.

Vi dirò come vanno le pushover dopo l'aggiornamento.
un saluto a tutti

 

[Traven]

Perché non hai visto gli Epyc con 12 canali di memoria, altro che octa prezzo! L'opzione in assoluto migliore per te sarebbe l'Epyc 9184x (impatto positivo della cache maggiorata sul tuo workload).

In realtà ora che ci penso c'è anche l'octacore Epyc 9015 che costa poco più di 500€ (~900 per il 9115, 16 cores) e condivide il controller 12-channels con l'intera lineup Epyc Turin (quindi Zen5). Ovviamente rimane il costo della piattaforma (compresi 12 moduli di DDR5).

Ah e grazie della dritta. in effetti è davvero molto interessante considerando il TDP e il numero di canali di memoria, e un costo non per niente eccessivo. ci farò un pensiero

 

[monticelli]

Ciao Traven,
grazie per i risultati delle prove.
E' una situazione complicata, difficile da sbrogliare perché è un SW chiuso in cui si ha pochissima visibilità del workflow, per di piu' gira su windows che probabilmente ci mette del suo. Poi non è un SW di calcolo "puro" ma tratta anche elementi di normativa, etc.
Il problema fisico in se' è non banale, perché è un'applicazione di dinamica non lineare che, anche per dimensioni non stratosferiche (a proposito, qual è l'ordine di grandezza delle matrici? Migliaia di righe/colonne? Milioni? ...) può essere scontroso da trattare.
La mia esperienza in questo campo, in passato, era su problemi lineari di grandi dimensioni di risposta dinamica di strutture sottoposte a sollecitazioni sismiche (quindi eq. lineare delle onde elastiche), fatti girare su macchine parallele dipartimentali ma anche PC consumer.
I codici tipo quello che stai usando tu, nel mio ricordo, erano SW anche piuttosto avanzati dal punto di vista fisico/modellistico, molto meno dal punto di vista della numerica e dell'efficienza computazionale. Quello era uno dei motivi per cui avevamo lanciato un programma di R&D su codici per l'elasticità lineare di grande scala.
Il dato del 14% di utilizzo della CPU, con rare punte al 25%, però non è accettabile da nessun punto di vista lo si guardi: visti anche i dati di temperatura e consumo viene da pensare che la CPU non stia facendo quasi niente. Anche ipotizzando un guadagno del 50% grazie all'adozione di CPU con supporto multi-channel alla RAM, passeremo al 21% di utilizzo CPU, per me comunque inaccettabile.
Ho scaricato la versione trial del SW che usi, se vuoi posso fare una prova sulla mia macchina di casa, che ha un i7 13700K, 32 GB di RAM DDR5 e GPU Nvidia 3060. Potresti nel caso passarmi un caso d'esempio, da fare girare sulla tua macchina e sulla mia, per confrontare le performance. Non deve essere necessariamente uno dei tuoi casi di lavoro, su cui possono esserci ovvi problemi di non-disclosure, va benissimo anche un caso preso dal Web.
Fammi sapere se puo' aiutare.

 

[mr_loco]

Buon pomeriggio ragazzi, ho fatto alcuni teest, tanto che dovevo rifare due pushover. vi dico come le ho impostate
1° pushover con Solver Intel MKL pardiso + modello ad aste + driver radeon adrenalin
GPU Visualizza allegato 492669 CPU+RAM Visualizza allegato 492670 la ram non si muove, al masssimo 100MB e un 2% della cpu se lo prende lo screen
Tempi 33 min.

2° pushover con Solver Intel MKL pardiso + modello a Gusci+ driver radeon adrenalin
Tutto invariato ma tempi sulle 3 ore (non terminata).

3° pushover con Solver AspenTech MA57 + modello ad aste+ driver radeon pro
GPU Visualizza allegato 492673 CPU+RAMVisualizza allegato 492674
Lieve riduzione del carico CPU di 2% (penso grazie ai driver) (gli screen danno un lieve balzo)
ma Tempi di 26min (dovuto alle Aspen).

4° pushover con Solver AspenTech MA57 + modello a gusci+ driver radeon pro
Tempi sulle 2 ore (non terminata).

Per avere i tempi di mezz'ora ho lanciato i modelli con gli interventi di progetto. in situazioni invece di stati attuali, con piani non rigidi le matrici si complicano e anche per analisi ad aste si comincia a salire sui 60/90 minuti molto facilmente, ed è dove vorrei risparmiare. Cmq la differenza dei solver non l'avevo mai percepita in modo cosi netto. Diciamo che è un buon inizio.
Prima di spendere in Hardware credo che farò un aggiornamento del software, ho letto che la versione successiva della mia beneficia di un importante aggiornamento sul calcolo parallelo.
Visualizza allegato 492675
Vi dirò come vanno le pushover dopo l'aggiornamento.
un saluto a tutti

il notebook è collegato alla corrente? utilizza attività di sistema per vedere il lavoro della cpu, con grafico su singolo core, a me pare che non stia lavorando proprio, il wattaggio della cpu è di 24W

 

[Traven]

Ciao Traven,
grazie per i risultati delle prove.
E' una situazione complicata, difficile da sbrogliare perché è un SW chiuso in cui si ha pochissima visibilità del workflow, per di piu' gira su windows che probabilmente ci mette del suo. Poi non è un SW di calcolo "puro" ma tratta anche elementi di normativa, etc.
Il problema fisico in se' è non banale, perché è un'applicazione di dinamica non lineare che, anche per dimensioni non stratosferiche (a proposito, qual è l'ordine di grandezza delle matrici? Migliaia di righe/colonne? Milioni? ...) può essere scontroso da trattare.
La mia esperienza in questo campo, in passato, era su problemi lineari di grandi dimensioni di risposta dinamica di strutture sottoposte a sollecitazioni sismiche (quindi eq. lineare delle onde elastiche), fatti girare su macchine parallele dipartimentali ma anche PC consumer.
I codici tipo quello che stai usando tu, nel mio ricordo, erano SW anche piuttosto avanzati dal punto di vista fisico/modellistico, molto meno dal punto di vista della numerica e dell'efficienza computazionale. Quello era uno dei motivi per cui avevamo lanciato un programma di R&D su codici per l'elasticità lineare di grande scala.
Il dato del 14% di utilizzo della CPU, con rare punte al 25%, però non è accettabile da nessun punto di vista lo si guardi: visti anche i dati di temperatura e consumo viene da pensare che la CPU non stia facendo quasi niente. Anche ipotizzando un guadagno del 50% grazie all'adozione di CPU con supporto multi-channel alla RAM, passeremo al 21% di utilizzo CPU, per me comunque inaccettabile.
Ho scaricato la versione trial del SW che usi, se vuoi posso fare una prova sulla mia macchina di casa, che ha un i7 13700K, 32 GB di RAM DDR5 e GPU Nvidia 3060. Potresti nel caso passarmi un caso d'esempio, da fare girare sulla tua macchina e sulla mia, per confrontare le performance. Non deve essere necessariamente uno dei tuoi casi di lavoro, su cui possono esserci ovvi problemi di non-disclosure, va benissimo anche un caso preso dal Web.
Fammi sapere se puo' aiutare.

Grazie, provo a vedere qualcosa, loro hanno una piccola libreria di esempi.
Però non so se con la freetrial riesci a fare gran che.
Ah avevo monitorato i clock della CPU con CPUZ e i core li usa tutti e 8, ma a caso, 1 poi 2 o 3.