Scheda madre Google per processori IBM Power8: eccola!

[marmotta]

In questa news c'è anche un'altra notizia curiosa ed interessante.... nvidia sta prendendo in considerazione il power8 per un futuro HTC!!!

Si deduce che non è una cpu "solo server"

[marmotta]

Anche con le schede di A-eon si parla di migliaia di euro..... poi nell'articolo si parla di prezzi in linea con soluzioni xeon e maggiori prestazioni! Una motherboard xeon e relativo processore (anche di fascia alta) non costa piu di una nemo

How much?

Se intendi lo xeon vado a memoria: 300 euro circa per la motherboard e dai 300 ai 1000 euro per la cpu

Non andando a memoria..... i migliori xeon E7 con socket lga1567 hanno un costo decisamente piu elevato! Ma sono un prodotto di nicchia per chi ha bisogno di 15/30/60 core.

Bisogna vedere quando dicono "prezzo piu competitivo di uno xeon" che xeon intendono.... è una gamma vastissima!

[Amiga Supremo]

Beh,
1300,00€ sarebbero la metà dell'attuale prezzo di un AmigaONE X1000 in configurazione base, anche se però una mobo NEMO attualmente viene poco meno di 2200,00€ (2180,50€ spedita, per l'esattezza).

[marmotta]

Non sono riuscito a risalire al prezzo di un power8.... ma ho trovato qualche power7

Ricondizionato http://www.amazon.com/IBM-Power7-ESFDT00C04-Processor-46J6256/dp/B00H87L5R0/ref=sr_1_1?s=electronics&ie=UTF8&qid=1399054372&sr=1-1&keywords=cpu+ibm+power7

Nuovo http://www.ebay.com/itm/IBM-51Y2836-IBM-Power7-3-0GHz-8-Core-Processor-/231203399296?pt=US_Internal_Hard_Disk_Drives&hash=item35d4cbe680

E' indicativo.... poi bisogna considerare che si tratta del prezzo IBM (che non ha nessun interesse a tenerlo basso...) e con package stile piccolo mattone estraibile per server IBM.

[tlosm]

Non sono riuscito a risalire al prezzo di un power8.... ma ho trovato qualche power7

Ricondizionato http://www.amazon.com/IBM-Power7-ESFDT00C04-Processor-46J6256/dp/B00H87L5R0/ref=sr_1_1?s=electronics&ie=UTF8&qid=1399054372&sr=1-1&keywords=cpu+ibm+power7

Nuovo http://www.ebay.com/itm/IBM-51Y2836-IBM-Power7-3-0GHz-8-Core-Processor-/231203399296?pt=US_Internal_Hard_Disk_Drives&hash=item35d4cbe680

E' indicativo.... poi bisogna considerare che si tratta del prezzo IBM (che non ha nessun interesse a tenerlo basso...) e con package stile piccolo mattone estraibile per server IBM.

Io ho una scheda cpu PowerII di un R6000 ed è grande quanto una scheda madre della Sam 440ep mini itx 8)

[cdimauro]

AROS... lo dici sempre tu che è immaturo e pieno di problemi. Prima di pensare a sfruttare la memoria in più credo che abbiano ben altro da fare, no?

Ma se fosse stato cosi banale comunque lo avrebbero fatto, tanto più che AROS gira su qualsiasi PC, quindi potenzialmente anche su hardware dotati di una gran quantità di memoria fisica (4 GB o più)

Molto probabilmente perché AROS supporta l'architettura x86-64, e dunque il supporto ai 64 bit è completo, visto che tutto (s.o., device, ram disk, applicazioni... tutto!) può utilizzare più di 2GB di memoria.

Sarebbe del tutto inutile buttare tempo per cercare di sfruttare un po' di memoria in pochi e limitati casi, quando puoi farlo interamente e per tutto.

Comunque puoi chiedere a chiunque s'intenda un minimo di s.o. (e un po' di quello Amiga), se non ti fidi.

