Newsgroup: it.comp.hardware
Titolo: computer potente per calcoli

Ciao.
Mi servirebbe un computer tostarello per calcoli che girano su un processore 
alla volta.
Ad hardware sto a zero... che soluzione consigliate? So solo che 2gb di ram 
bastano e avanzano...
La maggior parte delle volte partono calcoli singoli, quindi nella mia 
ignoranza mi sono fatto l'idea che a parità di "potenza totale" un dual core 
sia meglio di un quad core.
Grazie 

Ciuk ha pensato forte :

Ma di che tipo di "calcoli" stiamo parlando?

 La maggior parte delle volte partono calcoli singoli
Se il "calcolo" è single core, prendi il processore con più Ghz.
Se lavori invece in multiprocessing, prendi il processore con più core.
-- 
_______________________________________
Luc (37, CO) -- Acer Aspire M5610 Q6600
MediaCenter HIPER HMC-2K53A-H2 AMD5200+
Fujitsu Siemens Amilo Si 1520 12" T2300
_______________________________________

 Se lavori invece in multiprocessing, prendi il processore con più core.
Anche se lavora contemporaneamente con più sessioni applicative, oppure 
in multitasking può prendere un quad core... dipene appunto dalla 
natura dei calcoli che deve svolgere.

Calcoli ad elementi finiti: meshing, calcoli strutturali, acustici, 
fluidodinamici.
So solo che i più importanti viaggiano sul singolo processore.
Quindi chiedevo qual è il processore con il singolo core più cazzuto.
E' una domanda stupida? Scusa ma non sono ferrato. Dal poco che ne so i mhz 
da soli non sono indicativi...
Grazie
"Lorenz"  wrote in message news:mn.0b2f7db45...@alientech.it...



Un processo di calcolo viene sempre eseguito da un'unica CPU, per far 
lavorare due CPU contemporaneamente dovresti lanciare due calcoli, ma 
indipendenti tra di loro.
Quindi se lanci molti calcoli indipendenti, piu' core ci sono meglio e', 
altrimenti se si tratta di un unico calcolo complesso un dual core e' 
adeguato e la differenza la fa la frequenza di lavoro.

 Un processo di calcolo viene sempre eseguito da un'unica CPU, 
Non è detto, se il processo è multithreaded?

 Calcoli ad elementi finiti:
IIRC i calcoli FEM sono ben parallelizzabili, ma è giusto un ricordo 
vago. Ovviamente poi dipende dall'implementazione quindi se ti hanno 
detto che va su un singolo core attieniti a quello.

 Non è detto, se il processo è multithreaded?
Devono essere calcoli indipendenti altrimenti si perde piu' tempo a 
coordinare i due thread che a eseguire il tutto su un unico core.

Infatti è così, questa è l'unica cosa certa...
Mi sapete quindi indicare un processore con i core cazzuti? Non mi interessa 
ne abbia 2-4-6 o non so a quanti siano arrivati... Ad esempio
piglio un phenom 2 con tre core e va bene (nel senso che siamo ad alti 
livelli di calcolo)?
"acc"  wrote in message 
news:4d95c33e$0$38651$4faf...@reader1.news.tin.it...


 da soli non sono indicativi...
Ormai le cpu hanno almeno due core... tralasciando quelli di fascia 
ultrabassa tipo alcuni Sempron. Perciò considerando la tipologia di 
elaborazioni che dovrà fare la cpu prendina una del tipo quad core.
E comunque devi prendere tutto un pc oppure basta solo l'accoppiata 
MB/cpu? Inoltre quanto volete spendere?

acc ci ha detto :

Si poi dipende anche dalla complessità instrinseca dei calcoli da 
elaborare... in determinati situazioni può essere più conveniente 
"perdere" un pò di tempo nella sincronizzazione iniziale dei thread, 
per poi farli comunque eseguire ad ogni core.

 mhz da soli non sono indicativi...
i7 2600K con 8Gb di Ram e Gtx460 (o Gtx560) per sfruttare cuda con
Matlab, in simulazione avanzata...
serve anche buona conoscenza di C++ ;)
Guido Veloce
-- 
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 i7 2600K con 8Gb di Ram  
La cosa che non mi convince molto però è che sostiene che il pc 
"macina" senza problemi anche con la presenza di soli 2GB di RAM...:)

 coordinare i due thread che a eseguire il tutto su un unico core.
