Newsgroup: it.comp.hardware.cpu
Titolo: processorori veloci, bus lenti

nell'ambito della ricerca, spesso succede di dover
effettuare calcoli in aritmetica ad interi che
impegnano molto il silicio ma che necessitano di poca
ram.
fra i piu' comuni sistemi e a parita' di costo, mi par
di capire, che i celeron sono la scelta migliore
(corregetemi, altrimenti), ma se si volesse progettare
un sistema dedicato, 64bit, una scheda da montare su
un computer esistente che si carica un blocco di
64/127/256 Kb contenenti sia dati che codice, esegue i
calcoli necessari e restituisce i risultati, che
carico di lavoro di progettazione/ costi e
performances si otterrebbero?
Oha
"Ci sono tre tipi di persone al mondo: quelle che sanno contare, 
e quelle che non ne sono capaci."

performances si otterrebbero?
per progettare da zero un sistema dedicato? milioni di dollari.
progettare da zero un sistema general-pourpose competitivo con i sistemi
odierni? _CENTINAIA_ di milioni di dollari.
non per nulla sono sempre meno i progettisti di hardware che si imbarcano
in progetti realmente nuovi, tutti gli altri si limitano a prendere pezzi
di altri progetti, rimescolarli e infilarci una o due cosette proprie per
poi rivogarli come miracoli del tutto inediti....
---
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
    I bimbi buoni vanno in paradiso.
    I bimbi cattivi vanno dove gli pare!

poi rivogarli come miracoli del tutto inediti....
si, e se alla intel avessero preso il bx, aggiunto il divisore 2 agp
al northbridge e un decente controller ata66 al southbridge avrebbero
potuto tirare fuori un bel chips. "CX" o "DX" per buoni comp. a basso
costo... con FSB "certificato" a 133 (tanto sappiamo che il bx regge
anche i 150..).
Invece ha tirato fuori quell'obbrobrio di 810 e quel millennium bug
(ovvero ci vuole un millenium per debuggarlo) dell'820...
--
[GAP], il [GAP] dei [GAP] - diffidate delle imitazioni :-)

 nell'ambito della ricerca, spesso succede di dover