Mi fido, il punto di discussione era questo; si parlava di tempistica e di eventuale difficoltà nell'implementazione, tu sostieni sia semplice, io anche dopo la tua spiegazione continuo a pensare che non lo sia

E' per questo che ti dicevo di chiedere a qualche programmatore che s'intende di questi argomenti, in modo da avere il giudizio di un'altra persona competente.

Io ciò che avevo da dire tecnicamente sull'argomento l'ho detto, ma se mi dici che continui a pensare che non sia semplice, non posso fare altro che chiederti il parere di qualcun altro.

Tuttavia immagino che la vera ragione per cui sia stata implementata solo adesso non vada tanto ricercata nelle questioni tecniche bensì pratiche, gli hardware precedenti (su OS4) non avevano la possibilità di montare una gran quantità di memoria e, a dirla tutta non c'era nemmeno tutta questa necessità, 2 GB sono teoricamente più che sufficienti per l'uso odierno, tuttavia con l'avvento dell'X1000 e della futura Cyrus le cose a livello hardware sono cambiate per cui giustamente anche il limite dei 2 GB doveva essere superato ..

E' una motivazione valida, ma l'X1000 è fuori da un bel pezzo ormai, e loro ci lavoravano già da prima. La storia la conosciamo.

Comunque considerato la loro cronica lentezza nello sviluppo, penso che rientri in questo anche il parziale utilizzo della memoria oltre i 2GB.

Samo io mi chiedo come mai le cose semplici le fanno sempre gli altri 8)

Perché altri hanno ben altri, e più proficui obiettivi, come puoi leggere sopra.

e comunque credo si stiano dando da fare anche a superare il limite di 256mb di Vram

Di questo non ne ero al corrente, ma mi pare strano che ci sia un limite come quello, visto che lo spazio d'indirizzamento oltre i 2GB è interamente disponibile, e il framebuffer per la scheda video si potrebbe mappare lì, e per ben oltre 256MB.

Moving to SMP will inevitable mean that SMP aware programs will need to adhere to stricter rules. We introduced several mechanisms over the years to improve instability issues causes by buggy software with memory leaks, access to the zero page or a very common mistake, freeeing the same memory twice.

In tandem with the DOS development a lot of work was done in this area in the kernel whilst still retaining backwards compatibility with a lot of old applications including legacy 68K applications. There are limits ofcourse to what extent we will accommodate such programs.

Qui parla di SMP-aware program, quindi di programmi che sono appositamente pensati e realizzati per sfruttare l'SMP. Tradotto: con nuove applicazioni, appositamente pensate e che utilizzano API apposite.

Questo significa che le vecchie applicazioni (sia 68K sia PowerPC) NON potranno fare uso di tutti i core. Molto probabilmente gireranno su un solo core, e nel caso di accesso a particolari parti del s.o. è plausibile che gli altri core verranno congelati in attesa che la situazione "di emergenza" passi.

Dunque possiamo parlare più correttamente di supporto a multicore, peraltro limitato a un solo scenario. Mi fermo qui perché ci sarebbe ben altro da dire, ma non ho tempo, e poi al solito verrei subissato da critiche dai fanatici integralisti, che non riescono ad accettare certi discorsi nemmeno se sono squisitamente tecnici.

Mi pare una soluzione sensata da quanto ne capisco, simile a quella di cui si era ipotizzato a volte in questa sede.
Del resto non avrebbe senso in un contesto di nicchia, rompere la compatibilità con il vecchio parco software, mentre i nuovi programmi potranno sfruttare le CPU multicore.

Alla fine anche su Windows ho visto applicazioni vecchie non pensate per i multicore girare più velocemente su un single core ad alta frequenza che su multicore a frequenza minore.

Ci sono delle differenze sostanziali, però. Le vecchie applicazioni Windows girano in una sandbox, e non inficiano il resto del sistema. Ed è questo che si dovrebbe fare, e si fa, in un s.o. moderno.