Non è in discussione il tempo totale di esecuzione, ma che un processo 
venga sempre eseguito da un'unica CPU, questo non mi pare sia vero.

 senza problemi anche con la presenza di soli 2GB di RAM...:)
Il calcolo in genere ne richiede molta meno

acc ha pensato forte :

Certo,pure qui con dei distinguo... ma comunque mi riferivo adesso più 
che altro al fatto che Guido ha consigliato un sistema con subito 
8giga.
Probabilmente nel caso dell'OP ne bastano e avanzano 4 in questo caso 
:)

 venga sempre eseguito da un'unica CPU, questo non mi pare sia vero.
Se i calcoli sono indipendenti, si possono organizzare in piu' thread 
che funzionano parallelamente (fermo restando che un thread parte e 
muore sullo stesso core), viceversa e' improbabile ottenere benefici.
Aggiungo che l'organizzazione in thread di un calcolo e' una 
complicazione non da poco; va bene nel caso di un'applicazione "finita" 
dove e' utile ottimizzare i tempi, ma e' controproducente in fase di 
sperimentazione, dove cio' che piu' conta e' mantenere semplicita' e 
chiarezza.

 poi farli comunque eseguire ad ogni core.
La sincronizzazione non e' mai iniziale

acc ha spiegato il 01/04/11 :

C'è ad ogni suddivisione del ciclo elaborativo...ad esempio nel caso di 
processi che siano composti da più thread.

 processi che siano composti da più thread.
Di nuovo fai confusione...
Al momento della suddivisione del processo non si sincronizza nulla, si 
lanciano i thread e basta, la sincronizzazione avviene quando un thread 
termina e il processo dovra' attendere la fine degli altri.
Il tutto ovviamente si riferisce al caso di calcoli che, per poter 
proseguire, necessitano dei risultati intermedi di tutti i thread, 
altrimenti (con riferimento al post precedente) parliamo di calcoli (e 
relativi thread) indipendenti.

 indipendenti.
 Ovvio, dato che si stava parlando di multithreading...che poi in 
genere i thread di per se non sono indipendenti come lo possono essere 
i processi, anche se possono condividere le stesse variabili.
Comunque stiamo andando OT...:D

 Comunque stiamo andando OT...:D
Specifichiamo meglio perchè non si sa mai... sono indipendenti solo 
nell'ambito del processo in cui "risiedono" :)
Praticamente ricapitoliamo:
1) I programmi sono costituiti da processi.
2) I processi sono indipendenti tra loro, e posseggono dei registri, e 
delle variabili proprie.
3) I thread sono dei "processi leggeri" i quali hanno la caratteristica 
di condividere le stesse variabili globali per l'esecuzione di una ben 
determinata mansione.
4) Un processo può essere composto da un solo thread, o da più thread.
5) Più thread in un processo possono essere utilizzati per condividere 
lo stesso lavoro e cooperano per un qualche tipo di attività, mentre 
processi diversi sono generalmente scorrelati.
Va bene? :)

 processi diversi sono generalmente scorrelati.
Nella maggior parte dei casi, i thread si usano per fare attivita' 
indipendenti e diverse tra di loro.
L'utilizzo cooperativo per concorrere allo stesso fine e' piuttosto 
inusuale, per fare un esempio, mentre stai leggendo questo messaggio il 
tuo newsreader potrebbe decidere di scaricare nuovi messaggi con un 
altro thread, in tal caso ci sono due attivita' (visualizzazione 
messaggio e scaricamento thread) ma si tratta di compiti diversi e 
indipendenti.
Tornando al caso del calcolo, perche' la divisione in thread sia 
redditizia e' necessario che sussistano determinate condizioni, cioe' la 
presenza di blocchi che siano calcolabili indipendentemente e che questi 
richiedano diverso tempo, altrimenti il tempo perso nella gestione dei 
thread (overhead) puo' superare quello guadagnato.
Ti ricordi le (deludenti) prestazioni effettive dei primi NT su sistemi 
multiprocessore?

