Link alla notizia: http://www.hwupgrade.it/news/cpu/e-di-fujitsu-la-cpu-piu-veloce-al-mondo_28996.html

Il colosso giapponese sviluppa un processore a otto core in grado di esprimere una potenza computazionale di 128 gigaflop

Click sul link per visualizzare la notizia.

cavolo molto interessante... ma qualche informazione in piu sulla piattaforma e quant'altro?

ma è compatibile x86? non credo sinceramente....

gli sparc non sono male,purtroppo sono poco diffusi!

ma è compatibile x86? non credo sinceramente....

Ovviamente no, sono processori destinati ad server di alto livello ;)

Magari ci fanno un porting di Crysis...

ma è compatibile x86? non credo sinceramente....

che io sappia l'architettura x86 negli ultimi 20 anni non è mai stata la più veloce :p

e te pareva ke nn usciva un commento su crysis XD

Come hanno scritto su altri siti...ma il Cell non faceva gli stessi gigaflop o anche meglio?

ma gli xeon non avevano specifiche più performanti degli i7 oltre che ad essere anche pensati per ambito server? non è più sensato fare un paragone con quelli?

Gli SPARC sono CPU destinate ai server di fascia medio-alta. Sono usati da SUN e da Fujitsu sulla fascia Primepower. Di solito impiegano Solaris come sistema operativo.

Per supertigrotto : gli sparc sono i processori storicamente utilizzati da SUN, nelle sparcstation (workstation) o nei vari server ..... poi mi sa che le usano anche altri produttori ......

Ultimamente SUN utilizza anche architettura x86 per roba di basso livello, ma la punta di diamante della produzione è sempre su architettura sparc .....

comunque, sono tutti sistemi che supportano UNIX e LINUX, per cui se un gioco ha un porting linux ci potreste giocare davvero :D (col sistemista che vi squarta sul posto però :D, ad occhio fra gli applausi)

saluti

;)

Gyxx

La potenza di cell è data in buona parte dalle SPU vettoriali che però non sono performani in qualunque contesto....

che io sappia l'architettura x86 negli ultimi 20 anni non è mai stata la più veloce :p

dipendi a cosa misuri al velocità

dipendi a cosa misuri al velocità

non a quanti fps fa a crysis! ^_^
Apparte gli scherzi in gigaflop credo :fagiano:

gli x86 se li sognano tutti sti gigaflops XD

tra dieci anni questa cpu ce l avremo sui cellulari....

Davvero incredibile che numeri !!!

per me ci fanno girare crysis in macchina virtuale in modalità full software rendered... che dite, così ce la fa a girare decentemente? :D :D :D :D :D

ma allora che senso ha fare un paragone? magari ha un architettura che se ci potessi far girare sopra windows sarebbe un chiodo (1 processore intendo, chiaro che su un supercomputer da 10.000 processori è un'altro discorso, a parte che microsoft non te lo fa installare perchè sull'etichetta di winzozz c'è scritto 1-2 CPU, non 1000-2000 :asd: )

sinceramente sto crysis ha un po rotto i maroni! ma capperi c'entra con questa cpu! ma se è destinata ai server! ma fatemi il piacere di non commentare che è meglio...

sinceramente sto crysis ha un po rotto i maroni! ma capperi c'entra con questa cpu! ma se è destinata ai server! ma fatemi il piacere di non commentare che è meglio...

Ti quoto, a volte si commenta proprio fuoriluogo.. Soprattutto con sto CRYSIS.. bel gioco pesante ok.. ma non centra una mazza con sta roba.. Cmq bel processore.. lo voglio anche io!!!!(Per il mio muletto-server)

per me ci fanno girare crysis in macchina virtuale in modalità full software rendered... che dite, così ce la fa a girare decentemente? :D :D :D :D :D

un superpi da 1M non c'è l'ho mettiamo?? :ciapet: :ciapet:

:doh:

Ti quoto, a volte si commenta proprio fuoriluogo.. Soprattutto con sto CRYSIS.. bel gioco pesante ok.. ma non centra una mazza con sta roba..

Cmq bel processore.. lo voglio anche io!!!!(Per il mio muletto-server)

:D :D

edita la sign max 3 righe a 1024x768 tu ne hai 4 a 1280x1024 :fagiano: ;)

un superpi da 1M non c'è l'ho mettiamo?? :ciapet: :ciapet:

:doh:

Che lingua é ?????

Che lingua é ?????

c'è l'ho :sofico: :doh: :doh: azz mi sbaglio sempre :fagiano: non fustigatemi :stordita:

sera a tutti, per rispondere a tutti quanti secondo me crysis cn questa cpu fa 5 fps al max perchè nn e ottimizzata per la grafica 3d...un po' come accade per il cell della ps3....molto potente come valori di picco ma poco adatta per le applicazioni ludiche. pero una cosa ma il cell non ha 200gigaflops di potenza??? (perdonate l'ignoranza)
Ps ance se centra poco con l'argomento in questione però secondo me l'architettura del cell è il futuro, ora è il 1 tentativo ed è andata come andata pero pensate all'idea innovativa 1 unica cpu in grado di fare tutto video audio calcoli e chi piu ne ha piu ne metta....mica male come idea...

ironia portami via, eh?

La questione delle architetture non la capisco molto onestamente sento spesso dire qui sul forum che x86 è peggio di ARM: a livello architettura fisica, instruction set o entrambi ??? Perchè ARM è più lento di x86 perchè non ha la stessa tecnologia produttiva e costruttiva che possono avere intel o AMD ?? Ovvero un ipotetico ARM quad-core fatto bene a 3,2ghz di clock si comporterebbe meglio rispetto ad un i7 x86 per semplificare immaginando di avere un programma scritto in C++ per direne uno, a parità di compliatore cosa è meglio ??? quali sono le istruzioni che ARM esegue meglio ??

P.S. OT ma visto che qualcuno ha tirato fuori le architetture mi sono sbizzarrito con le domande :D

La questione delle architetture non la capisco molto onestamente sento spesso dire qui sul forum che x86 è peggio di ARM: a livello architettura fisica, instruction set o entrambi ??? Perchè ARM è più lento di x86 perchè non ha la stessa tecnologia produttiva e costruttiva che possono avere intel o AMD ?? Ovvero un ipotetico ARM quad-core fatto bene a 3,2ghz di clock si comporterebbe meglio rispetto ad un i7 x86 per semplificare immaginando di avere un programma scritto in C++ per direne uno, a parità di compliatore cosa è meglio ??? quali sono le istruzioni che ARM esegue meglio ??

P.S. OT ma visto che qualcuno ha tirato fuori le architetture mi sono sbizzarrito con le domande :D

Chiudiamo quì la questione, un processore ARM quad-core fatto bene a 3,2ghz,
esistono già si chiamano Power:

http://www-03.ibm.com/systems/it/power/

il problema è che costano 6000€ a processore e il software deve essere appositamente scritto e tutto il parco software attuale dovremmo buttarlo nel cesso.

Chiudiamo quì la questione, un processore ARM quad-core fatto bene a 3,2ghz,
esistono già si chiamano Power:
http://www-03.ibm.com/systems/it/power/
il problema è che costano 6000€ a processore e il software deve essere appositamente scritto e tutto il parco software attuale dovremmo buttarlo nel cesso.
A me sembra che siano Power non ARM (anche se entrambi RISC) :p