<snip>
domandina: vuoi farti un sistema full-custom?? ovvero vuoi andarti a
progettare un ASIC??
rispostina: si ---> consiglio: lascia perdere......... (per esperienza)
se invece stai pensando ad un sistema generico di tipo standard, le
soluzioni potrebbero essere diverse.
la + semplice IMVHO e' la classica schedina DSP programmabile (una TI "base"
va' + che bene) su bus pci (ne esistono sia 32/33 che 64/66) che, seppur
progettata per i calcoli matriciali/vettoriali sugli fp, puo' discretamente
fungere anche come integer number cruncher, al limite spendi qualche $$ in +
e prendi quella col ctrl di ram integrato e uno slot dimm. in questo caso si
parla di spendere qlcs intorno ai 120US$.
se invece ti serve qlcs di + specifico si potrebbe pensare ad una soluzione
semi-custom. in questo caso avresti due possibilita': progettare un sistema
microprogrammato oppure progettare la funzione che devi realizzare
direttamente in logica cablata con delle PLA. la prima ha il vantaggio di
essere discretamente semplice e ancora abbastanza veloce, la seconda ha il
grosso vantaggio (IMHO) se ben progettata di essere veloce quanto un asic
mal progettato (ce ne sono moltissimi.......... anche perche' e' molto
facile sbagliare e molto costoso correggere). entrambe cmq presentano un
grado di difficolta' progettuale assoluto molto alto, anche se e' nulla in
confronto a quello dell'asic.
come ultima soluzione potresti pensare di prendere una qualunque cpu
economica ma superscalare e pipelined sugli interi (un k6-x, un 680xx, un
P1, etc etc etc), appiccicarci un ctrl di ram (magari te lo progetti o lo
prendi di quelli std, tanto le funzioni da implementare sono banali) e
qualche gestore di interfaccia da/verso il pci, aggiungere a piacere un po'
di SRAM (256KB bastano e avanzano) da usare per i dati e una ROM per il
codice (che tanto essendo banalmente ricorsivo molto probabilmente sara'
tutto contenuto nella L1) e il gioco + o - e' fatto. va' da se' che tale
soluzione sarebbe la + semplice da realizzare, testare e programmare, pero'
e' altrettanto chiaro che e' pure quella meno performante in assoluto, anche
se sicuramente andresti + veloce di una cpu che deve pensare al SO, all/I/O,
al video, a tutte le schifezze che zio Bill mette in background senza dire
nulla (qlcn ha mai sentito parlare di wmiexe, che e' lanciato dal systray??)
etc etc etc.
insomma come al solito tutto dipende da quanto tempo, soldi e fatica hai
deciso di spendere sul progetto.
ciao

 performances si otterrebbero?
Una cosa del genere puo` essere gia` fatta con le FPGA (ad esempio guarda
www.xilinx.com
). Esistono schede PCI che montano FPGA a diverse centinaia di
MHz, e dato che puoi "ottimizzare" la loro logica in base a un determinato
scopo, forse a parita` di clock riescono ad essere anche piu` performanti di un
processore 'von neumann' generico.
Lo svantaggio e` che non e` affatto semplice usarle. Sia le schede che i
software di sviluppo costano milioni; non credo che siano in molti a usare le
FPGA nella pratica, ma a livello accademico sono molto studiate.
--
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

 wrote:
:)domandina: vuoi farti un sistema full-custom?? ovvero vuoi andarti a
:)progettare un ASIC??
[forse il mio post ha dato l'impressione che io sappia
quello che dico :^7 ]
tutto quello che ho letto e' interessante, ma temo che
sia in buona parte fuori dalla mia portata, se non per
quanto riguarda i dsp, forse.
a parte il tempo, gli investimenti in denaro per
progettare macchine dedicate sembra moolto piu' alto
che la paralellizzazione su piu' macchina x86,
sbaglio?
partendo al contrario, e ipotizzando un bilancio
domestico (pochi miglioni), conviene passare tempo a
cercare, studiare e far funzionare un dsp piuttosto
che implementare un MP su lan?
vi faccio un esempio pratico...
supponiamo di avere una f(n) O(n log n) che per per
n=10e9 richieda circa 1 secondo di cpu su un pII 350 e
che f(n1) sia indipendente da f(n2).
io potrei distribuire il calcolo su piu' macchine, per
questo sbaglio a pensare che una implementazione
diversa sia controproducente in termini di costi?
se invece supponiamo un problema non parallelizzabile,
quanto costerebbe un DSP che riuscirebbe a raddoppiare
la potenza di calcolo della macchina sulla quale e'
montata (e.g. pII 350)? (in questo caso, suppongo di
delegare al dsp una unica funzione complessa,
lasciando il resto dei calcoli alla CPU)
Oha
---


estendo la mia domanda:
a parita' di performances, qual'e' il piu' economico
sistema per effettuare calcolo in aritmetica ad
interi, 64 bit [1] ? (mi riferisco a performance tipo
pII)
Oha
[1] - se il processore e' a 32 bit dovra' fare piu'
conti, 3 volte tanto per le moltiplicazioni, come
esempio.


(ovvero ci vuole un millenium per debuggarlo) dell'820...
Qui hanno avuto problemi seri... beh, diciamo che hanno fatto delle enormi
cazzate.
l'idea di base era buona, il sistema ad hub e' una manna per il gtl+ (anche
se ancora insufficiente...), ma le rambus avrebbero richiesto almeno altri
due anni prima di essere sviluppate a sufficienza da essere proponibili
(cosa che le avrebbe messe totalmente fuori mercato...).
(quattro bit di bus? OTTOCENTO MEGAHERTZ per fare quello che le altre fanno
a 150? ma scherziamo?)


 lasciando il resto dei calcoli alla CPU)