L'approccio di AmigaOS4, invece, è troppo conservativo: aggiungono pezze a un s.o. ormai vecchio di 30 anni, trascinandosi dietro tutti i limiti che ha, e tarpando le ali anche alle nuove applicazioni.

Sarebbe meglio pensare a un s.o. il più possibile compatibile con le API e la filosofia del s.o. di Amiga per le nuove applicazioni, facendo girare quelle vecchie isolandole in una sandbox, in modo che non facciano danni.

E conoscendo gli amighisti ottimizzeranno tutti i loro programmi e ricompileranno per le nuove api (powerpc) i vecchi programmi 68k lasciano il tempo che trovano già quelli che funzionano su OS4 senza ausilio del Euae sono molto veloci su un G4 ... su euae jit ho le performance su un G4 1.2ghz come un 68060 a 75mhz ...

Se cambiano le API, è tutt'altro che scontato che sia sufficiente ricompilare le vecchie applicazioni PowerPC per sfruttare i diversi core e/o la memoria protetta e/o il resource tracking e/o i 64 bit e quant'altro di innovativo.

Ed è tutt'altro che scontato che spendano risorse nel farlo. Come ben sai, il panorama Amiga non è che brilli per numero di sviluppatori attivi.

Poi se fosse realmente come dici tu, allora si potrebbero infilare le vecchie applicazioni sia 68K sia PowerPC in una sandbox, lasciando che le nuove girino nel nuovo ambiente sfruttando tutte le caratteristiche moderne di cui sopra. Ovviamente se fosse disponibile un eventuale AmigaOS5 che funzionasse in quel modo.

Comunque samo pensa che ormai le applicazioni 68K non se le calcoli più nessuno, per cui non capisco perché Hyperion sia così saldamente orientata al mantenimento della retrocompatibilità, anziché darci un taglio netto e passare a una soluzione ben più moderna, solida e robusta.

Servono i sorgenti, e non li mollano facilmente, mi pare.

Per dare un'imbeccata, non servono i sorgenti, mi pare.

Non credo che serva. Le cose che ho scritto sono ovvie per chi abbia un po' di conoscenze e/o esperienza nel campo dei s.o. Come dicevo prima a samo, potete chiedere anche ad altri cosa ne pensano sull'argomento, perché sono realmente cose scontate.

Samo io mi chiedo come mai le cose semplici le fanno sempre gli altri 8)

Probabilmente perché per riuscire a fare quelle difficili bisogna anche essere capaci, oltre a dire di esserlo.

Assolutamente d'accordo.

Ad ogni modo, al di là della scheda di Google, chiaramente pensata per server, quel che serve ad Hyperion per far schizzare la base utenti verso i 10mila, come da loro auspicato, è hardware con un rapporto prezzo/prestazioni decisamente migliore, e soprattutto un portatile ad un prezzo accessibile.

Il supporto multicore, di più RAM e delle GPU di ultima generazione, aiuterà e parecchio, però senza un'offerta hardware più competitiva, la user base rimarrà più o meno quella attuale (quantificata in circa 2500 utenti 4.1 registrati da Hyperion stessa, con un numero di licenze vendute evidentemente maggiore, immagino intorno alle 4000).

Purtroppo capisco benissimo che abbassare significativamente i prezzi dell'hadware proprietario sia molto difficile.

Non vedo il problema. Hyperion sviluppa AmigaOS4, che è un s.o.. Non ha nulla a che vedere coi produttori di hardware, e non deve necessariamente legarsi a essi.

Soluzioni PowerPC economiche ne esistono, e pure portatili: supportarli consentirebbe di espandere la base di utenti, se sono realmente quelle le problematiche della comunità di questo s.o..

Poi bisogna considerare anche che un conto è sviluppare su un HW specificatamente progettato per e un altro invece, sviluppare su un HW "sconosciuto".