Chiudiamo quì la questione, un processore ARM quad-core fatto bene a 3,2ghz,
esistono già si chiamano Power:

http://www-03.ibm.com/systems/it/power/

il problema è che costano 6000€ a processore e il software deve essere appositamente scritto e tutto il parco software attuale dovremmo buttarlo nel cesso.

si ma il problema è che un processore da 6000€ come quello serve per fare le cose che ci si fanno con quello...

è come dire che "se mettessimo un GT200b (chip nVidia per GPU) al posto del core2duo, andrebbe più piano o più veloce winzozz? cavolo le GPU hanno una potenza di calcolo impressionante!"... peccato che una GPU non esegue codice x86....

meglio o peggio dipende da cosa gli si fa fare

La questione delle architetture non la capisco molto onestamente sento spesso dire qui sul forum che x86 è peggio di ARM: a livello architettura fisica, instruction set o entrambi ??? Perchè ARM è più lento di x86 perchè non ha la stessa tecnologia produttiva e costruttiva che possono avere intel o AMD ?? Ovvero un ipotetico ARM quad-core fatto bene a 3,2ghz di clock si comporterebbe meglio rispetto ad un i7 x86 per semplificare immaginando di avere un programma scritto in C++ per direne uno, a parità di compliatore cosa è meglio ??? quali sono le istruzioni che ARM esegue meglio ??

P.S. OT ma visto che qualcuno ha tirato fuori le architetture mi sono sbizzarrito con le domande :D
x86 è un architettura cisc, arm e sparc sono risc. Le architetture risc sono sempre meglio delle CISC, ma meno versatili perché più difficile da modificare ed in genere più costose (gli sparc, itanium e powerpc costano molto).

Il vantaggio dell'architettura arm è che ha un set di istruzioni ridotto, e ogni istruzione ha una lunghezza fissa e un numero massimo di operandi. Un processore è quindi molto compatto e semplice ed è possibile dedicare i transistor espressamente per il calcolo e non per ottimizzazioni contorte o per complessi metodi di fetch delle istruzioni come avviene per l'x86.
Altro punto forte dell'architettura arm è la fusione delle istruzioni di salto con le istruzioni condizionali. Un innovazione che elimina di fatto il prediction fault e lo svuotamento della pipeline. Altra cosa che l'x86 si sogna e ahimé pure lo sparc, ma non l'itanium.

Confrontare il cell con questo processore è fuori luogo perché i Gigaflops del cell glie li forniscono le sue spe che non sono core generici ma processori vettoriali, vagamente simili a quelli presenti nelle gpu.

x86 è un architettura cisc, arm e sparc sono risc. Le architetture risc sono sempre meglio delle CISC, ma meno versatili perché più difficile da modificare ed in genere più costose (gli sparc, itanium e powerpc costano molto).

Il vantaggio dell'architettura arm è che ha un set di istruzioni ridotto, e ogni istruzione ha una lunghezza fissa e un numero massimo di operandi. Un processore è quindi molto compatto e semplice ed è possibile dedicare i transistor espressamente per il calcolo e non per ottimizzazioni contorte o per complessi metodi di fetch delle istruzioni come avviene per l'x86.
Altro punto forte dell'architettura arm è la fusione delle istruzioni di salto con le istruzioni condizionali. Un innovazione che elimina di fatto il prediction fault e lo svuotamento della pipeline. Altra cosa che l'x86 si sogna e ahimé pure lo sparc, ma non l'itanium.

Confrontare il cell con questo processore è fuori luogo perché i Gigaflops del cell glie li forniscono le sue spe che non sono core generici ma processori vettoriali, vagamente simili a quelli presenti nelle gpu.

in pratica è come dicevo io: siccome non centrano una pippa uno con l'altro fare confronti non ha molto senso!

sono d' accordo sul fatto che che bisogna buttare tutto quanto fatto addio software ecc ecc, ma ipotiziamo di scrivere un benchmark in un linguaggio ad alto livello lo compiliamo con due compilatori scritti in modo efficiente per entrambe le architetture x86 e ARM a parita di clock, numero di core, cache chi ne esce vincitore ?? Ovvero ARM è superiore in ogni campo ad x86 o c' è qualcosa che fa meglio e qualcosa che fa peggio e quindi dipende da cosa bisogna fare ??
Grazie :D

x86 è un architettura cisc, arm e sparc sono risc. Le architetture risc sono sempre meglio delle CISC, ma meno versatili perché più difficile da modificare ed in genere più costose (gli sparc, itanium e powerpc costano molto).

Il vantaggio dell'architettura arm è che ha un set di istruzioni ridotto, e ogni istruzione ha una lunghezza fissa e un numero massimo di operandi. Un processore è quindi molto compatto e semplice ed è possibile dedicare i transistor espressamente per il calcolo e non per ottimizzazioni contorte o per complessi metodi di fetch delle istruzioni come avviene per l'x86.
Altro punto forte dell'architettura arm è la fusione delle istruzioni di salto con le istruzioni condizionali. Un innovazione che elimina di fatto il prediction fault e lo svuotamento della pipeline. Altra cosa che l'x86 si sogna e ahimé pure lo sparc, ma non l'itanium.

Confrontare il cell con questo processore è fuori luogo perché i Gigaflops del cell glie li forniscono le sue spe che non sono core generici ma processori vettoriali, vagamente simili a quelli presenti nelle gpu.

ah ecco qua grazie mille quindi diciamo che il "segreto" sta nel RISC vado a leggermi in maniera più dettagliata come funziona GRAZIE !!!!:D


P.S. di Cell io non ho parlato eh..

ma gli xeon non avevano specifiche più performanti degli i7 oltre che ad essere anche pensati per ambito server? non è più sensato fare un paragone con quelli?

no, praticamente gli i7 e xeon partono dalla stessa architettua, solo che gli xeon supportano memorie ECC, cisono versioni che consumano meno e permettono di essere usati singoli o a gruppi, ma per il resto sono identici.

tra dieci anni questa cpu ce l avremo sui cellulari....


e tra 10 anni ci sarà ancora gente che fracassa i marroni con crysis:muro: :muro: :muro: :rolleyes: :rolleyes:

sono d' accordo sul fatto che che bisogna buttare tutto quanto fatto addio software ecc ecc, ma ipotiziamo di scrivere un benchmark in un linguaggio ad alto livello lo compiliamo con due compilatori scritti in modo efficiente per entrambe le architetture x86 e ARM a parita di clock, numero di core, cache chi ne esce vincitore ?? Ovvero ARM è superiore in ogni campo ad x86 o c' è qualcosa che fa meglio e qualcosa che fa peggio e quindi dipende da cosa bisogna fare ??
Grazie :D

più che a parità di clock andrebbe fatto a parità di watt. E verrà fatto a breve con i netbook con processori arm al posto degli atom. E già si preannuncia una vittoria schiacciante di arm.
Mi riservo un ultima frecciata ad x86:
intel l'ha scelto per larrabee per via della sua diffusione e blabla, il problema è che x86 è un architettura troppo complessa da implementare, vale a dire costosa. Intel rischia di ritrovarsi con processori eccessivamente grossi che non andranno molto più forte di quelli forniti dalla concorrenza, che con processori più piccoli e architetture dedicate andranno comunque forte. Per arginare un po' il problema intel ha scelto un vecchio pentium, l'ultimo con architettura in-order, sperando che fosse abbastanza piccolo da non portare eccessivi svantaggi sui costi complessivi. Tutti sti ritardi però mi fanno pensare che non sia bastato.
Anche perché alla fine i programmatori per avere la massima compatibilità continueranno a fare giochi in directx, opengl e opencl. Il valore aggiunto di x86 potrebbe rivelarsi inutile