ecco, il pto e' proprio questo. pochissime (e quando dico pochissime intendo
veramente mooooooolto poche) categorie di problemi sono parallelizzabili in
maniera nativa (che non vuol dire gestibili in thread separati, ma proprio
implementabili con due flussi di prg separati e interagenti) e normalmente
la gestione di un prg parallelo e' molto complessa.
in generale quindi si preferisce gestire il tutto con sistemi dedicati
quando serve veramente tanta potenza.
nota che molti confondono il parallelismo computazionale con le architetture
multiprocessore. una mobo con 2 cpu in genere, in ambito domestico, NON sta
facendo girare un prg parallelo, ma molto + semplicemente due prg diversi (o
due thread, che e' la stessa cosa + o -).
ma torniamo a noi, se mi parli di apps "casalinghe" allora direi che la
soluzione su schedina DSP (che BTW incorpora anche ovviamente l'ADC, nel msg
precedente l'avevo dimenticato...) e' quella che permette le migliori
prestazioni rispetto al costo in assoluto ed e' inoltre discretamente
semplice da programmare.
altro tipo di problema e' invece se mi parli di gestire un prg di tipo
vettoriale (SIMD, che NON e' un prg parallelo), ovvero che applica la stessa
operazione su + dati contemporaneamente. in questo caso direi che i costi di
una soluzione dedicata (DSP et similia) salgono decisamente troppo (una
schedina di acquisizione ed elaborazione dati vettoriale della HP costicchia
oltre i 10M£) mentre invece potrebbe risultare molto soddisfacente una
soluzione sotto E3Dnow o Altivec oppure l'implementazione di una rete in cui
ogni singolo pc si occupa di un "pezzettino" di vettore da trattare.
insomma tutto dipende dalla applicazione che hai in mente.
ciao

 wrote:
:)insomma tutto dipende dalla applicazione che hai in mente.
obvious. ma questo non lo so.
ora come ora, sto testando delle coppie di numeri a,p
e verificando se soddisfano un'equazione.
il processo e' ottimizzato sfruttando alcune
caratteristiche dell'equazione, quindi per calcolare
a2,p devo conoscere tutti i risultati della f(a1,p)
per tutti gli a1<a2
quindi e' parallelizzabile "nativamente" per p, non
per a
per questo intendo preparare un server (probabilmente
usando MPI) che distribuisce i valori di p ai diversi
processi remoti, che iniziano a controllare tutti gli
a e restituiscono al server i risultati.
per questo _non_ e' conveniente (credo) un DSP o che
altro.
interessante invece sarebbe avere un DSP che calcola
aritmetica ad interi a 64 bit (il mio celeron, per
quanto ne ho capito fin'ora, riesce a fare conti solo
a 32bit in aritmetica ad interi) o meglio a 128bit
questo mi permetterebbe di superare alcune barriere
molto scomode.
per esempio, se devo fare una moltiplicazione a
128bit, su una macchina a 32bit, posso limitare il
numero di moltiplicazioni con karatsuba, e con 9
moltiplicazioni ottenere il risultato. (devo usare
codice macchina, altrimenti in C ho bisogno di molte
piu' moltiplicazioni)
questo mi permette di intuire che un DSP a 128bit, se
girasse a 100Mhz, andrebbe come un processore a 32bit
a 900MHz (il prefetch e le pipelines non servono, in
questo caso)
quindi avere a disposizione un unita' esterna di
calcolo _potrebbe_ essere un vantaggio, se poi in C
riesco ad accedervi senza problemi (sommando le
potenze di calcolo dei due silicio)
ma quanto impiego per caricare sul DSP i dati da
moltiplicare (supponiamo 128bit x 128bit)?
tornando a noi, io credo che i progetti che
affrontero' di qui a qualche anno saranno solo in
aritmetica ad interi (o derivati). un DSP montato come
PCI sul mio computer potrebbe aiutarmi di piu' (a
parita di costo) di un secondo computer?
Oha


 parita di costo) di un secondo computer?
no, se devi lavorare solo sugli interi un DSP potrebbe non essere la
soluzione ideale.
IMHO se c'e' una cosa che una cpu consumer sa' fare veramente bene sono i
calcoli sugli interi. hai provato a dare uno sguardo alle estensioni mmx????
sarebbe anche interessante nel tuo caso una soluzione multi-cpu, magari con
un SO che permetta l'uso esclusivo di una cpu per un dato task. cmq, ripeto,
qui siamo decisamente OT, prova a chiedere in qualche gruppo +
specificatamente orientato al SW.
in finale, se mi permetti un suggerimento, per affrontare il tuo prob
probabilmente avrei fatto cosi': mi sarei procurato una macchina x86 (K7
oppure P3, in ordine di gradimento personale) sotto Linux/W2000 con un buon
quantitativo di ram (128MB) su cui avrei fatto girare un programmino client
che gestisce il calcolo dei vari pacchetti, "fisicamente"  realizzato su
macchine
server, gestendo il tutto magari sotto un protocollo "facile" (ipx o tcp) da
gestire.
le macchine server le avrei prese di tipo alpha (native 64bit. anche un
semplice 21164 andrebbe benissimo) molto "light", diciamo con 32MB di ram e
un disco da 1GB (e' anche troppo come conf, ma non credo si possa trovare di
meno) con sotto un linux molto base, kernel, qualche servizio essenziale e
nulla +.
in questo modo puoi fare una specie di rete a stella, con l'x86 che funge da
"supervisore" e fornitore di dati.
noi in lab all'universita' ai tempi facevamo cosi', dato che c'erano solo 10
macchine alpha (e tutte riservate ai maledetti tesisti, presenti esclusi
ovviamente......) quando ci serviva di fare qlcs di molto pesante loggavamo
su un client x86 e poi aprivamo un telnet muto sulle 10 macchine alpha con
altrettante sessioni di matlab a cui venivano dati in pasto i vari
pacchetti. ah... bei tempi.....
ciao