Hw "sconosciuto" è circoscritto al controller sata (che molto probabilmente è standard), al chip audio (che comunque sarebbe su PCI), idem per la grafica.... rimane il chipset ethernet e usb, ma anche loro sicuramente saranno standard.

Per la cpu a quanto pare il POWER8 mantiene la compatibilità PPC, anche se solo applicazioni scritte appositamente per architettura POWER potrebbero sfruttarlo per bene... ma al memento mi accontenterei

Riassumendo secondo me non ci sarebbe nessuna difficoltà a farci girare AmigaOS.

Concordo. Infatti l'hardware è tutt'altro che sconosciuto, e alcune cose si potrebbero risolvere temporaneamente con qualche schedina.

Una scheda server può essere anche adattata a lavorare da desktop, ma con le dovute limitazioni: il concetto di server odierno non è quello del macchinone monolitico ipertrofico con Windows 2000 su e 4 cpu belve in parallelo. Quella è roba da 10 anni fa. Oggi per server si intendono macchine iperspecializzate nel fornire "servizi" da cui il nome. Un nas per capirci, piuttosto che un router intelligente sono due esempi di server specializzati e non richiedono particolari capacità di calcolo. Quando prendi un cluster di schede che funziona decentemente ne metti un tot a lavorare in parallelo l'una con l'altra: nel caso del power hai buone prestazioni e, cosa importantissima, consumi ridotti per cosi che devono lavorare 24h.
Fare la macchina general purpose (cioè di uso generale) è tutt'altra cosa. Non conosco, per mia ignoranza, i power8 né le cpu montate dalle macchine Google ma sono sicuro che non monteranno un altivec o comunque un'unità vettoriale (cioè dedita all'ausilio del calcolo, ad esempio di dati multimediali) cosa che fa la differenza tra un g4 e un pa-semi.
E'pur vero che molte delle macchine che tutti noi abbiamo (sam, x1000) non ce l'hanno e funzionano ugualmente bene. Potrebbero funzionare meglio, certamente, ma già il loro compitino lo svolgono bene. Mi fermo.
Parole in libertà...

Sono i SoC di Freescale, che verranno montati sulle prossime Cyrus, a non avere Altivec. I POWER già da tempo implementano quest'unità SIMD, e idem per la CPU dell'X1000, come ti è già stato detto.

Altra scelta completamente sbagliata di A-EON, visto che l'unità SIMD è da parecchi anni uno strumento indispensabile per ottenere ottime prestazioni a prezzo contenuto e senza dover necessariamente sbattersi la testa su codice multi-threaded.

In questa news c'è anche un'altra notizia curiosa ed interessante.... nvidia sta prendendo in considerazione il power8 per un futuro HTC!!!

Si deduce che non è una cpu "solo server"

Ma sei sicuro che sia HTC e non HPC, invece? Perché non mi pare di aver letto qualcosa riguardo a soluzioni mobile di nVidia basate su PowerPC, visto che, al contrario, s'è ormai costruita anche un proprio processore ARM in casa.

P.S. Scusate per il mega quote, ma le regole del forum m'impongono di accumulare le risposte in un solo messaggio. Personalmente, anche per una questione di maggior leggibilità, avrei preferito rispondere separatamente / singolarmente.

[marmotta]

Ma sei sicuro che sia HTC e non HPC, invece? Perché non mi pare di aver letto qualcosa riguardo a soluzioni mobile di nVidia basate su PowerPC, visto che, al contrario, s'è ormai costruita anche un proprio processore ARM in casa.

Hai ragione.... preso dalla foga ho confuso l'acronimo è proprio HPC

[cdimauro]

Tranquillo, è un errore che può capitare facilmente.

[Raffaele]

State a farvi tante pippe mentali sui Power 8 quando basterebbe un banale MPC6810D (dual core model) che prima di tutto ha altivec e poi la possibilità per ogni core di lavorare sia in coppia con l'altro sia alternativamente in modalità singola, prendendosi la memoria RAM che gli serve, potendo far girare due sistemi operativi diversi allo stesso tempo, per poter vivere felici.

[cdimauro]

Dal sito di Freescale: "No results for 'MPC6810D'"

Comunque dipende tutto da quello che uno deve farci. Un dual core può andare bene, essere eccessivo, o essere inadeguato. Ognuno ha esigenze diverse.

EDIT. Rispondo su una questione che era rimasta aperta.

Va detto che Hyperion non ha mai parlato di supporto dei 64 bit, almeno mai in riferimento ad AmigaOS 4.2.

Invece l'ha fatto, un bel po' di tempo fa. Non l'avrei citato altrimenti.

Io non l'ho mai letto.
Puoi linkarmi un qualche documento "ufficiale" (quindi di provenienza Hyperion) in cui si parla esplicitamente di supporto ai 64 bit per la prossima release dell'OS?
Sono sicuro al 99% di non averlo mai visto.

Rieccomi, e come avevo promesso ti riporto la fonte, che è addirittura una notizia pubblicata nel blog di Hyperion da uno dei gemelli. Ecco qui.

Per comodità incollo un paio di frasi: "key components of the upcoming AmigaOS 4.2 [...] 64 bit address space awareness".

Allora, sei soddisfatto adesso?

[samo79]

Comunque samo pensa che ormai le applicazioni 68K non se le calcoli più nessuno, per cui non capisco perché Hyperion sia così saldamente orientata al mantenimento della retrocompatibilità, anziché darci un taglio netto e passare a una soluzione ben più moderna, solida e robusta.

Non ricordo di averla messa in questi termini, ho sempre sostenuto che le applicazione 68k non sono più cosi vitali dato che un certo ricambio software c'è stato se vogliamo dirla cosi, tuttavia nei limiti del possibile sono per il loro mantenimento a patto ovviamente di non andare a inficiare lo sviluppo ed il processo di "ammodernamento" futuro .. insomma finchè si può supportare il "mondo 68k" che lo si faccia, dopo si vedrà

[andres]

@cdimauro
Hai ragione te allora.
Anche se va detto che qui si parla in maniera informale di due kernel, uno stabile e uno "sperimentale" da portare avanti per testare grosse novità, non dice esplicitamente che AmigaOS 4.2 sarà a 64 bit.
Comunque ha detto che ci stanno lavorando, quindi sbagliavo.

[marmotta]

State a farvi tante pippe mentali sui Power 8 quando basterebbe un banale MPC6810D (dual core model) che prima di tutto ha altivec e poi la possibilità per ogni core di lavorare sia in coppia con l'altro sia alternativamente in modalità singola, prendendosi la memoria RAM che gli serve, potendo far girare due sistemi operativi diversi allo stesso tempo, per poter vivere felici.

Nemmeno io ho trovato nulla... ma essendo una cpu di Freescale mi sa che ha un decimo della potenza di un Power8 e se i prezzi dovessere coincidere sarebbe una pessima soluzione (si parla sempre si "se").

Riguardo l'Altivec del freescale sarebbe comunque mooolto piu lento di un Power8 anche se non ce l'ha. A proposito cdmauro dice che il Power8 ha l'Altivec....

Ho fatto una piccola ricerca e a quanto pare è vero! https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Intel%20SSE%20to%20PowerPC%20AltiVec%20migration

E si aggiunge il VSX, queste le caratteristiche SIMD del POWER7

Codice: Seleziona tutto

64 Entry Vector/Scalar Register File
– 128-bit wide registers
– Used for 32b/64b scalar as well as 4x32B/2x64b SIMD
instructions
 Floating point instructions and issue rates:
– Up to two instructions can be issued to the VSU in a given
cycle – one for each pipeline
– Instructions executed by pipe0 can be a 128-bit simple fixed
point operation (Altivec), 128-bit complex fixed point operation
(Altivec), 4-way SIMD single-precision FPU operation (Altivec),
a 2-way SIMD double-precision FPU operation (VSX) or a
scalar floating point (single or double precision) operation.
– Instructions executed by pipe1 can be a 128-bit permute
(Altivec or VSX permute), a store, a scalar floating point (single
or double precision) operation, or a 2-way SIMD doubleprecision
FPU operation (VSX).
– So there can be two simultaneous VSX instructions executing
at once, each handling 2 double-precision FP operations. Since
each operation can be a FP multiply-add (FMA) that gives a
peak of 2x2x2=8 double-precision FP operations per cycle.
– Different from previous implementations, the scalar and vector
FP operations are all executed within the VSU.
– Because there are two scalar FXU pipelines independent of the
VSU, two additional FXU operations, for logical operations and/
or array indexing, can be executed at the same time as VSU
operations

[Raffaele]

La mia solita memoria ballerina che mi fa ricordare le cose giuste con un nome differente...

Il processore non è l'MPC8610D, ma l'MPC8641D

http://www.freescale.com/webapp/sps/sit ... 018rH38653


L'MPC8610 invece è il monocore che ha il motore grafico al suo interno, fino a grafica SXGA 10280x1024 ed era stato valutato da A-Cube, se mi ricordo i fatti, come possibile processore per la SAM prima di scegliere l'AMCC che adesso l'equipaggia.

[cdimauro]

Comunque samo pensa che ormai le applicazioni 68K non se le calcoli più nessuno, per cui non capisco perché Hyperion sia così saldamente orientata al mantenimento della retrocompatibilità, anziché darci un taglio netto e passare a una soluzione ben più moderna, solida e robusta.

Non ricordo di averla messa in questi termini, ho sempre sostenuto che le applicazione 68k non sono più cosi vitali dato che un certo ricambio software c'è stato se vogliamo dirla cosi,

Io ricordo che avevi detto che non c'era bisogno di usare le vecchie applicazioni 68K, perché c'erano quelle equivalenti PowerPC. E quindi sarebbe inutile usare le prime.

Ma l'idea che mi sono fatto, leggendo tanti post degli amighisti (anche sui siti internazionali, quando capita), è che il software 68K venga ancora pesantemente utilizzato. E non parlo soltanto di giochi, ovviamente.

tuttavia nei limiti del possibile sono per il loro mantenimento a patto ovviamente di non andare a inficiare lo sviluppo ed il processo di "ammodernamento" futuro .. insomma finchè si può supportare il "mondo 68k" che lo si faccia, dopo si vedrà

Il problema è che, come già detto, applicazioni vecchie sia 68K sia PowerPC inficiano la piattaforma. E' questo il nocciolo della questione.

Se si procede per evoluzione, mettendo pezze all'esistente, anziché a una soluzione radicale, gli utenti continueranno ad avere in mano una piattaforma fragile e non abbastanza moderna.

Poi se è questo che vogliono, amen...

@cdimauro
Hai ragione te allora.
Anche se va detto che qui si parla in maniera informale di due kernel, uno stabile e uno "sperimentale" da portare avanti per testare grosse novità,

Non è così. Leggi bene. Dicono che lo sviluppo è stato suddiviso, e lo capisco perché si tratta di modifiche che potrebbero creare problemi. D'altra parte parliamo di un kernel, e non di un'applicazione: errori in scheduler et similia hanno mostruose ripercussioni.

non dice esplicitamente che AmigaOS 4.2 sarà a 64 bit.

No, infatti non lo sarà. Ma dice che si utilizzeranno (in parte) i 64 bit. E, quindi, farà uso del nuovo kernel sperimentale.

State a farvi tante pippe mentali sui Power 8 quando basterebbe un banale MPC6810D (dual core model) che prima di tutto ha altivec e poi la possibilità per ogni core di lavorare sia in coppia con l'altro sia alternativamente in modalità singola, prendendosi la memoria RAM che gli serve, potendo far girare due sistemi operativi diversi allo stesso tempo, per poter vivere felici.

Nemmeno io ho trovato nulla... ma essendo una cpu di Freescale mi sa che ha un decimo della potenza di un Power8 e se i prezzi dovessere coincidere sarebbe una pessima soluzione (si parla sempre si "se").

Riguardo l'Altivec del freescale sarebbe comunque mooolto piu lento di un Power8 anche se non ce l'ha. A proposito cdmauro dice che il Power8 ha l'Altivec....

Ho fatto una piccola ricerca e a quanto pare è vero! https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Intel%20SSE%20to%20PowerPC%20AltiVec%20migration

E si aggiunge il VSX, queste le caratteristiche SIMD del POWER7

Codice: Seleziona tutto

64 Entry Vector/Scalar Register File
– 128-bit wide registers
– Used for 32b/64b scalar as well as 4x32B/2x64b SIMD
instructions
 Floating point instructions and issue rates:
– Up to two instructions can be issued to the VSU in a given
cycle – one for each pipeline
– Instructions executed by pipe0 can be a 128-bit simple fixed
point operation (Altivec), 128-bit complex fixed point operation
(Altivec), 4-way SIMD single-precision FPU operation (Altivec),
a 2-way SIMD double-precision FPU operation (VSX) or a
scalar floating point (single or double precision) operation.
– Instructions executed by pipe1 can be a 128-bit permute
(Altivec or VSX permute), a store, a scalar floating point (single
or double precision) operation, or a 2-way SIMD doubleprecision
FPU operation (VSX).
– So there can be two simultaneous VSX instructions executing
at once, each handling 2 double-precision FP operations. Since
each operation can be a FP multiply-add (FMA) that gives a
peak of 2x2x2=8 double-precision FP operations per cycle.
– Different from previous implementations, the scalar and vector
FP operations are all executed within the VSU.
– Because there are two scalar FXU pipelines independent of the
VSU, two additional FXU operations, for logical operations and/
or array indexing, can be executed at the same time as VSU
operations

Gli ho dato un'occhiata, e con VSX hanno pensato di fondere assieme il banco di registri dell'FPU e quello di Altivec, per cercare di minimizzare l'impatto delle modifiche, sia a livello di silicio sia di supporto del s.o. per i 64 registri vettoriali. Non dico che siamo ai livelli dell'obsoleta tecnologia MMX di Intel (e 3DNow! di AMD), ma quasi, visto che viene riciclato lo spazio dell'FPU.

Comunque faccio notare che nel link che hai riportato confrontano SSE e Altivec/VSX, quando già da un po' di anni Intel ha introdotto AVX e AVX2, e quest'anno arriverà AVX-512.

Per rendere l'idea, con AVX intel è in grado di eseguire 4x2x2 = 16 operazioni a doppia precisione per ciclo di clock. Con AVX-512 il valore sarà raddoppiato...

Per rendere l'idea del distacco che c'è ormai fra x86 e PowerPC in ambito SIMD: http://www.cwcdefense.com/media-center/ ... ance-.html E parliamo di AVX: con AVX-512 la situazione migliorerà drammaticamente, non soltanto per il raddoppio della dimensione dei registri e quindi della capacità di calcolo, ma perché questa nuova unità SIMD porterà un sacco di altre migliorie che i RISC possono soltanto sognarsi.

La mia solita memoria ballerina che mi fa ricordare le cose giuste con un nome differente...

Il processore non è l'MPC8610D, ma l'MPC8641D

http://www.freescale.com/webapp/sps/sit ... 018rH38653


L'MPC8610 invece è il monocore che ha il motore grafico al suo interno, fino a grafica SXGA 10280x1024 ed era stato valutato da A-Cube, se mi ricordo i fatti, come possibile processore per la SAM prima di scegliere l'AMCC che adesso l'equipaggia.

OK, è il vecchio G4 riciclato in salsa embedded. Rimane comunque un buon processore per le prestazioni che ha.