ce lo ritroveremo su playstation 4... :D
ma 128 GFLOPS a singola precisione ? no perchè il cell ne fa 204,8 GFLOPS (teoricamente ) lavorando in singola precisione e circa 25 in doppia quindi se fosse in doppia è 5 volte + potente di un cell ? da non credere.

ragazzi mi sembra che abbiate poche idee ma confuse :D

come prima cosa confrontare una CPU pensata per il calcolo in virgola mobile con una CPU pensata per il general purpose (gli x86 in genere) è come confrontare un dragster con una station wagon. il primo va parecchio di più della seconda ma con la seconda fai di tutto mentre invece con il primo più che le gare di accelerazione non puoi fare.

detto questo i numeri folli quando si tratta di architetture specificatamente pensate per macinare GFLOPS non fanno particolare impressione, basti ricordare come ben ha detto qualcuno il cell, che tra l'altro viene impiegato come COPROCESSORE in architetture x86 (server opteron). se poi vogliamo anche scomodare le GPU ricordo che ormai la loro potenza si misura in TERAflops quindi ci sarebbe da aprire un capitolo a parte.

aggiungo che i numeri folli poi bisogna anche capirli perchè i flops se si parla di precisione singola sono una cosa, se si parla di precisione doppia sono un'altra (suppongo si parli di doppia altrimenti non farebbe così notizia).

in ogni caso tecnicamente è enormemente più complesso aumentare l'efficienza IPC (instruction per clock) di un x86 (come nel passaggio da core 2 a i7) piuttosto che spremere gflops su gflops, dato che per questi basta aumentare il numero di unità dedicate fino a raggiungere il totale desiderato. non a caso tutte le architetture che spingono sui gflops hanno decine se non centinaia di unità ad essi dedicate che fanno questo in parallelo.

riassumo quanto detto in: si, sarà anche il più veloce del mondo ma a svolgere un compito specifico. nel general purpose gli x86 sono difficili da battere.

e qui apro un'altra parentesi su chi tira regolarmente merda sugli x86. sono dei processori MOLTO performanti nell'ambito in cui operano, ovvero il general purpose, tant'è che a livello di numeri gli x86 danno del bel filo da torcere ai vari Itanium 2 e POWER6. gli x86 è da parecchio che detengono il primato come processori general purpose più performanti; giusto i processori da mainframe ogni tanto si fanno vedere ma non c'è ARM o powerpc che regga il confronto. anche ai tempi quando apple sponsorizzava i powerpc tirava fuori tutti i numeri di programmi e bench che sfruttavano altivec, ovvero un'unità di calcolo parallelo di cui erano dotati i powerpc, ma sul general purpose erano comunque indietro.

non a caso quando c'è stato lo switch i numeri tirati fuori dalla stessa apple erano incredibili (più veloce del 400%, del 500% o anche più).

infine ricorderei che gli x86 moderni (dal pentium in poi, quindi è qualche annetto, aggiornatevi) internamente sono dei RISC anche se hanno mantenuto per ovvie ragioni il set di istruzioni CISC... la differenza con un RISC puro è semplicemente la presenza di un traduttore che traduce le istruzioni x86 in microistruzioni RISC prima di darle in pasto al core... ergo inutile fare confronti con ARM e powerpc. gli arm vanno bene dove servono basse performance e consumi ancor più bassi, i powerpc nei sistemi embedded e gli x86 sui computer, dai netbook ai server (fino a quelli di una certa dimensione, poi ovviamente ci sono itanium e POWER)...

spero di aver chiarito un po' di idee =)

Vorrei fare notare che una banale GPU RV770 (quella montata su ATI Radeon HD 4870), utilizzata opportunamente, processa 1.2 TeraFlops, vale a dire circa 10 volte di più di uno di questi processori, costando probabilmente solo una piccola frazione.
Dico questo solo per coloro che non conoscono la differenza tra una GPU e una CPU.

ma due centimetri qudrati di die??
e poi ridotto a un terzo il consumo...rispetto a cosa???

sono d' accordo sul fatto che che bisogna buttare tutto quanto fatto addio software ecc ecc, ma ipotiziamo di scrivere un benchmark in un linguaggio ad alto livello lo compiliamo con due compilatori scritti in modo efficiente per entrambe le architetture x86 e ARM a parita di clock, numero di core, cache chi ne esce vincitore ?? Ovvero ARM è superiore in ogni campo ad x86 o c' è qualcosa che fa meglio e qualcosa che fa peggio e quindi dipende da cosa bisogna fare ??
Grazie :D

Gli ARM oggi in commercio sono processori ottimizzati per costi e consumi, non per le prestazioni pure. Quindi il confronto non si pone.

Però, come da esempi citati, se un processore RISC è sviluppato per ottenere prestazioni pure, come questo SPARC o i POWER IBM, può ancora stracciare tranquillamente gli x86, anche se Intel ha dalla sua fonderie allo stato dell'arte e risorse quasi illimitate per lo sviluppo dei suoi microprocessori.
Però Intel ha anche dalla sua l'ECONOMIA DI SCALA. Quindi questi RISC allo stato dell'arte non possono comunque competere a livello di costi produttivi (e quindi per l'utente).

ma che bel bestiolo...

http://img33.imageshack.us/img33/2782/venusviii.jpg (http://img33.imageshack.us/my.php?image=venusviii.jpg)


@ FX .... ottima spegazione!

Come hanno scritto su altri siti...ma il Cell non faceva gli stessi gigaflop o anche meglio?

probabilmente questi sono riferiti ad operazioni a doppia precisione (64bit)

Scusate ma Gigaflop sta per fiasco gigantesco?

Scusate ma Gigaflop sta per fiasco gigantesco?

edit avevo letto male

ci gira crysis? ahahha

Gran bel post, FX, grazie per la spiegazione!

A questo punto, però, mi hai fatto venire una curiosità: le istruzioni che hanno aggiunto nel corso degli anni, come MMX, SSE, ecc, come si inseriscono nel discorso? Intendo dire: i processori di oggi, come hai detto, sono RISC preceduti da un traduttore che si occupa di spezzare le istruzioni CISC in RISC. Mi viene da pensare allora che sarebbe meglio se un compilatore utilizzasse direttamente istruzioni RISC, e se le CISC venissero usate solo dai vecchi programmi (sbaglio?). Se è così, supportare delle istruzioni aggiuntive non è un controsenso (nel senso: lavoro extra per il traduttore da CISC a RISC)?

Perdonami se ho detto idiozie ma sono un profano in materia... Come dicevi tu, poche idee ma confuse! :-D

Grazie della chiarissima spiegazione. Per chi come me ne capisce poco... servono interventi così. :)


Anche se dai, potevi almeno citare 1 votla Crysis :asd:

@FX: mitico!!!
gran bella cpu, chissà in OC se spinge.... a quando il "sotto azoto"?