ho letto il vostro messaggio non ho capito nulla ma dalle parole chiave:
rete, MMX, LINUX, OTTIMIZZAZIONE, CALCOLO ecc. vi posso indicare un
programma che si trova gratuitamente sia per linux, os/2 e winporc.
E' un compilatore pascal Moooooolto potente ottimizato al massiomo per MMX e
la cpu che usa il sistema si FreePascal il pacchetto linux e' fpc-xxx.rpm
lo trovate su 
www.linuxberg.org
Spero di essere stato di aiuto.

 ho letto il vostro messaggio non ho capito nulla ma dalle parole chiave:
<snip>
interessante, c'e' ancora qlcn che si sbatte per scrivere un compilatore
Pascal ottimizzato!!!
lo provero' di sicuro (anche se mi devo andare a rileggere gli appunti di
fondamenti di informatica, l'unico corso dove ho sentito parlare di Pascal),
grazie dell'info.
ciao

 lo trovate su 
www.linuxberg.org
I sorgenti su 
http://www.freepascal.org
, ma come compilatore ottimizzante
e' meglio egcs.

Supporta le istruzioni 3Dnow ed MMX, io non ho mai letto il suo manuale, ho usato
il fpc (PASCAL non C) e leggendo il mauale ho visto ste cose.
Lorenzo Cirio ha scritto:

--
_______________________________________________________________________________________
Per un po' di tempo non potro' seguire il gruppo
le risposte che mi darete giratele anche al mio indirizzo 
ko...@libero.it
in modo che possa rispondere grazie.
_______________________________________________________________________________________

 wrote:
:)no, se devi lavorare solo sugli interi un DSP potrebbe non essere la
:)soluzione ideale.
ok.
:)IMHO se c'e' una cosa che una cpu consumer sa' fare veramente bene sono i
:)calcoli sugli interi. hai provato a dare uno sguardo alle estensioni mmx????
no. per quanto mi e' stato detto, MMX non mi aiuta
sugli interi.
:)qui siamo decisamente OT, prova a chiedere in qualche gruppo +
:)specificatamente orientato al SW.
hai ragione.
:)in finale, se mi permetti un suggerimento, per affrontare il tuo prob
:)probabilmente avrei fatto cosi': mi sarei procurato una macchina x86 (K7
:)oppure P3, in ordine di gradimento personale) sotto Linux/W2000 con un buon
:)quantitativo di ram (128MB) su cui avrei fatto girare un programmino client
:)che gestisce il calcolo dei vari pacchetti, "fisicamente"  realizzato su
:)macchine
ora c'e' solo un pII350 con linux Debian ridotto
all'osso. (spunto il 98% della CPU, afaik)
grazie