Il calcolo in genere ne richiede molta meno
Infatti, guardavo ad esempio proprio oggi un Sismicad della Concrete
su un vecchio Athlon64 3200+ che nei momenti critici arranca (CPU 100
per 10-15 secondi).
La RAM, però, era occupata per solo 250 MB.
In questo caso conviene puntare molto sul processore, è inutile
mettere anche solo 4GB se non ci sono altre richieste.
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.

 multiprocessore?
Francamente non molto... che poi NT l'ho usato poco all'epoca, specie 
in multiprocessing.
Ho cominciato a lavorare seriamente in tal senso a partire da 
Win2000...

 mettere anche solo 4GB se non ci sono altre richieste.
Vabbè... con quello che costa la RAM oggi può metterli lo stesso.
Male di certo non fa. Puoi fare anche un bel Ramdisk al limite :D

 alla volta.
io mi prenderei un x4 athlon, spendi poco e  gira a 3GHz  cloccabili 
tranquillamente


beh, se ha già l'eseguibile può fare poco. Molti programmi
agli elementi finiti sono stati riscritti da quando hanno
iniziato a uscire le CPU multi core perché precedentemente
erano stati concepiti, a livello architetturale, mai
potendo prevedere quel che avrebbe portato il progresso.
Se ha un eseguibile di vecchia concezione può solo
macinare MHz e cache come se piovesse (e non solo: di
quello che uso ho i sorgenti ma è un programma così
delicato e complesso che non ci metterei mai le mani per
parallelizzarlo, andrebbe proprio riscritto).
ciao!
Apx.
-- 
Un corpo immerso in un liquido si bagna.
Un corpo immerso nel cemento sapeva troppo.
Un corpo immerso in un altro corpo si diverte.
Un corpo immerso in due corpi è un'orgia.

 parallelizzarlo, andrebbe proprio riscritto).
In linea di massima concordo, ma spesso capita di avere
sottomano delle soluzioni ibride, ad esempio con delle Tesla,
e di non avere già pronta la "pappa" (i programmi specifici di
calcolo) e allora bisogna rnboccarsi le maniche e lavorare :)


Il 01/04/2011 15.26, Lorenz ha scritto:
 >>> Calcoli ad elementi finiti: meshing, calcoli strutturali, acustici,
 >>> fluidodinamici.
 >>> So solo che i più importanti viaggiano sul singolo processore.
 >>> Quindi chiedevo qual è il processore con il singolo core più cazzuto.
 >>> E' una domanda stupida? Scusa ma non sono ferrato. Dal poco che ne so i
 >>> mhz da soli non sono indicativi...
 >>
 >> i7 2600K con 8Gb di Ram
 >
 > La cosa che non mi convince molto però è che sostiene che il pc "macina"
 > senza problemi anche con la presenza di soli 2GB di RAM...:)
Da premettere che l'acquisto di 8 Gb di ram oggigiorno non costituisce
un problema e in ogni caso mi riferivo a soli 2 moduli di 4Gb per un
probabile aggiornamento totale a 16 Gb.
Probabilmente come sostiene l'operatore, utilizza qualche
soluzione di calcolo che fa un uso non "intensivo" di Ram ma
questo non "implica" che una macchina "buona e potente" per
i calcoli non ha bisogno di molta Ram, anzi, e qui mi limito
solamente con una dimostrazione per "induzione" (non me ne
voglia Peano, lol!) :
le Nvidia Tesla C2070, portano a bordo 6Gb di Ram...
ci sarà un motivo? o no?
Cmq, da quel che ha scritto l'operatore gli basta semplicemente
acquistare un i5 760, in cui la smart-cache contribuirà positivamente,
specialmodo nei calcoli sigle-thread, e 4 Gb di Ram.


 ci sarà un motivo? o no?
Texture, niente a che vedere con i calcoli

 Texture, niente a che vedere con i calcoli