A questo punto, però, mi hai fatto venire una curiosità: le istruzioni che hanno aggiunto nel corso degli anni, come MMX, SSE, ecc, come si inseriscono nel discorso? Intendo dire: i processori di oggi, come hai detto, sono RISC preceduti da un traduttore che si occupa di spezzare le istruzioni CISC in RISC. Mi viene da pensare allora che sarebbe meglio se un compilatore utilizzasse direttamente istruzioni RISC, e se le CISC venissero usate solo dai vecchi programmi (sbaglio?). Se è così, supportare delle istruzioni aggiuntive non è un controsenso (nel senso: lavoro extra per il traduttore da CISC a RISC)?

Ma MMX, SSE e successive sono un discorso a parte dato che sono estensioni SIMD (single instruction multiple data) della cpu, per fare alcuni calcoli sono immensamente più veloci delle normali istruzioni x86 perché possono appunto processare più dati per volta.

E se i compilatori utilizzassero direttamente le istruzioni RISC (e i processori attuali non possono mica saltare la fase di traduzione) il programma risultare non sarebbe più x86, e allora a quel caso tanto valeva cambiare set di istruzioni anni fa, non è stato fatto per garantire la retrocompatibilità dei programmi con i vecchi processori.
Ovviamente se si potesse sarebbe estremamente conveniente, avremmo processori più veloci (ma non di tantissimo) e soprattutto con consumi meno elevati.
Ma per ragione di retrocompatibilità questo passaggio non si è stato fatto e non credo certo si farà nell'immediato futuro.

P.S. Questa CPU ancora in fase di prototipazione da 128Gflops comunque non mi pare così sorprendente, il POWER7 che è in fase di sviluppo si prevede avrà 256Glops, esattamente il doppio, e dovrebbe essere prevista per il 2010.

x86 è un architettura cisc, arm e sparc sono risc. Le architetture risc sono sempre meglio delle CISC, ma meno versatili perché più difficile da modificare ed in genere più costose (gli sparc, itanium e powerpc costano molto).

Il vantaggio dell'architettura arm è che ha un set di istruzioni ridotto, e ogni istruzione ha una lunghezza fissa e un numero massimo di operandi. Un processore è quindi molto compatto e semplice ed è possibile dedicare i transistor espressamente per il calcolo e non per ottimizzazioni contorte o per complessi metodi di fetch delle istruzioni come avviene per l'x86.
Altro punto forte dell'architettura arm è la fusione delle istruzioni di salto con le istruzioni condizionali. Un innovazione che elimina di fatto il prediction fault e lo svuotamento della pipeline. Altra cosa che l'x86 si sogna e ahimé pure lo sparc, ma non l'itanium.

Confrontare il cell con questo processore è fuori luogo perché i Gigaflops del cell glie li forniscono le sue spe che non sono core generici ma processori vettoriali, vagamente simili a quelli presenti nelle gpu.
Costano molto perchè i prezzi sono tenuti artificialmente alti dalle "velleità server" che hanno. In realtà costano di meno, e sono meno difficili da modificare proprio in quanto reduced instruction set.
I RISC general purpose (come power e ARM) fanno affidamento sulla bontà del compilatore per performare in modo decnete. Il compilatore si aggiorna ad ogni versione e cambiarlo è uno scherzo.
Gli x86, in quanto complex, ottimizzano pesantemente in hardware codici di tutti i tipi, cosa che gli costa un certo numero di transistor. In pratica il software generato dal compilatore fa 2-3 passaggi prima di diventare realmete linguaggio macchina comprensibile a quel processore. Non a caso esistono compilatori ottimizzati x86 Intel e AMD e quant'altro proprio perchè le due marche hanno diversi tipi di ottimizzatori interni. È una schifezza assurda e un controsenso totale, e andrebbero cestinati al più presto, ma grazie al grip di intel sul mercato, questo non è possibile.

Per la serie si faccia una domanda e si dia una risposta :asd:

Imho una gpu mi fà tanto fuzzy flops.. :asd:
e in questo caso si fà presto ad estremizzare le prestazioni.. ;)

I RISC general purpose (come power e ARM) fanno affidamento sulla bontà del compilatore per performare in modo decnete. Il compilatore si aggiorna ad ogni versione e cambiarlo è uno scherzo.
Gli x86, in quanto complex, ottimizzano pesantemente in hardware codici di tutti i tipi, cosa che gli costa un certo numero di transistor. In pratica il software generato dal compilatore fa 2-3 passaggi prima di diventare realmete linguaggio macchina comprensibile a quel processore. Non a caso esistono compilatori ottimizzati x86 Intel e AMD e quant'altro proprio perchè le due marche hanno diversi tipi di ottimizzatori interni. È una schifezza assurda e un controsenso totale, e andrebbero cestinati al più presto, ma grazie al grip di intel sul mercato, questo non è possibile.

Infatti per me il futuro è nei compilatori JIT (http://en.wikipedia.org/wiki/Just-in-time_compilation).
Così si può ottimizzare il codice per il SINGOLO processore, o anche processori diversi, mantenendo un UNICO binario (bitcode (http://llvm.org/docs/BitCodeFormat.html), più propriamente).
Sono curioso di vedere se la Apple con SnowLeopard finalmente implementerà questa cosa, visto che il compilatore che lo può fare ormai ce l'hanno pronto (LLVM (http://llvm.org/)).

A quel punto Intel, ARM, PowerPC o Sparc sarà lo stesso. E di nuovo potrà vincere l'architettura VERAMENTE migliore, non quella più diffusa... per il solo motivo di essere diffusa (avere più software). Vedi x86.

Vorrei fare notare che una banale GPU RV770 (quella montata su ATI Radeon HD 4870), utilizzata opportunamente, processa 1.2 TeraFlops, vale a dire circa 10 volte di più di uno di questi processori, costando probabilmente solo una piccola frazione.
Dico questo solo per coloro che non conoscono la differenza tra una GPU e una CPU.

la gpu lìho tirata in ballo proprio per dire che ogni "processore" va misurato sul suo scopo. le gpu si misurano in teraflops, ma probabilmente se "capissero" l'x86 windows magari andrebbe lentissimo, nonostante i teraflops!

Complimenti a FX che ha fatto capire il concetto giusto

A questo punto, però, mi hai fatto venire una curiosità: le istruzioni che hanno aggiunto nel corso degli anni, come MMX, SSE, ecc, come si inseriscono nel discorso? Intendo dire: i processori di oggi, come hai detto, sono RISC preceduti da un traduttore che si occupa di spezzare le istruzioni CISC in RISC. Mi viene da pensare allora che sarebbe meglio se un compilatore utilizzasse direttamente istruzioni RISC, e se le CISC venissero usate solo dai vecchi programmi (sbaglio?). Se è così, supportare delle istruzioni aggiuntive non è un controsenso (nel senso: lavoro extra per il traduttore da CISC a RISC)?

Ci sono fondamentalmente 3 motivi:
1. retrocompatibilita' coi vecchi programmi
2. retrocompatibilita' coi vecchi programmi
3. retrocompatibilita' coi vecchi programmi
:)

Il problema e' questo: se cambi ISA, non puoi piu' far girare i vecchi programmi (a meno di non avere un qualche meccanismo di Dynamic Binary Translation). Questo puo' essere un problema gestibile per piattaforme embedded, perche':
1. la gente che scrive quei programmi e' (relativamente) poca ed e' pagata dalle loro aziende proprio per fare quello
2. minimizzare il consumo energetico e i costi e' una priorita' assoluta

Per il codice x86 e' piu' difficile... ci sono svariati miliardi di righe di codice la' fuori (dai sistemi operativi ai driver, a ogni genere di applicativi, videogiochi... e ogni cosa), scritte da (decine di) milioni di persone. Dovresti:
1. progettare una nuova ISA o adottarne un'altra gia' esistente (e qui inizierebbero guerre di religione e spargimenti di sangue... la guerra CISC vs RISC c'e' gia' stata, nel mondo accademico, negli anni '80, e non ha vinto nessuno: nessuna delle due filosofie "nuda e pura" e' vincente, ognuna ha dei benifici e dei costi)
2. scrivere/riscrivere tutti i compilatori, e riottimizzarli: quanti anni ci vorrebbero?
3. ricompilare tutti i miliardi di linee di codice di cui sopra, e guardare come crashano in allegria; riesaminare, ridebuggare, ricompilare, riottimizzare ecc. ogni programma esistente

Come vedi, e' follia completa. L'x86 ha vinto anni fa, e restera' qui per mooolto tempo.

Come diceva FX, la cosa non e' drammatica. Innanzitutto, non e' affatto vero che RISC e' meglio di CISC "in assoluto". Dipende da cosa devi fare, dall'applicativo, dall'ambito di utilizzo. In embedded, si' (o forse e' meglio VLIW? o forse e' meglio un processore vettoriale? Tutti approcci usati, la' dove possono dare il meglio di se').
Secondo, i processori x86, almeno dai tempi del PII, hanno un front-end che macina l'ISA x86 e la trasforma in un'altra ISA interna (in realta' parte di questo meccanismo e' stato anche spostato, alle volte, nella gerarchia di memoria, ad es. nell'interfaccia tra la L2 e la L1-I). Questa ISA interna e' quasi RISC... o meglio, e' load/store (e qualcos'altro). Ma le istruzioni non vengono solo spezzate, ma anche fuse insieme... insomma, non e' certo un RISC come veniva inteso negli anni '80.

D'altro canto, nemmeno i PowerPC usano una ISA puramente RISC: la R sta per "Reduced", cioe' l'idea di avere poche istruzioni (meno di 100, contro le svariate centinaia dell'x86, per dire). E quella non e' stata un'idea vincente: una RISC si oggi puo' tranquillamente avere 2-300 istruzioni... insomma, e' abbastanza complicato :)


Per quel che riguarda MMX ed SSE: ad una ISA non puoi _mai_togliere isctruzioni, se no i vecchi programmi che le usano non girano piu'. Ma puoi aggiungerle... ed ecco nascere tutte quelle estensioni, perlopiu' ridicole scimmiottature di istruzioni vettoriali... ma stanno diventando meglio :) (Larrabee mi sembra avere un'ISA vettoriale piuttosto pulita)

Ci sono fondamentalmente 3 motivi:
1. retrocompatibilita' coi vecchi programmi
2. retrocompatibilita' coi vecchi programmi
3. retrocompatibilita' coi vecchi programmi
:)

Il problema e' questo: se cambi ISA, non puoi piu' far girare i vecchi programmi (a meno di non avere un qualche meccanismo di Dynamic Binary Translation). Questo puo' essere un problema gestibile per piattaforme embedded, perche':
1. la gente che scrive quei programmi e' (relativamente) poca ed e' pagata dalle loro aziende proprio per fare quello
2. minimizzare il consumo energetico e i costi e' una priorita' assoluta

Per il codice x86 e' piu' difficile... ci sono svariati miliardi di righe di codice la' fuori (dai sistemi operativi ai driver, a ogni genere di applicativi, videogiochi... e ogni cosa), scritte da (decine di) milioni di persone. Dovresti:
1. progettare una nuova ISA o adottarne un'altra gia' esistente (e qui inizierebbero guerre di religione e spargimenti di sangue... la guerra CISC vs RISC c'e' gia' stata, nel mondo accademico, negli anni '80, e non ha vinto nessuno: nessuna delle due filosofie "nuda e pura" e' vincente, ognuna ha dei benifici e dei costi)
2. scrivere/riscrivere tutti i compilatori, e riottimizzarli: quanti anni ci vorrebbero?
3. ricompilare tutti i miliardi di linee di codice di cui sopra, e guardare come crashano in allegria; riesaminare, ridebuggare, ricompilare, riottimizzare ecc. ogni programma esistente

Come vedi, e' follia completa. L'x86 ha vinto anni fa, e restera' qui per mooolto tempo.

Come diceva FX, la cosa non e' drammatica. Innanzitutto, non e' affatto vero che RISC e' meglio di CISC "in assoluto". Dipende da cosa devi fare, dall'applicativo, dall'ambito di utilizzo. In embedded, si' (o forse e' meglio VLIW? o forse e' meglio un processore vettoriale? Tutti approcci usati, la' dove possono dare il meglio di se').
Secondo, i processori x86, almeno dai tempi del PII, hanno un front-end che macina l'ISA x86 e la trasforma in un'altra ISA interna (in realta' parte di questo meccanismo e' stato anche spostato, alle volte, nella gerarchia di memoria, ad es. nell'interfaccia tra la L2 e la L1-I). Questa ISA interna e' quasi RISC... o meglio, e' load/store (e qualcos'altro). Ma le istruzioni non vengono solo spezzate, ma anche fuse insieme... insomma, non e' certo un RISC come veniva inteso negli anni '80.

D'altro canto, nemmeno i PowerPC usano una ISA puramente RISC: la R sta per "Reduced", cioe' l'idea di avere poche istruzioni (meno di 100, contro le svariate centinaia dell'x86, per dire). E quella non e' stata un'idea vincente: una RISC si oggi puo' tranquillamente avere 2-300 istruzioni... insomma, e' abbastanza complicato :)