Tanto per fare un esempio tra decine...
in una soluzione del genere
http://www.businessmagazine.it/news/workstation-quad-tesla-per-supermicro_32790.html
con 4 Tesla C2050 e potenza di calcolo di circa 4 TFlops
in singola precisione e circa 2 TFlops in doppia precisione,
si mettono a costruirci le "texture"? °_O
ROFTLMAOOOOOOOOOOOOOOOOOOOOOOOO :D
Probabilmente ti stai confondendo con i "calcoli renali"
ROFTLMAOOOOOOOOOOOOOOOOOOOOOOOO :D
Devo scappare che me la sto facendo addosso :DDDDDDD
Intanto ti consiglio di leggerti questi:
http://www.nvidia.com/object/GPU_Computing.html
http://www.mathworks.com/products/parallel-computing/
... si spera che capisci, ma la vedo dura  ^__^


 
http://www.businessmagazine.it/news/workstation-quad-tesla-per-supermicro_32790.html
Invece di parlare di cose che non sai, perche' non ti fai quattro conti?
Con un Giga di RAM puoi memorizzare 67 milioni di numeri in virgola 
mobile. Nel mondo reale e' i casi che necessitano di una tale mole di 
dati sono abbastanza rari (in quei casi non si usano comuni PC).
Nei calcoli comuni non serve mantenere risultati intermedi, si tende per 
quanto possibile a fare tutto nei registri della FPU, che sono 
sufficienti nella maggior parte dei casi, la RAM non serve, se non per 
mantenere grandi quantita' di array di poligoni, ma in tal caso parliamo 
di applicazioni grafiche (come quelle che hai citato).


Anche se non e' obbligatorio che un thread giri sempre sullo stesso 
core, di certo e' desiderabile. Se ad esempio hai piu' thread che core 
(caso abbastanza normale) e' ovvio che la situazione puo' cambiare, ma 
e' altrettando ovvio che il sistema tendera' a mantenere un thread sullo 
stesso core piu' a lungo possibile, pena l'inefficienza.
Nella peggiore delle ipotesi (sistema sovracaricato) in cui i thread 
durano il minimo possibile e vengono subito scambiati con altri 
processi, avresti un sistema che perde piu' tempo nel context-switch che 
per il lavoro che deve fare.

 core, di certo e' desiderabile. 
Non so come avrei potuto scrivere più chiaramente che le prestazioni non 
erano nel merito della discussione, lo era solo la tua affermazione che 
un processo venisse _sempre_ eseguito da un'unica CPU.

 di applicazioni grafiche (come quelle che hai citato).
Certo, in effetti i calcoli renali sono dei depositi di consistenza
dura che si formano per precipitazione dei sali minerali contenuti
nelle urine (calcio, ossalato, fosfati ed acido urico).
La formazione di un calcolo è favorita dall'aumento della
concentrazione di questi elettroliti o dalla riduzione del liquido
che li tiene in soluzione (scarso volume di urine).
Calcoli renaliQuando i sali si aggregano tra loro formano dapprima
cristalli, quindi microcalcoli ed infine calcoli che possono
raggiungere le dimensioni di una pallina da golf.
Proprio a causa della loro forma e composizione chimica i calcoli
renali possono muoversi dalla sede di origine e andare ad ostacolare
il flusso dell'urina. Tale ostacolo, oltre a causare un dolore spesso
intenso, favorisce lo sviluppo di infezioni urinarie e, se persiste
per lunghi periodi, aumenta le possibilità di danno ai reni, fino
a sviluppare una insufficienza renale progressiva.
Normalmente le urine contengono sostanze che impediscono la formazione
di calcoli, ma non sempre tali composti sono presenti in quantità
adeguate o svolgono efficacemente la loro funzione.
Oggi se ne conoscono due categorie: macromolecolari (di natura
proteica) e micromolecolari come il citrato o il magnesio.
Anche i mucopolissaccaridi, grazie alle loro proprietà colloidali
favoriscono il mantenimento in soluzione dei sali allontanando la
formazione di calcoli renali.


 un processo venisse _sempre_ eseguito da un'unica CPU.
Cosa cambia? Sarebbe come affermare che la cache non funziona perche' 
ogni tanto c'e' qualche "cache miss", irrilevante...
Allo stesso modo un thread gira per la maggior parte del tempo nello 
stesso core, nel caso dei multi-core spesso ci gira per *tutto il 
tempo*, il resto e' irrilevante.