Per quel che riguarda MMX ed SSE: ad una ISA non puoi _mai_togliere isctruzioni, se no i vecchi programmi che le usano non girano piu'. Ma puoi aggiungerle... ed ecco nascere tutte quelle estensioni, perlopiu' ridicole scimmiottature di istruzioni vettoriali... ma stanno diventando meglio :) (Larrabee mi sembra avere un'ISA vettoriale piuttosto pulita)

complimenti... che lavoro fai per curiosità? non sono informazioni che leggi su wiki e le metti insieme a caso.

Visto che si sta parlando di certe cose..... ora capite l'importanza dell'opensource, nel senso della facilità con cui si porta un'applicazione da una cpu a un'altra(debian suporta 11 architetture, + altre sperimentalmente).
Con l'opensource, molti di questi problemi non ci sono, non c'è il problema della compatibilità dei processori. Infatti quando sono usciti i 64bit le distro linux sono state le prime ad offrire OS+applicazioni in pochissimo tempo.
Poi non capisco perchè le softwarehouse non compilano per altre architetture. Per come siamo messi non possiamo cambiare architettura non pre motivi tecnologici, ma per motivi commerciali. Itanium di intel non è stato un flop come processore, ma all'inizio se ricordate intel voleva che itanium sostituisse gli x86 tanto che all'inizio diceva che in futuro itanium sarebbe arrivato anche sui portatili. MS ha fatto windows per itanium, ma poi nessuno ci ha fatto le applicazioni.

Ripeto, capite che con l'opensource ci sarebbe mercato per ogni CPU, e per ogni milgioria tecnologica in ambito CPU dove si è frenati dalla compatibilità

Visto che si sta parlando di certe cose..... ora capite l'importanza dell'opensource, nel senso della facilità con cui si porta un'applicazione da una cpu a un'altra(debian suporta 11 architetture, + altre sperimentalmente).
Con l'opensource, molti di questi problemi non ci sono, non c'è il problema della compatibilità dei processori. Infatti quando sono usciti i 64bit le distro linux sono state le prime ad offrire OS+applicazioni in pochissimo tempo.

Ma distribuire i software come sorgente non è il massimo, per 3 motivi:

1. Non è un modo esattamente veloce ed elegante per l'utente
2. Non tutti hanno piacere a rendere leggibili da tutti i propri sorgenti
3. Devi avere il compilatore e le librerie della versione giusta per compilare il software

Molto meglio un approccio con bitcode, come detto sopra.

Visto che si sta parlando di certe cose..... ora capite l'importanza dell'opensource, nel senso della facilità con cui si porta un'applicazione da una cpu a un'altra(debian suporta 11 architetture, + altre sperimentalmente).
Con l'opensource, molti di questi problemi non ci sono, non c'è il problema della compatibilità dei processori. Infatti quando sono usciti i 64bit le distro linux sono state le prime ad offrire OS+applicazioni in pochissimo tempo.
Poi non capisco perchè le softwarehouse non compilano per altre architetture. Per come siamo messi non possiamo cambiare architettura non pre motivi tecnologici, ma per motivi commerciali. Itanium di intel non è stato un flop come processore, ma all'inizio se ricordate intel voleva che itanium sostituisse gli x86 tanto che all'inizio diceva che in futuro itanium sarebbe arrivato anche sui portatili. MS ha fatto windows per itanium, ma poi nessuno ci ha fatto le applicazioni.

Ripeto, capite che con l'opensource ci sarebbe mercato per ogni CPU, e per ogni milgioria tecnologica in ambito CPU dove si è frenati dalla compatibilità

si e le software house di cosa vivono? non tutte possono fare software gratis! io personalmente compilerei anche in vbcjx86paperino, ma io programmo software gestionali in c#, vb.net e se microsoft non mi fa il compilatore... niente software! attualmente l'unica sarebbe sviluppare tutti in java!

Visto che si sta parlando di certe cose..... ora capite l'importanza dell'opensource, nel senso della facilità con cui si porta un'applicazione da una cpu a un'altra(debian suporta 11 architetture, + altre sperimentalmente).
Con l'opensource, molti di questi problemi non ci sono, non c'è il problema della compatibilità dei processori.

Scusa, ma e' un discorso fuffa. Debian supporta quelle architetture perche' ha deciso cosi'. Se Microsoft volesse, potrebbe scrivere l'OS che vuole per l'architettura che vuole -- non lo fa perche' non le conviene. Fine.
Se per assurdo domani x86 scomparisse per essere rimpiazzata da una nuova ISA, tutti dovrebbero risviluppare tutto il software, e non sarebbe bello per nessuno.





Poi non capisco perchè le softwarehouse non compilano per altre architetture. Per come siamo messi non possiamo cambiare architettura non pre motivi tecnologici, ma per motivi commerciali.

I miliardi di dollari e gli anni necessari per ricompilare e ritestare tutto il software li paghi tu?
E come e' gia' stato detto, non ce n'e' veramente bisogno. Cambiare architettura non migliorerebbe le cose di molto dal punto di vista prestazionale, ed esigerebbe un costo enorme.



Itanium di intel non è stato un flop come processore, ma all'inizio se ricordate intel voleva che itanium sostituisse gli x86 tanto che all'inizio diceva che in futuro itanium sarebbe arrivato anche sui portatili. MS ha fatto windows per itanium, ma poi nessuno ci ha fatto le applicazioni.


Diciamo anche che l'architettura EPIC non e' cosi' power come sembrava potesse essere all'inizio (per dare un'idea: Hennessy & Patterson, in una delle loro bibbie nell'architettura dei computer, hanno spostato VLIW dal capitolo 4 all'appendice G tra la terza e la quarta edizione...)
E' esattamente quello che dicevo prima: nuova architettura (diversissima), han dovuto scrivere i compilatori (difficilissimi per VLIW), riscrivere i programmi, eccetera... nel frattempo, le microarchitetture standard x86 sono andate avanti cosi' tanto da mangiarsi buona parte dei vantaggi della nuova architettura.

complimenti... che lavoro fai per curiosità? non sono informazioni che leggi su wiki e le metti insieme a caso.

Lavoro? Nessuno :D

Seriamente: ho lavorato un pochino (1.5 anni) alla ST come Digital ASIC Designer, poi ho fatto lo zompo e sono emigrato nella Silicon Valley (a Stanford): al momento sto lavorando al mio master EE, specializzazione Computer Architecture & VLSI Design.
La speranza era trovare lavoro qui (AMD, Intel, NVidia, Sun... sono tutte nel raggio di 30 minuti di macchina). Ho anche un paio di contatti all'interno, purtroppo la crisi ha colpito anche qui e sono tutte in hiring freeze.
Si vedra'!

per me ci fanno girare crysis in macchina virtuale in modalità full software rendered... che dite, così ce la fa a girare decentemente? :D :D :D :D :DQuesta CPU fa 128GFlops, poco più di una 8600GT (114GFLops)
Per me Crysis girerebbe male :o)

Infatti per me il futuro è nei compilatori JIT (http://en.wikipedia.org/wiki/Just-in-time_compilation).
Così si può ottimizzare il codice per il SINGOLO processore, o anche processori diversi, mantenendo un UNICO binario (bitcode (http://llvm.org/docs/BitCodeFormat.html), più propriamente).
Sono curioso di vedere se la Apple con SnowLeopard finalmente implementerà questa cosa, visto che il compilatore che lo può fare ormai ce l'hanno pronto (LLVM (http://llvm.org/)).

A quel punto Intel, ARM, PowerPC o Sparc sarà lo stesso. E di nuovo potrà vincere l'architettura VERAMENTE migliore, non quella più diffusa... per il solo motivo di essere diffusa (avere più software). Vedi x86.

Java e NET/Mono non lo fanno già?
Il problema è che col JIT ti "reverse-engineerano" il codice che è una bellezza...

Grazie mille a Sapo84 e a Pleg per le spiegazioni! :)

Mi avete fatto capire che ero abbastanza fuori strada... Comunque cerco di farvi capire meglio la mia idea sull'argomento (che, ripeto, è quella di un profano, e quindi sbagliata!).

Supponiamo che un CISC supporti le istruzioni "aggiungi 1 a quella variabile" e "aggiungi 2 a quella variabile", quindi +1 e +2, mentre un RISC supporti solo la prima. Stando così le cose, si può adottare questo approccio: il processore è di fatto un RISC che supporta solo +1, preceduto da un'unità che converte ogni istruzione +2 in 2 successive +1. A quel punto un compilatore potrebbe prendere atto della situazione e usare direttamente 2 istruzioni +1, rendendo quindi inutile la traduzione preliminare, che resterebbe comunque disponibile per garantire la retrocompatibilità. Quello che ho detto può avere senso solo a patto che 1) il set di istruzioni RISC sia esattamente un sottoinsieme di quelle CISC: alcune in meno, nessuna in più, e nessuna differenza (tipo: se l'istruzione CISC si chiama +1, quella capita dal processore RISC deve essere ancora +1, non ++, altrimenti non funziona!); 2) la traduzione da CISC a RISC può essere evitata (risparmiando tempo!) se l'istruzione da eseguire è già una di quelle nativamente capite dal processore (per esempio, la +1).
In sostanza, l'idea sarebbe quella di mantenere questa unità di conversione CISC->RISC integrata nel processore, per motivi di compatibilità, ma allo stesso tempo di demandare dove possibile (cioè nei programmi moderni) questa operazione ai compilatori, in modo da sgravare la CPU. Come dire: se il programma è vecchio usiamo la conversione fatta dall'hardware, se invece il programma è nuovo, compilato in maniera accorta, è già pronto per essere eseguito così com'è direttamente dalla parte RISC. Però la frase
Secondo, i processori x86, almeno dai tempi del PII, hanno un front-end che macina l'ISA x86 e la trasforma in un'altra ISA interna
mi fa capire che questo non è possibile, perché l'ISA usata internamente dalla CPU è di fatto diversa dalla x86, e quindi non può essere il compilatore a generare istruzioni relative a quell'ISA, perché se anche questo fosse possibile (mettendo un front-end che capisce se le istruzioni che arrivano sono già dell'ISA interna o se sono x86, quindi ancora da convertire) finirebbero per funzionare solo su quella generazione di processori (per esempio i Pentium 2), ma se nella generazione successiva di processori i progettisti dovessero decidere di modificare l'ISA interna (perché ne hanno trovata una più efficiente) già non funzionerebbe più.

Dopodiché, il mio dubbio su MMX, SSE, ecc era in questo senso: partendo dal presupposto (sbagliato) che l'ISA interna sia un sottoinsieme della ISA esterna, quindi un sottoinsieme di x86, perché mai, dopo tutto questo sforzo per ridurre l'ISA interna, dovremmo andare ad aggiungere il supporto hardware ad altre istruzioni? Però ora mi rendo conto che 1) Le cose non funzionavano come pensavo, visto che l'ISA interna non è solo una riduzione di quella esterna ma è proprio diversa, e come mi ha detto anche Sapo84 i processori attuali non possono saltare la fase di traduzione; 2) da quel che ho capito dalla risposta di Sapo84, MMX & co. hanno una funzione diversa, elaborano più dati alla volta, quindi non è una "inversione di tendenza" nel tornare da RISC a CISC (che è quello che credevo io!), bensì si tratta di andare a coprire una funzionalità altrimenti non presente.

Bene, spero di avere spiegato cosa intendevo (erroneamente) e di avere capito. Comunque ancora grazie mille per le vostre spiegazioni! :)

Supponiamo che un CISC supporti le istruzioni "aggiungi 1 a quella variabile" e "aggiungi 2 a quella variabile", [cut] per motivi di compatibilità, ma allo stesso tempo di demandare dove possibile (cioè nei programmi moderni) questa operazione ai compilatori, in modo da sgravare la CPU. Come dire: se il programma è vecchio usiamo la conversione fatta dall'hardware, se invece il programma è nuovo, compilato in maniera accorta, è già pronto per essere eseguito così com'è direttamente dalla parte RISC.

L'idea generale non e' cosi' sbagliata: x86 ha delle istruzioni molto lunghe e complesse (credo che ce ne siano da 17 byte, confermate?) che magari venivano usate una volta, e adesso meno. Cioe', un compilatore moderno "sa" che istruzioni lunghe e complicate sono inefficienti, e potrebbe sostituirle con altre piu' semplici, se decide che eseguire ad es. 3 istruzioni semplici sia piu' veloce che eseguirne una complessa (che fa lo stesso lavoro).
Per far questo pero' devi avere ben chiara la microarchitettura, e devi generare codice ottimizzato per quella microarchitettura (ad es. lo switch -march del gcc fa questo: gli stai dando delle informazioni precise su per quale microarchitettura ottimizzare).


non può essere il compilatore a generare istruzioni relative a quell'ISA, perché se anche questo fosse possibile (mettendo un front-end che capisce se le istruzioni che arrivano sono già dell'ISA interna o se sono x86, quindi ancora da convertire) finirebbero per funzionare solo su quella generazione di processori (per esempio i Pentium 2), ma se nella generazione successiva di processori i progettisti dovessero decidere di modificare l'ISA interna (perché ne hanno trovata una più efficiente) già non funzionerebbe più.

Esatto. L'ISA e' il "contratto" tra l'hardware e il software, che non deve essere violato (se no i programmi non girano piu'). Quella si chiama "architettura".
Piu' sotto abbiamo altri due livelli: la "microarchitettura", che e' l'implementazione dell'ISA (cioe' l'organizazzione interna del processore, che cambia di generazione in generazione per diventare piu' efficiente, ma sempre implementando l'ISA, cioe' rispettando il "contratto"). Ed infine la "implementazione", cioe' la realizzazione circuitale vera e propria della microarchitettura.

Con questa CPU forse VISTA gira decentemente...

ma la precedente cpu citata è l'i7 ma non sarebbe il power6??
ok ho controlla to son li li come prestazioni, l'i7 è più efficente però :D

fanculo ai babbei che postano LE SOLITE CAZZATE

Con questa CPU forse VISTA gira decentemente...

compratela così non rimpi più e riesci a gocare a campo minato per bene.

ma la precedente cpu citata è l'i7 ma non sarebbe il power6??
ok ho controlla to son li li come prestazioni, l'i7 è più efficente però :D

fanculo ai babbei che postano LE SOLITE CAZZATE

tanti saluti anche a lei e la prossima volta moderi i termini

4 giorni

.............anche ai tempi quando apple sponsorizzava i powerpc tirava fuori tutti i numeri di programmi e bench che sfruttavano altivec, ovvero un'unità di calcolo parallelo di cui erano dotati i powerpc, ma sul general purpose erano comunque indietro.

non a caso quando c'è stato lo switch i numeri tirati fuori dalla stessa apple erano incredibili (più veloce del 400%, del 500% o anche più).............


anche io ricordo molto bene questa cosa ........ peccato che non riesca piu' a trovare i link in cui qualcuno aveva confrontato i dati del sito apple subito prima e subito dopo la migrazione ........

mica hai qualcosa in merito?

Con questa CPU forse VISTA gira decentemente...

veramente l'installalzione di vista su questa cpu non parte neanche...

windows funziona solo su x86 e x86_64

questa cpu ha una architettura SPARC64.

gli unici che potrebbero girarci e che mi vengono in mente sono linux (debian),

solaris, netbsd

Insomma, alla fin fine per risolvere i problemi di evoluzione del software, che castrano l'evoluzione dell'hardware dovremmo aspettare l'arrivo della singolarità, quando la macchina si scriverà da sola il codice... :asd:

Con questa CPU forse VISTA gira decentemente...

* a che pro questi post? :fagiano:

* a che pro questi post? :fagiano:

facile: uno non legge nulla + non sa niente dell'argomento + ama lamentarsi = post di questo genere

Comunque veramente interessante questo discorso, io ho sempre pensato che processori che usiamo noi fossero dei rics e che i cisc non li producesse più nessuno per la semplice regola "basta fare più istruzioni rics per avere un istruzione cisc", ma io di queste cose ci capisco veramente poco anzi massima stima per pleg.

E un bel "chi se ne frega" non lo vogliamo aggiungere?

Vorrei fare notare che una banale GPU RV770 (quella montata su ATI Radeon HD 4870), utilizzata opportunamente, processa 1.2 TeraFlops, vale a dire circa 10 volte di più di uno di questi processori, costando probabilmente solo una piccola frazione.[...]1) Io di "banale" in una GPU come RV770 non ci vedo assolutamente nulla... A meno che per te non sia "banale" l'architettura di una moderna GPU di fascia alta dotata di 956 milioni di transistor... Siamo quasi a quota 1 miliardo... Invece le nVidia GTX il miliardo di transistor l'hanno pure superato di un bel po'... :stordita:

2) La GPU è un pezzo di hardware creato per effettuare rendering in real-time. La CPU è un'unità di elaborazione general-purpose. Il confronto fra CPU e GPU, allo stato attuale, può essere considerato soltanto come "una nota di colore" in un articolo (o in un proclamo di superiorità di un produttore di una console rispetto ad un'altra...).

anche io ricordo molto bene questa cosa ........ peccato che non riesca piu' a trovare i link in cui qualcuno aveva confrontato i dati del sito apple subito prima e subito dopo la migrazione ........

mica hai qualcosa in merito?

Beh, certo. "Fino al 500%" ha un significato profondo. Significa "Se va bene questi sono il doppio di un G5, ma per fare numeri grandi includiamo nel calcolo quei residuati antebellici dei G4". Personalmente avevo fatto un test di codifica video (ed altra fuffa con un benchmark poco affidabile, lol) tra i vari Mac che avevo a disposizione.
Il link al mio test è http://eatsushi.org/comments.php?id=201 ma avviso che il sito è abbastanza NSFW in ogni altro punto.
Per amor di sintesi: un file video di 24 minuti e 29 secondi compresso con le stesse impostazioni e lo stesso programma (eh beh :P ) richiedeva 23 minuti e 5 secondi per un G4 da 1.2ghz e solo 10 minuti e 13 secondi per un Core Solo da 1.5ghz. Casualità, entrambe le configurazioni erano il minimo possibile come prestazioni al momento dell'aquisto, e concettualmente equivalenti. Quindi.... evitando di paragonare quel povero G4 con i più grossi Core Duo che avevano a disposizione, i numeri calano. Ma lo sanno tutti come funziona il campo di distorsione della realtà di zio Jobs :D

Detto questo, il passaggio ad Intel è stato una cosa buona, non si poteva più andare avanti con G5 che invece di migliorare davvero aumentavano il numero di core, e di portatili con una generazione di processori persino più vecchia (e li invece aumentavano i mhz... sigh). E poi il mio attuale T8300 non fa rimpiangere niente.







Ma su questo nuovo processore, ci girerà bene Quake 3? Aha domanda a sorpresa.

[...]Ma su questo nuovo processore, ci girerà bene Quake 3? Aha domanda a sorpresa.Spero sia stata una domanda ironica... :stordita:

Bella spiegazione davvero.
Certo che però:
Decine di migliaia di queste CPU saranno installate nel nuovo supercomputer.
dovrebbe essere potentino, eh? :sofico:

Spero sia stata una domanda ironica... :stordita:

Si e no :P
Facevo ironia sul fatto che tutti siano ossessionati da Crysis, e poi... vogliamo mettere? Quake 3 è stato il benchmark di riferimento per un bel po', lol.

Secondo le informazioni disponibili Venus, il cui nome commerciale è SPARC64 VIIIfx, è in grado di mettere a disposizione una velocità computazionale 2,5 maggiore di quanto possibile con il processore Intel Core i7-965

Uao un 8 core fisico che supera di 2,5 volte un 8 core virtuali (4 fisici)... Tra l'altro senza comunicare i costi di un singolo processore...

:mbe:

Venus ha inoltre saputo mostrare una notevole efficienza energetica, riusciendo a tagliare a circa 1/3 il consumo energetico attuale.
Quale consumo attuale? Di quanti watt? 100? 1000?

:mbe:

Ok che il Core i7-965 e' il top di velocita' di un singolo processore, ma confrontarlo cosi' a caso...

Come dire che un'auto con motore a reazione e' 25 volte piu' veloce di una Ferrari.... Ma grazie al cavolo, il consumo e' infinitamente piu' alto e non voglio pensare al costo...

Mah...

Fra l'altro non credo proprio che un singolo core di questo nuovo Sparc sia SEMPRE più veloce di un singolo core di un i7... Secondo me questi Fujitsu sono processori che vanno benissimo nel calcolo vettoriale in virgola mobile, ma per il resto sono molto scettico...

Fra l'altro non credo proprio che un singolo core di questo nuovo Sparc sia SEMPRE più veloce di un singolo core di un i7...

ovviamente no, e nessuno lo ha mai detto.
gli ambiti di utilizzo sono diversi, ma molto, per questo ha poco senso confrontarli tranne che per sfizio.

ovviamente no, e nessuno lo ha mai detto.
gli ambiti di utilizzo sono diversi, ma molto, per questo ha poco senso confrontarli tranne che per sfizio.Però l'articolo è un po' fuorviante, perché da quel poco che c'è scritto, si mette in risalto unicamente la forza bruta in termini di gigaflops (confrontandola con un i7), ma non si dice null'altro. Non dice quali sono le sue caratteristiche, non dice se è un architettura in-order o out-of-order, non dice quanta cache ha, non dice quanti registri possiede, non dice che estensioni ha per accelerare calcoli vettoriali (se ne ha), non parla di FSB, non cita nessun benchmark concreto, ma poi alla fine dice che, oltre che per la ricerca e pochi altri ambiti specifici, potrebbe essere usato anche per personal computer e sistemi embedded.
Insomma, più che un articolo, a me pare una pubblicità sponsorizzata da Fujitsu.

Però l'articolo è un po' fuorviante, perché da quel poco che c'è scritto, si mette in risalto unicamente la forza bruta in termini di gigaflops (confrontandola con un i7), ma non si dice null'altro. Non dice quali sono le sue caratteristiche, non dice se è un architettura in-order o out-of-order, non dice quanta cache ha, non dice quanti registri possiede, non dice che estensioni ha per accelerare calcoli vettoriali (se ne ha), non parla di FSB, non cita nessun benchmark concreto, ma poi alla fine dice che, oltre che per la ricerca e pochi altri ambiti specifici, potrebbe essere usato anche per personal computer e sistemi embedded.
Insomma, più che un articolo, a me pare una pubblicità sponsorizzata da Fujitsu.

allora dovrebbe avere ...
Registri: 192 integer 288 floating poin
Cache:
L1: 32KiB 2-way data, 32KiB 2-way instruction
L2: 5MiB 10-way (128 byte line)



inoltre dispone di un suo multithreading che funziona come quello intel SMT.
pure sta cpu inclide il memory controller