GPU vs CPU + altro.

[cdimauro]

La discussione è iniziata qui e prosegue in questo thread.

Mi spiace, ma non concordo affatto. La GPU non può sostituire in toto la CPU nei calcoli in virgola mobile, o in generale in calcoli massicciamente paralleli, perché dipende tutto dal tipo di algoritmi che sono adattabili alla sua architettura.

Tant'è che le unità SIMD delle CPU moderne vengono continuamente aggiornate. Non a caso Intel ha tirato fuori le AVX di recente, e sono sicuro che se ne farà un ottimo uso. Come sempre...

Le unità AVX sono in netta competizione con quanto offerto dal GP-GPU in quanto c'è una mega datriba tra intel ed nVidia, non so rammenti i tempi dell'annuncio delle stazioni Tesla e intel che non ha licenziato i nuovi chipset ad nvidia (e certamente intel non sta a braccetto nemmeno con Ati/Amd).

Le due questioni sono ben diverse, e non sono collegate. Le licenze sono un tema che non riguarda solo nVidia, e che Intel batte già da parecchio tempo.

Inoltre non vedo sovrapposizione fra le AVX e il GP-GPU computing. Forse ti confondi con l'architettura Larrabee, che è basata su x86 e che va a competere con nVidia e AMD proprio in questo settore.

Ma se hai informazioni in merito mi farebbe piacere leggerle, perché per me rappresentano una novità.

Cercano di dire, NO! Non usate il GP-GPU (visto che loro non offrono CUDA e compagnia bella) ma i dati AVX per quanto eccellenti per una CPU sono pur sempre ridicoli in confronto a quelli ottenibili su una GPU.

Non vedo come sia possibile questa generalizzazione. Le GPU e le AVX hanno architetture molto diverse, sebbene in alcuni casi siano sovrapponibili.

Poi mentre le GPU sono utilizabili anche in sistemi "non-PC" (quindi anche dalle nostre parti usiamo le componenti che usa Windows), AVX è solo per x86 ( e per ora solo Windows) a noi tocca altivec che è ben altra cosa...(meno potente).

Questo è un altro discorso, ma di estensioni SIMD ne sono presenti parecchie.

Invece anche FreeScale sta provvedendo ad aggiornare Altivec con nuove istruzioni,

Ma come, non sei tu ad insegnarmi che loro le CPU le fanno per il mercato embedded? ;-)

Esattamente, ma non vedo cosa ci sia di male in ciò.

Ricordati che li ci sono sistemi rack che nemmeno ce l'ahnno il chip grafico e quindi se vuoi acelerare la vector math o usi Altivec/SSE o niente...

Questo se parli di server, e in ogni caso anche nel caso di server sono ormai comuni soluzioni con GPU integrata.

Nel settore embedded mobile c'è SEMPRE una GPU, anche di ottima potenza, che fa parte del sistema.

Quindi?

quando il trend è quello di inglobare GPU dentro il core della CPU.

Err...le GPU integrate in Sandy Bridge fanno una figura ultra ridicola contro schede dedicate di 6/7 anni fa.

Infatti Intel ha stretto un accordo con Infineon per infilare una GPU PowerVR nelle sue prossime soluzioni.

Ma a parte questo stranamente non hai citato AMD con le sue soluzioni Fusion, per non parlare di nVidia con Tegra. E' soltanto una dimenticanza?

E' chiaro che quello è solo un trend per chi vuole vedere i film/youtube e usare facebook, senza acquistare una GPU dedicata.

AMD e nVidia stanno dimostrando che una GPU integrata non serve soltanto a questo.

Per il resto putroppo l'atto pratico non trova conferma delle migliori prestazioni float (a basso regime di MHZ) dato che un secondo bench abbastanza float based (Lame) una volta disattivato l'altivec da risultati piuttosto deludenti per chi si aspetta chissà che (valori simili alla 460).

Mi piacerebbe vedere in cosa consiste e in quali condizioni è stato effettuato il test.

Sta su Bitplane, test con lame senza Altivec (e qui parlavamo appunto delle potenzialità lisce).

Non ce l'ho e non l'ho trovato nemmeno online. In sintesi il dato quale sarebbe?

Sai com'è io mi fido piu delle prove su strada che bench sintetici che, come ampiamente dimostrato da Blender e Lame, non hanno corrispondenza reale.

SPEC fa uso di centinaia di algoritmi che ritrovi poi nel codice di tutti i giorni. Si va dai parser (interpreti, compilatori) alla compressione di Huffman, passando per query su base dati, FFT, filtraggio di immagini, ecc. E scusa se è poco...

Infatti, come dicevo, è uno standard industriale usato da tutti, proprio per la varietà del tipo di codice e, quindi, dell'affidabilità che ne deriva.

Quello che vuoi ma se poi sui su strada le differenze tra Peg2 e 460EX (senza Altivec) sono finora risultate irrilevanti, che ti devo dire? Se vuoi ti dico che risultano incredibili super duper yeah!

Non mi sembra che un solo test (quello con Lame; Blender riporta dati contrastanti e va approfondito) possa essere preso come campione di validità universale. Statisticamente è una posizione decisamente debole.

Si dovrebbero fare molti test, con codice quanto più variegato possibile. Che poi è quello che fa SPEC.

Fatico a trovare dati che dimostrino di come la Pegasos2 prevalga sulla 460EX "senza" Altivec,

Io dati non ne ho, ma se li hai tu, passami i link, così potrò almeno dargli un'occhiata.

Per ora abbiamo osservato (sempre senza Altivec parliamo) il bench di blender che hai citato anche tu (dove un 460 a 1Ghz termina il render un po prima del G4 a 800Mhz. Cosa credi che avvenga aumentando il G4 a 1Ghz e la 460 a 1150Mhz? Ancora una volta differenze irrisorie/poca roba? abbastanza inevitabile.)

Quel test è tutto da vedere, come già detto. Per il resto un G4 che passa da 800Mhz a 1Ghz ha un incremento del 25%, mentre un 460 che passa da 1Ghz a 1,15Ghz ha un incremento del 15%. Questo per il clock. A livello prestazionale prendendo QUEL risultato direi che il G4 non è messo affatto male.

Ma, ripeto, bisogna vedere la bontà di quel test col G4, visto che ci sono anche altri risultati in cui si dimostra più efficiente a parità di clock.

e il test lame fatto da bitplane.
In entrambi i casi, non si registrano differenze da far gridare al miracolo da una parte e far strappare i capelli dall'altra, la noia la fa abbastanza da padrona.

Prendendo per buono il LAME, con un solo test non si può dedurre nulla.

Sono molti di più i test che ho riportato io confrontando G3 e G4, dove complessivamente il G4 risulta avere prestazioni superiori. E se consideriamo che il 460 è a metà fra G2 e G3, direi che il quadro non è esattamente a suo favore.

Anche perché ti stai fissando con un G4 a clock abbastanza basso, quando è arrivato al doppio di quella frequenza, proprio in virtù della sua maggior scalabilità in frequenza, e mi sembra che gli altri test di divina dimostrino che all'aumentare della frequenza i risultati siano ben più lusinghieri, no?

Quindi la CPU il suo sporco lavoro lo fa, e si vede.

come fatico a trovare benchmark che pongano altivec al di sopra di GP-GPU.
Perché non ce ne sono? Altrimenti passami il link.

No dico, ma i test di video encoding con GP-GPU li hai visti si? Altivec è un Vic20 in confronto...

Embè? Puoi dimostrare che QUALUNQUE algoritmo in cui sia possibile impiegare un'unità SIMD possa essere portato su una GPU e funzionare (molto) meglio?

Se hai in tasca questa dimostrazione, allora il futuro è quello che ho dipinto: torniamo alle CPU da Commodore 64, lasciando che le GPU facciano praticamente tutto.

Ma mi sembra poco realistico, come quadro, no?

Io potrei farti alcuni esempi in cui l'uso di un'unità SIMD permetta di ottenere prestazioni ben più elevate di qualunque GPU, anche superpompata.

Se la CPU non è importante, a questo punto possiamo tornare a utilizzare il buon 6510 del Commodore 64...

Su questo siamo d'accordo al 100% in verità.
Quello che dico io è limitato a un range microscopico e cioè, al fatto che tra 460EX a 1150Mhz e G4 a 1Ghz SENZA altivec, non si sono registrate differenze eclatanti che possano far strappare i capelli, cosa confermata da benchmarks pratici, che una cosa o due a che fare con in floats ce l'hanno pure...
Il mio paragone termina a queste due schede non è un discorso in generale,

Sì, ma nemmeno puoi generalizzare con due soli benchmark in mano, di cui uno che mostra risultati variabili...

ben consapevole del fatto che i giochi open source arrivano da Linux x86 dove di codice ottimizato Altivec c'è il nisba piu totale (espando ulteriormente al riguardo in altri commenti).

Non è necessario scrivere in assembly per sfruttare le unità SIMD. E' sufficiente utilizzare un buon compilatore, con eventualmente alcune direttive per indicare la presenza di dati vettoriali (se il compilatore non ce la fa a riconoscerli da solo).

Per i calcoli di tipo vector in applicazioni professionali la Peg2 ha l'Altivec del G4 ma non potrà mai avvantaggiarsi del GP-GPU (un difetto della Peg2 non del G4). La 460EX potrà ricevere software di video encoding/decoding accelerati dalla GPU, ma non ha l'Altivec.

Non vedo perché, visto che tutt'ora vengono prodotte schede video AGP con GPU moderne (anche se si tratta ormai di una nicchia di mercato).

Tra i due "potenziali"perferisco quello offerto dalla 460EX e ti spiego definitivamente il perche: il GP-GPU (openCL) è una cosa che faranno per altre piattaforme e che se OpenSource, puoi usare su Amiga, PC, Mac wherever, mentre se fai una cosa specifica per Altivec sarebbe solo per PPC. La cosa ci invita a riflettere sulle conseguenze macroscopiche di tale situazione: quale pensi che la comunità Linux si filerà secondo te?

L'uno o l'altro a seconda del tipo di algoritmo. Inoltre le unità SIMD si possono utilizzare senza ricorrere direttamente all'assembly (vedi sopra).

Ciò non toglie che il GP-GPU è utilizzabile anche su schede AGP (anzi, mi pare ci siano anche schede PCI, tra l'altro).

Il seguente esempio risponde alla domanda: è già pronta la simulazione fisica e fluidodinamica openCL per Blender...(con altre cose che si stanno muovendo per i renderers) per Altivec nada.

Lasciamo alle GPU questo tipo di calcolo, per i quali sono molto versate.

Anche con l'altiveq la Peg2 non gestisce video FullHD, mentre è notizia recente l'introduzione a breve in Gallium/Mesa (solo per schede RadeonHD) dell'accelerazione video HW.
Mi sembra che il quadro cominci a farsi chiaro...

Stai supponendo che la Peg2 (che non è l'unica scheda al mondo a montare un G4) non sia in grado di montare GPU moderne nel suo slot AGP.

Eh, no, mi spiace, ma le cose non stanno affatto così. La CPU il suo lavoro di elaborazione della scena (e dell'IA) lo deve fare, e si tratta di calcoli in virgola mobile. Calcoli per cui un'unità SIMD dà un'ottima mano, a prescindere dalla GPU utilizzata, perché questo è lavoro che NON compete a quest'ultima.

Daccordissimo...ma...

Dunque Altivec, dove disponibile, farebbe sicuramente la differenza, posto che venga sfruttata, appunto.

...AI ottimizata a mano per l'altivec in un gioco PCx86 portato su Amiga? ( )
Hai ragione in generale ma ad Amiga ahimè, tange poco che ci possiamo fare?

Come già detto, non serve l'assembly per sfruttare le unità SIMD. Posso dirti che anche in giochi AAA è sempre più raro trovare pezzi di codice assembly.

Al più la moda è rappresentata dagli "intrinsic" del C++, che possono essere "emulati" anche su architetture completamente diverse.

Il che, almeno da quel che ho letto finora, non è affatto scontato, visto che si parla tanto di ottimizzare qui, ottimizzare là, ma sembra che la pratica sia stata abbandonata anche dagli sviluppatori (neo) amighisti...

Ai tempi d'oro si facevano giochi "piccoli" in assembler e li si ottimizava fino alla morte. Oggi ti capitano giochi fatti da altri con 12 miliardi di linee di codice (un gioco grosso e non tuo in pratica). Al massimo puoi ottimizare i driver video e questa domanda a Rogue gli è stata posta svariate volte in passato, lui ha risposto che la maniera in cui il sistema OpenGl è incastrato adesso non si puo fare molto e serviva farne uno nuovo.
Ci si può arrabbiare del fatto che il lavoro non sia stato fatto prima, ma finalmente ci si sono messi sopra "con la capa e col pensiero" e meglio tardi che mai.

E questo non dimostra forse che ottimizzare a manina il codice usando l'assembly x86 è cosa alquanto rara? Dunque perché continui a tirare in ballo quest'architettura?

Come detto, le ottimizzazioni di basso livello ormai difficilmente le trovi su progetti di milioni di righe di codice.

Lo si fa, se serve, su qualche driver o libreria di sistema. E preferendo gli intrinsic, quale strumento molto più comodo e di più facile portabilità.

Riguardo all'X1000, vedremo con quale supporto arriverà. A mio avviso mancherà l'SMP, i 64 bit, e i driver e/o SDK per sfruttare l'XMOS.

"Day one" è probabile, ma ricordiamoci che le promesse per quest'anno di Hyperion sono state, AmigaOS 4.1Update 2 for classics, Update3 for all e X1000 sugli scaffali con l'ultima versione disponibile di Aos. Dopo di che verranno aggiunte anche le altre facilities.

Come detto in altre occasioni, non mi pare un comportamento corretto far uscire una macchina che non si possa sfruttare al day one. I soldi gli utenti li cacciano fuori subito, non dopo diversi mesi.

Altrimenti è giusto il ragionamento di divina, perché il rischio è che tale supporto non arrivi mai.

E, come tu stesso hai detto, chi glielo fa fare a spendere tempo per un centinaio di utenti? La situazione sarà la stessa delle peg2, visto che hanno venduto qualche centinaio di licenze.

Perché per X1000 e per peg2, alle stesse condizioni? Visti i precedenti, c'è di che dubitarne fortemente...

[DAX]

In effetti siamo andati per conto nostro, questa non è nemmeno piu roba da thread, ma da email tra amici
Procedo con i miei commenti...

Le due questioni sono ben diverse, e non sono collegate. Le licenze sono un tema che non riguarda solo nVidia, e che Intel batte già da parecchio tempo.

Inoltre non vedo sovrapposizione fra le AVX e il GP-GPU computing. Forse ti confondi con l'architettura Larrabee, che è basata su x86 e che va a competere con nVidia e AMD proprio in questo settore.

Ma se hai informazioni in merito mi farebbe piacere leggerle, perché per me rappresentano una novità.

In effetti sfociare su discorsi Wintel rende l'intera cosa tanto complessa quanto irrilevante ai fini Amiga, sia perche noi non abbiamo SIMD competitive come AVX, sia perche io non parlavo in generale, ma solo di due mobo Amiga compatibili e questo in prospettiva alle effettive possibilità di "materializazione" di eventuale software facente uso delle poche facilities a disposizione di tali schede (piu avanti ti arriva lo scoop sulle pegasos che pare sia l'anello mancante di tante incomprensioni ).
Tanto per chit chat, mi riferivo al fatto che in quel periodo (vi erano anche dgli articoli su The Inquirer al rispetto se non ricordo male) sembrava guerra aperta, Intel sembrava avere un asso nella manica (larrabee appunto) da sfidare Nvidia ed in piu li ostacolava con le licenze, Nvidia rispose con le stazioni Tesla e la minaccia di creare super coputers senza il bisogno di intel e così via.
La cosa non è che si sia mai risanata.
Intel il GP-GPU lo vede come un cazzotto in un occhio, non essendo produttore di tali chips spinge perche i medesimi risultino il meno meno indispensabili possibile ed Nvidia continua ad aggiungere in cuda caratteristiche sempre piu avanzate di general computing.

Cercano di dire, NO! Non usate il GP-GPU (visto che loro non offrono CUDA e compagnia bella) ma i dati AVX per quanto eccellenti per una CPU sono pur sempre ridicoli in confronto a quelli ottenibili su una GPU.


Non vedo come sia possibile questa generalizzazione. Le GPU e le AVX hanno architetture molto diverse, sebbene in alcuni casi siano sovrapponibili.

Questa è la spiegazione che ho trovato al riguardo (fammi sapere se concordi con la medesima): "AVX and GPUs are very similar in operation especially in the case of nVidia and their 'scalar thread' approach.
A single AVX instruction does one operation on a set of registers in parallel.
That is exactly what Cuda does as well. Difference is mainly that Cuda takes the parallelism way further than just 4 or 8 registers.
A Cuda multiprocessor unit is basically like an uber-wide AVX unit on an Intel CPU.
The main difference is in how nVidia selects the instructions to execute next. It can have many instances of the same thread, and it uses a scoreboarding algorithm to keep track of which threads are ready for execution of the next instruction (all dependencies on previous instructions being resolved)."

In pratica mi sembra di capire che eccellono nel fare gli stessi tipi di calcolo ma il GPGPU (Cuda in questo caso) nelle sue ultime versioni e su processori potenti, lo fa molto meglio.

Poi mentre le GPU sono utilizabili anche in sistemi "non-PC" (quindi anche dalle nostre parti usiamo le componenti che usa Windows), AVX è solo per x86 ( e per ora solo Windows) a noi tocca altivec che è ben altra cosa...(meno potente).


Questo è un altro discorso, ma di estensioni SIMD ne sono presenti parecchie.

Chiaro, io piu che altro paragonavo OpenCL su AMD 4890 VS Altivec nel fare ad esempio video encoding.
Un PC linux ha la 4890 e ce l'abbiamo anche noi (magari con lo stesso codice open source) se invece andiamo su simd per CPU, il G4 ha l'altivec e il Sandy Bridge ha...una serie di cose che a elencarle tutte facciamo notte

Invece anche FreeScale sta provvedendo ad aggiornare Altivec con nuove istruzioni,
Ma come, non sei tu ad insegnarmi che loro le CPU le fanno per il mercato embedded? ;-)

Esattamente, ma non vedo cosa ci sia di male in ciò.
Ricordati che li ci sono sistemi rack che nemmeno ce l'ahnno il chip grafico e quindi se vuoi acelerare la vector math o usi Altivec/SSE o niente...

Questo se parli di server, e in ogni caso anche nel caso di server sono ormai comuni soluzioni con GPU integrata.

Nel settore embedded mobile c'è SEMPRE una GPU, anche di ottima potenza, che fa parte del sistema.
Quindi?

Era una battuta sul fatto che in alcuni settori la presenza di un unità vettoriale interna è fondamentale, in altri il GPGPU è piu quotato, in ogni modo qui stiamo all'OT dell OT (direi tutta la parte sopra) io concordo con te che avere tutte e due le componenti è ideale, nel caso di Sam460 VS Peg2 però nessuna delle due è in queste condizioni.
Quindi una scelta (lo so sembra strano ma ti manca una info qui, scoop piu in basso ). Ma chi la vorrebbe fare poi una scelta? Meglio tutto no? X1000 e non se ne parla piu (e ti do pure l'Xmos incluso nel prezzo )

quando il trend è quello di inglobare GPU dentro il core della CPU.


Err...le GPU integrate in Sandy Bridge fanno una figura ultra ridicola contro schede dedicate di 6/7 anni fa.


Infatti Intel ha stretto un accordo con Infineon per infilare una GPU PowerVR nelle sue prossime soluzioni.

Ma a parte questo stranamente non hai citato AMD con le sue soluzioni Fusion, per non parlare di nVidia con Tegra. E' soltanto una dimenticanza?

Piu un malinteso credevo ti stessi riferendo ad altro

E' chiaro che quello è solo un trend per chi vuole vedere i film/youtube e usare facebook, senza acquistare una GPU dedicata.
AMD e nVidia stanno dimostrando che una GPU integrata non serve soltanto a questo.

Va beh spero che concordiamo almeno sul fatto che di roba tosta non se n'è vista ancora però (intendo che possa convincere un gamer o un ricercatore con necessità Cuda per es. a lasciar perdere la GPU)

Per il resto putroppo l'atto pratico non trova conferma delle migliori prestazioni float (a basso regime di MHZ) dato che un secondo bench abbastanza float based (Lame) una volta disattivato l'altivec da risultati piuttosto deludenti per chi si aspetta chissà che (valori simili alla 460).

Mi piacerebbe vedere in cosa consiste e in quali condizioni è stato effettuato il test.
Sta su Bitplane, test con lame senza Altivec (e qui parlavamo appunto delle potenzialità lisce).
Non ce l'ho e non l'ho trovato nemmeno online. In sintesi il dato quale sarebbe?

Che usando lame senza Altivec Sam460EX e Pegasos2 con OS4.1Update2 danno gli stessi risultati.

Quello che vuoi ma se poi sui su strada le differenze tra Peg2 e 460EX (senza Altivec) sono finora risultate irrilevanti, che ti devo dire? Se vuoi ti dico che risultano incredibili super duper yeah!

Non mi sembra che un solo test (quello con Lame; Blender riporta dati contrastanti e va approfondito) possa essere preso come campione di validità universale. Statisticamente è una posizione decisamente debole.

Si dovrebbero fare molti test, con codice quanto più variegato possibile. Che poi è quello che fa SPEC.

Mah io rimango dell'idea che una scheda grafica non vada testata con 3Dmark ma con i giochi e lo stesso vale per le CPU, applicazioni, applicazioni e ancora applicazioni ( i sintetici non mi interessano in genere) anche se concordo con te sul fatto che una rosa di benchs piu ampia sia necessaria, vedremo...

Fatico a trovare dati che dimostrino di come la Pegasos2 prevalga sulla 460EX "senza" Altivec,

Io dati non ne ho, ma se li hai tu, passami i link, così potrò almeno dargli un'occhiata.


Per ora abbiamo osservato (sempre senza Altivec parliamo) il bench di blender che hai citato anche tu (dove un 460 a 1Ghz termina il render un po prima del G4 a 800Mhz. Cosa credi che avvenga aumentando il G4 a 1Ghz e la 460 a 1150Mhz? Ancora una volta differenze irrisorie/poca roba? abbastanza inevitabile.)


Quel test è tutto da vedere, come già detto. Per il resto un G4 che passa da 800Mhz a 1Ghz ha un incremento del 25%, mentre un 460 che passa da 1Ghz a 1,15Ghz ha un incremento del 15%. Questo per il clock. A livello prestazionale prendendo QUEL risultato direi che il G4 non è messo affatto male.

Ti ricordo però che il G4 parte in svantaggio (non partono dallo stesso tempo per poi aumentare il clock, il G4 partiva in svantaggio di un po di secondi) cosa che alla fine potrebbe si far sempre vincere il G4 di qualcosa, ma potremmo parlare di "strappaggio dei capelli" (nota pratica indonesiana )? dai, sarebbe comunque una differenza noiosa.

Ma, ripeto, bisogna vedere la bontà di quel test col G4, visto che ci sono anche altri risultati in cui si dimostra più efficiente a parità di clock.

Tutto è possibile, e come ripeto concordo con te che andranno fatti altri test.

e il test lame fatto da bitplane.
In entrambi i casi, non si registrano differenze da far gridare al miracolo da una parte e far strappare i capelli dall'altra, la noia la fa abbastanza da padrona.


Prendendo per buono il LAME, con un solo test non si può dedurre nulla.
Sono molti di più i test che ho riportato io confrontando G3 e G4, dove complessivamente il G4 risulta avere prestazioni superiori. E se consideriamo che il 460 è a metà fra G2 e G3, direi che il quadro non è esattamente a suo favore.
Anche perché ti stai fissando con un G4 a clock abbastanza basso, quando è arrivato al doppio di quella frequenza, proprio in virtù della sua maggior scalabilità in frequenza, e mi sembra che gli altri test di divina dimostrino che all'aumentare della frequenza i risultati siano ben più lusinghieri, no?

Quindi la CPU il suo sporco lavoro lo fa, e si vede.

Mi fossilizzo su quella frequenza perche OS4 non è disponibile su G4 a frequenze piu alte. Ripeto non sto dicendo che il G4 è inferiore o simile, ma che nel caso di OS4 siamo limitati a Sam460 1.15Ghz (con PCI-E ed eventuali vantaggi che porterà) e G4 1Ghz con Altivec ma niente PCI-E e mega scoop in arrivo (manca poco...) e "per ora" test da strapparsi i capelli non sono apparsi, tutto qui.

come fatico a trovare benchmark che pongano altivec al di sopra di GP-GPU.
Perché non ce ne sono? Altrimenti passami il link.


No dico, ma i test di video encoding con GP-GPU li hai visti si? Altivec è un Vic20 in confronto...


Embè? Puoi dimostrare che QUALUNQUE algoritmo in cui sia possibile impiegare un'unità SIMD possa essere portato su una GPU e funzionare (molto) meglio?

Se hai in tasca questa dimostrazione, allora il futuro è quello che ho dipinto: torniamo alle CPU da Commodore 64, lasciando che le GPU facciano praticamente tutto.

Ma mi sembra poco realistico, come quadro, no?

Io potrei farti alcuni esempi in cui l'uso di un'unità SIMD permetta di ottenere prestazioni ben più elevate di qualunque GPU, anche superpompata.

Forse stai fondendo troppo l'unità simd con l'intero concetto di CPU. Se mi dici che la GPU non puo fare tutto quello che fa una CPU sono con te, ma se separi l'unità SIMD ti accorgi che fa le stesse cose del GPGPU e che quest'ultimo invece di "sostituire" la CPU, puo attuare come se fosse la sua unità simd (per esempio, immagina un cell dove invece di un array di SPU, vi siano centinaia e centinaia di CudaCores). Insomma non mischiamo le due cose, la CPU serve, GPGPU può attuare in sostituzione della Vector unit e fare molto meglio in tandem.

Su questo siamo d'accordo al 100% in verità.
Quello che dico io è limitato a un range microscopico e cioè, al fatto che tra 460EX a 1150Mhz e G4 a 1Ghz SENZA altivec, non si sono registrate differenze eclatanti che possano far strappare i capelli, cosa confermata da benchmarks pratici, che una cosa o due a che fare con in floats ce l'hanno pure...
Il mio paragone termina a queste due schede non è un discorso in generale,


Sì, ma nemmeno puoi generalizzare con due soli benchmark in mano, di cui uno che mostra risultati variabili...

ben consapevole del fatto che i giochi open source arrivano da Linux x86 dove di codice ottimizato Altivec c'è il nisba piu totale (espando ulteriormente al riguardo in altri commenti).


Non è necessario scrivere in assembly per sfruttare le unità SIMD. E' sufficiente utilizzare un buon compilatore, con eventualmente alcune direttive per indicare la presenza di dati vettoriali (se il compilatore non ce la fa a riconoscerli da solo).

Come detto concordo con i "soli due benchs", per il resto mi ha detto Andrea Palmatè al quale ho chiesto proprio questa cosa esplicitamente che lui non ha avuto gran fortuna con i compilatori a nostra disposizione (e Andrea è un programmatore esperto, specie con i giochi) magari roba come il compilatore professionale intel (che ho sentito essere un vero e proprio mostro) farà 1000 volte meglio, ma su amiga...no luck a detta di Andrea.

Per i calcoli di tipo vector in applicazioni professionali la Peg2 ha l'Altivec del G4 ma non potrà mai avvantaggiarsi del GP-GPU (un difetto della Peg2 non del G4). La 460EX potrà ricevere software di video encoding/decoding accelerati dalla GPU, ma non ha l'Altivec.
Non vedo perché, visto che tutt'ora vengono prodotte schede video AGP con GPU moderne (anche se si tratta ormai di una nicchia di mercato).

Ok questo è un dato che non hai quindi non mi stupisce la tua risposta (finalmente ecco lo scoop ): la Pegasos2 ha un problema tecnico che gli impedisce di inizializare le schede RadeonHD AGP (anche quelle PCI su bus semplici) e Bplan, contatta da Hans De Ruiter ha dato il 2 di picche a qualsiasi aiuto al riguardo.
La mobo non ha dunque a disposizione (nemmeno in Mos) schede che utilizzino il paradigma Unified Shader Units, solo roba fixed function che non puo essere usata per il GPGPU.(bella fregatura...)

Tra i due "potenziali"perferisco quello offerto dalla 460EX e ti spiego definitivamente il perche: il GP-GPU (openCL) è una cosa che faranno per altre piattaforme e che se OpenSource, puoi usare su Amiga, PC, Mac wherever, mentre se fai una cosa specifica per Altivec sarebbe solo per PPC. La cosa ci invita a riflettere sulle conseguenze macroscopiche di tale situazione: quale pensi che la comunità Linux si filerà secondo te?


L'uno o l'altro a seconda del tipo di algoritmo. Inoltre le unità SIMD si possono utilizzare senza ricorrere direttamente all'assembly (vedi sopra).

Ciò non toglie che il GP-GPU è utilizzabile anche su schede AGP (anzi, mi pare ci siano anche schede PCI, tra l'altro).

Come futuro possessore di X1000 mi auguro che quelle 2 unità Altivec non stiano sempre a pettinare le bambole quindi che ti devo dire? se esce un sacco di software che le usa non sarò io a protestare. Resta da vedere cosa si potrà ottenere in AmigaOS con codice non "preparato" a mano (una volta si è lamentato anche un evangelista Mos, Crumb, della stessa cosa).
Poi per il resto adesso sai del problema della Pegasos.

Il seguente esempio risponde alla domanda: è già pronta la simulazione fisica e fluidodinamica openCL per Blender...(con altre cose che si stanno muovendo per i renderers) per Altivec nada.


Lasciamo alle GPU questo tipo di calcolo, per i quali sono molto versate.

Anche con l'altiveq la Peg2 non gestisce video FullHD, mentre è notizia recente l'introduzione a breve in Gallium/Mesa (solo per schede RadeonHD) dell'accelerazione video HW.
Mi sembra che il quadro cominci a farsi chiaro...


Stai supponendo che la Peg2 (che non è l'unica scheda al mondo a montare un G4) non sia in grado di montare GPU moderne nel suo slot AGP.

Ancora una volta malinteso dovuto a un dato che ti mancava

Daccordissimo...ma...

Dunque Altivec, dove disponibile, farebbe sicuramente la differenza, posto che venga sfruttata, appunto.


...AI ottimizata a mano per l'altivec in un gioco PCx86 portato su Amiga? ( )
Hai ragione in generale ma ad Amiga ahimè, tange poco che ci possiamo fare?


Come già detto, non serve l'assembly per sfruttare le unità SIMD. Posso dirti che anche in giochi AAA è sempre più raro trovare pezzi di codice assembly.

Al più la moda è rappresentata dagli "intrinsic" del C++, che possono essere "emulati" anche su architetture completamente diverse.

Il che, almeno da quel che ho letto finora, non è affatto scontato, visto che si parla tanto di ottimizzare qui, ottimizzare là, ma sembra che la pratica sia stata abbandonata anche dagli sviluppatori (neo) amighisti...


Ai tempi d'oro si facevano giochi "piccoli" in assembler e li si ottimizava fino alla morte. Oggi ti capitano giochi fatti da altri con 12 miliardi di linee di codice (un gioco grosso e non tuo in pratica). Al massimo puoi ottimizare i driver video e questa domanda a Rogue gli è stata posta svariate volte in passato, lui ha risposto che la maniera in cui il sistema OpenGl è incastrato adesso non si puo fare molto e serviva farne uno nuovo.
Ci si può arrabbiare del fatto che il lavoro non sia stato fatto prima, ma finalmente ci si sono messi sopra "con la capa e col pensiero" e meglio tardi che mai.

E questo non dimostra forse che ottimizzare a manina il codice usando l'assembly x86 è cosa alquanto rara? Dunque perché continui a tirare in ballo quest'architettura?

Perche kas1e ha trovato blocchi Assembler mentre cercava di portare Return to Castle Wolfenstein? (vero però)

Come detto, le ottimizzazioni di basso livello ormai difficilmente le trovi su progetti di milioni di righe di codice.


Lo si fa, se serve, su qualche driver o libreria di sistema. E preferendo gli intrinsic, quale strumento molto più comodo e di più facile portabilità.

Speriamo bene che ti devo dire...

Riguardo all'X1000, vedremo con quale supporto arriverà. A mio avviso mancherà l'SMP, i 64 bit, e i driver e/o SDK per sfruttare l'XMOS.

"Day one" è probabile, ma ricordiamoci che le promesse per quest'anno di Hyperion sono state, AmigaOS 4.1Update 2 for classics, Update3 for all e X1000 sugli scaffali con l'ultima versione disponibile di Aos. Dopo di che verranno aggiunte anche le altre facilities.


Come detto in altre occasioni, non mi pare un comportamento corretto far uscire una macchina che non si possa sfruttare al day one. I soldi gli utenti li cacciano fuori subito, non dopo diversi mesi.

Altrimenti è giusto il ragionamento di divina, perché il rischio è che tale supporto non arrivi mai.

Per quanto non mi sentirai certo dire che è una pacchia fighissima (non avere tutto from day one) va comunque sfatato il mito che Hyperion non fa le cose. Ai tempi di OS4 con Amiga Inc, si sono fermati svariate volte con la minaccia di perdere tutto il lavoro. Da quando ho la Sam invece stanno sfornado roba una dopo l'altra. hanno portato il 4.1 prima versione su Sam, Pegasos2 (e ovviamente A1), poi il corposo Update1 (che in altri OS avrebbero chiamato 4.2 minimo) su tutte le piattaforme, poi Update2, poi 4.0 e 4.1 su Classic e sappiamo che l'Update 3 (corposo come il "1") è in fase di ultimazione.
Non dubito che il ritmo procederà bene e le facilities promesse verranno offerte Update dopo update in maniera steady.
Vorrey anche fare un distinguo sul paragone che si è fatto con l'USB 2.0 e cioè che li Hyperion si è incaponita con una versione proprietaria tutta sua (da zero) e ci ha messo una quaresima, se avessero deciso per Poseidon avrebbero già risolto. Credo che la lezione l'abbiano appresa e per il 3D stanno "portando" e non riscrivendo da zero (cosa fatta con sangue e lacrime anche per il Driver2D per RadeonHD) faccio anche notare che Hans de Ruiter non è un improvvisato 8lavora con queste cose anche per guadagnarsi il pane) e Hans Joerg Frieden è first and foremost un programmatore di API e motori grafici 3D (programmatore di SO ci è diventato) .

E, come tu stesso hai detto, chi glielo fa fare a spendere tempo per un centinaio di utenti? La situazione sarà la stessa delle peg2, visto che hanno venduto qualche centinaio di licenze.
Perché per X1000 e per peg2, alle stesse condizioni? Visti i precedenti, c'è di che dubitarne fortemente...

Qui i discorsi (lo avrai ormai capito) sono due, per la Peg non è un accanimento è che il supporto era previsto, hanno scoperto l'arcano, hanno contattato Bplan e due di picche.

Per l'X1000 spero sia un successone (ed è alla base dei progetti futuri) comunque tutti gli utenti Sam riceveranno Gallium quindi andrà ai seguenti utenti: Sam440, SamFlex (che sono molti piu di 100 ;-)) Sam460EX e AmigaOne X1000.
Per le altre facilities si parla del futuro di Amiga, quindi o si fermano o vanno avanti con l'SMP etc etc etc.

[divina]

Era una battuta sul fatto che in alcuni settori la presenza di un unità vettoriale interna è fondamentale, in altri il GPGPU è piu quotato, in ogni modo qui stiamo all'OT dell OT (direi tutta la parte sopra) io concordo con te che avere tutte e due le componenti è ideale, nel caso di Sam460 VS Peg2 però nessuna delle due è in queste condizioni.
Quindi una scelta (lo so sembra strano ma ti manca una info qui, scoop piu in basso ). Ma chi la vorrebbe fare poi una scelta? Meglio tutto no? X1000 e non se ne parla piu (e ti do pure l'Xmos incluso nel prezzo )

quindi hai cambiato idea ... prima sostenevi che il Pegasos2 G4 (ed AmigaOne G4) erano da buttare, sostenendo che l' alternativa logica era la Sam 460 ... poi fortunatamente ti sei ricreduto ed hai capito che sarebbe comunque un downgrade ... beh meglio tardi che mai ...

Che usando lame senza Altivec Sam460EX e Pegasos2 con OS4.1Update2 danno gli stessi risultati.

per quale motivo bisognerebbe fare un test tanto sciocco, castrando volutamente una CPU PowerPC G4 ? (sappiamo che è il test fatto da @Lecta in Bitplane, ma come si è già detto a suo tempo, cerca il thread, è "giocare sporco" con un test fatto in quel modo).

Ok questo è un dato che non hai quindi non mi stupisce la tua risposta: la Pegasos2 ha un problema tecnico che gli impedisce di inizializare le schede RadeonHD AGP (anche quelle PCI su bus semplici) e Bplan, contatta da Hans De Ruiter ha dato il 2 di picche a qualsiasi aiuto al riguardo.
La mobo non ha dunque a disposizione (nemmeno in Mos) schede che utilizzino il paradigma Unified Shader Units, solo roba fixed function che non puo essere usata per il GPGPU.

non proprio così ... un po' di chiarezza: l' AmigaOne G4 ed il Pegsos 2 G4 supportano perfettamene schede video AGP 2x ... e NON supportano schede video AGP 4x (come qualunque altra mainboard x86 o PowerPC con AGP2x e non 4x), pertanto non risultano utilizzabili le schede video AGP HD 4x/8x ... tutto qua.
Sono invece utilizzabili le schede video ATI R300 es. la ATI Radeon 9800 AGP (modello in 2x) se si dessero una svegliata quelli di AmigaOS4.x potremmo utilizzare nel Pegasos2 G4 sia AmigaOS4.1.x che MorphOS2.x con una ottima ATI 9800 e con questo penso di aver chiarito il tutto
Da ultimo il "problema" di Bplan in merito al supporto di schede video riguarda il supporto di schede video HD su PCI (che non condivido), ma questo è un altro discorso.

Anche con l'altiveq la Peg2 non gestisce video FullHD, mentre è notizia recente l'introduzione a breve in Gallium/Mesa (solo per schede RadeonHD) dell'accelerazione video HW.
Mi sembra che il quadro cominci a farsi chiaro...

a me paiono solo slogan di un fan boy ... anche perchè di cose tangibili da Hyperion non se ne vedono da un pezzo, poi fai tu ...

"Day one" è probabile, ma ricordiamoci che le promesse per quest'anno di Hyperion sono state, AmigaOS 4.1Update 2 for classics, Update3 for all e X1000 sugli scaffali con l'ultima versione disponibile di Aos. Dopo di che verranno aggiunte anche le altre facilities.

bisogna vedere cosa c'è dentro di sostanziale e sostanzioso in quegli updates

Qui i discorsi (lo avrai ormai capito) sono due, per la Peg non è un accanimento è che il supporto era previsto, hanno scoperto l'arcano, hanno contattato Bplan e due di picche.

ancora con sta storia delle schede video HD su PCI ma si può ... ... ... tu su sei un vero fan boy

Per l'X1000 spero sia un successone (ed è alla base dei progetti futuri) comunque tutti gli utenti Sam riceveranno Gallium quindi andrà ai seguenti utenti: Sam440, SamFlex (che sono molti piu di 100 ;-)) Sam460EX e AmigaOne X1000.
Per le altre facilities si parla del futuro di Amiga, quindi o si fermano o vanno avanti con l'SMP etc etc etc.

mah ...

[DAX]

n ogni caso qualcuno ha detto (sempre su morphZone) che stanno investigando e che potrebbe anche non accadere mai (cosa, incredibile ma vero, riportata su Amiga.org dal super Mos fanboy "TakemeHomeGrandma" proprio in seguito alla pubblicazione degli screen "proof of concept").
poi se esce ben venga potrei farci un pensierino


non mi pare interessante un pensiero di un fan boy ... piuttosto diciamo che da svariati mesi, diversi sviluppatori del team di MorphOS hanno acquistato delle workstation PowerMac G5 e degli host IMac G5 con Isight per portarvi MorphOS2.x, traine tu le conseguenze autonomamente

A lato dei miei appellativi per come tale individuo si comporta su Amiga.org, lui nella comunità MOS internazionale è abbastanza rispettato come MOS evengelizer ed è il compagno di merende N.1 di Piru col quale dialoga spesso anche in privato.
Quando è uno che è a stretto contatto con gli sviluppatori a frenare gli entusiasmi, vuol dire solo una cosa: si i mac G5 li hanno presi, ma le analisi e i tentativi potrebbero anche portare alla decisione di cannare il progetto, oppure che ci potrebbe volere un secolo e mezzo.
Adesso se sono io a frenare gli entusiasmi pensa quello che vuoi, se è TMHG, mi preoccuperei...

Sono invece utilizzabili le schede video ATI R300 es. la ATI Radeon 9800 AGP (modello in 2x) se si dessero una svegliata quelli di AmigaOS4.x potremmo utilizzare nel Pegasos2 G4 sia AmigaOS4.1.x che MorphOS2.x con una ottima ATI 9800 e con questo penso di aver chiarito il tutto

Vedo che la cosa fondamentale non l'hai ancora capita: Mos e AOS non hanno lo stesso driver. Quello Mos può essere ottimizato, quello AOS è dipendente da Picasso96 e non c'è niente da fare. Per fare quello che dici tu Hyperion dovrebbe fermare lo sviluppo del futuro driver e concentrarsi a fare da zero un driver 2D nuovo per R300, e poi un driver 3D.
Quello che c'è parziale è Picasso96 e non va bene, Hans ha commnetato (per la 9700, ma fa lo stesso, il 9800 è praticamnte lo stesso chip)che per come è bloccato tutto, la Radeon9100 Pro 128-Bit darebbe risultati analoghi Che un driver possa rovinare completamente (bloccare e imbavagliare) le prestazioni di un scheda è confermato da tanti test incrociati con drivers diversi (la stessa scheda può anche ridursi a un terzo delle prestazioni col driver sbagliato) e Mac ne sa qualcosa (e su AOS stiamo pure peggio al momento).
Quindi fatti una 9100 e non cambia un gran che.

Mos ha puntato su un sitema diverso (e finemente ottimizato), AOS deve cambiarlo poi arriveranno le ottimizazioni se mai.
Non ha senso blocccare tutto per l'impresa titanica che ci vorrebbe per rifare tutto sulla Peg2 ad alte prestazioni (rifacimento totale del driver 2D e 3D per R300), ne perdere tempo col supporto R300 su picasso96 per quanto visto sopra (fatti una 9100Pro 128-Bit se vuoi usare l'attuale zozzeria).

Anche con l'altiveq la Peg2 non gestisce video FullHD, mentre è notizia recente l'introduzione a breve in Gallium/Mesa (solo per schede RadeonHD) dell'accelerazione video HW.
Mi sembra che il quadro cominci a farsi chiaro...

a me paiono solo slogan di un fan boy ... anche perchè di cose tangibili da Hyperion non se ne vedono da un pezzo, poi fai tu ...

Ho già letto il tuo commento su USB2.0, ma ti rispondo la stessa cosa che ho detto a Cesare (che tra l'altro riportava i tuoi commenti) con USB 2.0 Hyperion si è incaponita con una versione proprietaria tutta sua (da zero) e ci ha messo una quaresima, se avessero deciso per Poseidon avrebbero già risolto. Credo che la lezione l'abbiano appresa e per il 3D stanno "portando" e non riscrivendo da zero (cosa fatta con sangue e lacrime anche per il Driver2D per RadeonHD che per fortuna è ormai al 99.9%) faccio anche notare che Hans de Ruiter non è un improvvisato (lavora con queste cose anche per guadagnarsi il pane) e Hans Joerg Frieden è first and foremost un programmatore di API e motori grafici 3D.
Se su Aros una persona sola ci è riuscita in un anno, stai sicuro che due esperti del settore faranno altrettanto bene.

Detto questo ti faccio notare per le stesse ragioni di cui sopra, che non sono loro ad aggiungere l'accelerazione video HW in Gallium, lo stanno facendo su Linux e solo per schede RadeonHD. I nostri prodi devono solo "portare" e beccarsi tutto l'ambaradam con massimo gaudio.

Era una battuta sul fatto che in alcuni settori la presenza di un unità vettoriale interna è fondamentale, in altri il GPGPU è piu quotato, in ogni modo qui stiamo all'OT dell OT (direi tutta la parte sopra) io concordo con te che avere tutte e due le componenti è ideale, nel caso di Sam460 VS Peg2 però nessuna delle due è in queste condizioni.
Quindi una scelta (lo so sembra strano ma ti manca una info qui, scoop piu in basso ). Ma chi la vorrebbe fare poi una scelta? Meglio tutto no? X1000 e non se ne parla piu (e ti do pure l'Xmos incluso nel prezzo )


quindi hai cambiato idea ... prima sostenevi che il Pegasos2 G4 (ed AmigaOne G4) erano da buttare, sostenendo che l' alternativa logica era la Sam 460 ... poi fortunatamente ti sei ricreduto ed hai capito che sarebbe comunque un downgrade ... beh meglio tardi che mai ...

Non ho mai detto che la 460 sia la naturale evoluzione di niente, solo che un sistema valido e che per me quando saranno chiusi i giochi sarà una macchina che darà all'utente AmigaOS molte piu soddisfazioni della Pegasos2 (grazie alla'incapacità di quest'ultima di utlizare niente che abbia unified shader units).
L'X1000 è ovvimante l'ideale.

Che usando lame senza Altivec Sam460EX e Pegasos2 con OS4.1Update2 danno gli stessi risultati.

per quale motivo bisognerebbe fare un test tanto sciocco, castrando volutamente una CPU PowerPC G4 ? (sappiamo che è il test fatto da @Lecta in Bitplane, ma come si è già detto a suo tempo, cerca il thread, è "giocare sporco" con un test fatto in quel modo).

Guarda che io e Cesare stavamo intraprendendo una discussione proprio sulle potenzialità float senza Altivec (in maniera accademica) e quel test era presentato in quel contesto.

On a separate note però, ti faccio cmq presente che codice OpenSource per video encoding tramite OpenCL è già disponibile e che li si registrano differenze anche di 100:1. Come sempre si tratta di portare e non creare da zero.

Ok questo è un dato che non hai quindi non mi stupisce la tua risposta: la Pegasos2 ha un problema tecnico che gli impedisce di inizializare le schede RadeonHD AGP (anche quelle PCI su bus semplici) e Bplan, contatta da Hans De Ruiter ha dato il 2 di picche a qualsiasi aiuto al riguardo.
La mobo non ha dunque a disposizione (nemmeno in Mos) schede che utilizzino il paradigma Unified Shader Units, solo roba fixed function che non puo essere usata per il GPGPU.


non proprio così ... un po' di chiarezza: l' AmigaOne G4 ed il Pegsos 2 G4 supportano perfettamene schede video AGP 2x ... e NON supportano schede video AGP 4x (come qualunque altra mainboard x86 o PowerPC con AGP2x e non 4x), pertanto non risultano utilizzabili le schede video AGP HD 4x/8x ... tutto qua.Da ultimo il "problema" di Bplan in merito al supporto di schede video riguarda il supporto di schede video HD su PCI (che non condivido), ma questo è un altro discorso.

E' stato dettagliato da programmatori esperti mos come ChainQ, che il bus AGP della peg2 non è affatto AGP standard, dopo un analaisi pare che apprte il pettine si siano concentrati su un rewiring da 4 soldi contatta ChainQ e fatti dare i dettagli. Vi sono i problemi dell'open firmware, ma il fatto è che comunque si sia cercato di dare qualcosa, e Bplan ha dato il due di picche, daccordo o meno, un produttore HW non dovrebbe comportarsi così, ma che scherziamo.
Opinioni a parte le Unified Shader Units rimangono un sogno.

ancora con sta storia delle schede video HD su PCI ma si può ... ... ...
tu su sei un vero fan boy

Essere chiamato Fanboy per aver descritto dettagliatamente la situazione dei due drivers (presente e futuro) e la voglia comunque di dare supporto a un vecchio HW mi sembra il top. FanBoy sarebbe aspettarsi grandi prestazioni da tale supporto (cosa che non esiste), qui si parla di risorse umane a disposizione da una parte e compassione per la povera peg dall'altra.
Mi domando poi quale sarebbe il termine per chi magari se ne sta sempre nei thread di un altro flavor per riempirlo di fango e buttarci dentro la solita pubblicità per il proprio clone preferito.

[Lecta]

per quale motivo bisognerebbe fare un test tanto sciocco, castrando volutamente una CPU PowerPC G4 ? (sappiamo che è il test fatto da @Lecta in Bitplane, ma come si è già detto a suo tempo, cerca il thread, è "giocare sporco" con un test fatto in quel modo).

Non intervengo sul resto del thread perché proprio non me ne può fregar di meno di alimentare il tuo EGO....
Però visto che mi chiami gentilmente in causa dandomi dello "sciocco" (colui che ha fatto il test) e di quello che gioca sporco....

Il test come ho già spiegato in precedenza (ma ovviamente non c'è peggior sordo di chi non vuol sentire come hai dimostrato più volte e come dimostrerai di nuovo rispondendo ancora a questo mio post con le solite trite e ritrite argomentazioni che ormai posti a macchinetta su qualsiasi thread venga aperto su iksnet) nel test ho preso il minimo comune denominatore disponibile per le due piattaforme. Non avendo a disposizione una versione ottimizzata per Sam460 ho preso lo stesso identico eseguibile e l'ho usato su entrambe le piattaforme, unico modo secondo me (ma ovviamente tu non conosci il significato della frase "secondo me" visto che spacci per verità assoluta tutto quello che scrivi) di poter vedere come si comportavano due piattaforme alle stesse condizioni di utilizzo.
Fidati che se avessi voluto "giocare sporco", come mi hai gentilmente accusato di fare, avrei potuto farlo in ben altri modi con test confezionati ad hoc.

Ti invito a non mettere mai più in dubbio la mia onestà, perché un conto è avere opinioni divergenti, un conto è gettare accuse sugli altri.

E con questo chiudo la faccenda.
Non mi meraviglio veramente più quando sento di gente che si allontana (anche da questo forum) perché disgustata dal clima di accuse e veleni creato dai soliti noti.

Ah, evita pure di rispondermi con frasi del tipo "io ho diritto di dire come la penso" "io che sono utente di entrambi i sistemi posso giudicare obiettivamente (si come no)" o altre frasi del cavolo che usi di solito per giustificarti... ormai le conosciamo bene.

Edit: corretto due erroracci di ortografia

[Alblino]

@Divina
In effetti dai era chiaro che su bitplane il test
di Lame era fatto con la versione che non usa le istruzioni
Altivec del G4 è ben scritto.
Per cui precisa pure però non esagerare con le accuse a Lecta di
giocare sporco.

[amig4be]

non ho letto l'articolo perchè non interessato alla rivista in se, però è possibile preparare per il prossimo numero un articolo dove si torchia in ogni modo la 460 senza pietà...

a partire da blender (non c'è bisogno di aspettare gallium quando si puà già torchiare la cpu con l'ormai obsoleto blender 2.4x)
emulazione classic, bench sotto emulazione

e tante altre cose

[cdimauro]

In effetti sfociare su discorsi Wintel rende l'intera cosa tanto complessa quanto irrilevante ai fini Amiga, sia perche noi non abbiamo SIMD competitive come AVX, sia perche io non parlavo in generale, ma solo di due mobo Amiga compatibili e questo in prospettiva alle effettive possibilità di "materializazione" di eventuale software facente uso delle poche facilities a disposizione di tali schede (piu avanti ti arriva lo scoop sulle pegasos che pare sia l'anello mancante di tante incomprensioni ).

Lo "scoop" in realtà lo conoscevo. Ne parlo meglio dopo. Comunque il discorso è andato più sul generale. Se ci limitiamo a parlare soltanto di quelle due macchine, si taglia un bel po' di roba.

Tanto per chit chat, mi riferivo al fatto che in quel periodo (vi erano anche dgli articoli su The Inquirer al rispetto se non ricordo male) sembrava guerra aperta, Intel sembrava avere un asso nella manica (larrabee appunto) da sfidare Nvidia ed in piu li ostacolava con le licenze, Nvidia rispose con le stazioni Tesla e la minaccia di creare super coputers senza il bisogno di intel e così via.
La cosa non è che si sia mai risanata.

E' stata risanata, invece, perché Intel ha pagato qualcosa come 1,6 miliardi di dollari a nVidia per la causa che c'era in corso, e quest'ultima può continuare a sviluppare chipset per i processori della prima (anche se non lo farà ormai), oltre alla possibilità da parte di Intel di accedere ai brevetti di nVidia.

In ogni caso sono questioni che non c'entrano col GP-GPU.

Intel il GP-GPU lo vede come un cazzotto in un occhio, non essendo produttore di tali chips spinge perche i medesimi risultino il meno meno indispensabili possibile ed Nvidia continua ad aggiungere in cuda caratteristiche sempre piu avanzate di general computing.

Invece proprio Intel sta creando delle soluzioni proprio per aggredire questo mercato. Vedi Larrabee, che addirittura voleva aggredire quello delle GPU, ma che ha fallito a causa delle dimensioni troppo elevate del core. Dalle sue ceneri è nata Knights Ferry, che si è correttamente posizionata proprio su GP-GPU computing.

Non vedo come sia possibile questa generalizzazione. Le GPU e le AVX hanno architetture molto diverse, sebbene in alcuni casi siano sovrapponibili.

Questa è la spiegazione che ho trovato al riguardo (fammi sapere se concordi con la medesima): "AVX and GPUs are very similar in operation especially in the case of nVidia and their 'scalar thread' approach.
A single AVX instruction does one operation on a set of registers in parallel.
That is exactly what Cuda does as well. Difference is mainly that Cuda takes the parallelism way further than just 4 or 8 registers.
A Cuda multiprocessor unit is basically like an uber-wide AVX unit on an Intel CPU.
The main difference is in how nVidia selects the instructions to execute next. It can have many instances of the same thread, and it uses a scoreboarding algorithm to keep track of which threads are ready for execution of the next instruction (all dependencies on previous instructions being resolved)."

In pratica mi sembra di capire che eccellono nel fare gli stessi tipi di calcolo ma il GPGPU (Cuda in questo caso) nelle sue ultime versioni e su processori potenti, lo fa molto meglio.

Che lo faccia molto meglio è ampiamente discutibile, perché dal discorso manca il contesto.

E' vero che le architetture sono simili, ma ci sono delle differenze non indifferenti. In particolare, Cuda, e le GPU in generale, sono fatte per carichi massicciamente paralleli, ma per i quali le latenze non sono importanti e, anzi, possono essere (e lo sono) molto elevate.

Per semplificare il discorso, la GPU lavora bene in locale, con la sua memoria e, soprattutto, all'interno del suo core. Ma per poter lavorare ha bisogno che la CPU le passi i dati, e che quest'ultima se li venga poi a riprendere. Si tratta di passaggi per i quali si perde già parecchio tempo di per sé, con velocità di un paio d'ordini di grandezza rispetto ai trasferimenti interni dei rispettivi chip. Senza contare poi la latenza elevata dovuta ai calcoli della GPU.

Per contro, un'unità SIMD lavora a strettissimo contatto con la CPU. Se alla CPU serve un calcolo dall'unità SIMD, le "passa" subito ciò che le serve e quello che deve fare, e quest'ultima procede molto velocemente, con latenze di pochi cicli di clock (per le operazioni più comuni).

Inoltre l'unità SIMD si può avvantaggiare dell'architettura del core della CPU; ad esempio, per le modalità d'indirizzamento verso la memoria, che può essere molto complessa; e l'accesso alla memoria ha una latenza inferiore rispetto a quello della medesima per la GPU, anche se la banda aggregata è molto più elevata per quest'ultima. E poi si possono usare i registri e in generale le istruzioni della CPU per aiutare nel calcolo dell'algoritmo in questione, altro fatto estremamente importante (la CPU per calcoli general purpose rimane imbattibile).

Il risultato è che per carichi medio-piccoli, o in ogni caso dove servono risultati molto velocemente, l'unità SIMD è di gran lunga preferibile rispetto a una GPU.

Ed è il motivo per cui Intel ha colto la palla al balzo con Larrabee, fornendo un'architettura molto innovativa (che mi sono divertito a studiare) che è in grado di cogliere il meglio di entrambi gli approcci, ma che NON è in grado di sostituire né la CPU né la GPU; infatti il suo target è il GP-GPU computing.

Spero che il discorso adesso sia più chiaro, e che CPU, GPU e GP-GPU (con Larrabee in particolare) abbiano la loro precisa collocazione.

Questo è un altro discorso, ma di estensioni SIMD ne sono presenti parecchie.

Chiaro, io piu che altro paragonavo OpenCL su AMD 4890 VS Altivec nel fare ad esempio video encoding.
Un PC linux ha la 4890 e ce l'abbiamo anche noi (magari con lo stesso codice open source) se invece andiamo su simd per CPU, il G4 ha l'altivec e il Sandy Bridge ha...una serie di cose che a elencarle tutte facciamo notte

C'è da dire che proprio per l'encoding video l'apposizione sezione integrata nella GPU di SandyBridge svolge un lavoro migliore di qualunque altra soluzione, inclusi CUDA di nVidia e OpenCL (OpenStream? Non ricordo bene come si chiama) di AMD.

In ogni caso parliamo di UN preciso algoritmo. Ce ne sono anche altri in cui le GPU sono papabili, ma, come dicevo, non puoi generalizzare e pensare che qualunque calcolo parallelo lo si possa spostare sulle loro spalle.

Questo se parli di server, e in ogni caso anche nel caso di server sono ormai comuni soluzioni con GPU integrata.

Nel settore embedded mobile c'è SEMPRE una GPU, anche di ottima potenza, che fa parte del sistema.
Quindi?

Era una battuta sul fatto che in alcuni settori la presenza di un unità vettoriale interna è fondamentale, in altri il GPGPU è piu quotato, in ogni modo qui stiamo all'OT dell OT (direi tutta la parte sopra) io concordo con te che avere tutte e due le componenti è ideale,

OK.

nel caso di Sam460 VS Peg2 però nessuna delle due è in queste condizioni.
Quindi una scelta (lo so sembra strano ma ti manca una info qui, scoop piu in basso ). Ma chi la vorrebbe fare poi una scelta? Meglio tutto no? X1000 e non se ne parla piu (e ti do pure l'Xmos incluso nel prezzo )

E' una macchina per pochi, che venderà qualche centinaio di unità. Non la prendo nemmeno in considerazione per quanto già detto: inutile sviluppare per un mercato così ristretto.

E' chiaro che quello è solo un trend per chi vuole vedere i film/youtube e usare facebook, senza acquistare una GPU dedicata.
AMD e nVidia stanno dimostrando che una GPU integrata non serve soltanto a questo.

Va beh spero che concordiamo almeno sul fatto che di roba tosta non se n'è vista ancora però (intendo che possa convincere un gamer o un ricercatore con necessità Cuda per es. a lasciar perdere la GPU)

Veramente proprio queste soluzioni con GPU integrata sono particolarmente appetibili, proprio perché rimuovono il collo di bottiglia rappresentato dal passaggio di dati con la CPU, che si trova "accanto".

La banda di memoria non è certo quella delle GPU, ma si può sempre migliorare (vedi le soluzioni quad channel per i server).

Il futuro è rappresentato dall'integrazione sempre più stretta di CPU e GPU. Infatti ci stanno puntando proprio tutti: Intel, AMD (da un pezzo) e nVidia...

Mi piacerebbe vedere in cosa consiste e in quali condizioni è stato effettuato il test.
Sta su Bitplane, test con lame senza Altivec (e qui parlavamo appunto delle potenzialità lisce).
Non ce l'ho e non l'ho trovato nemmeno online. In sintesi il dato quale sarebbe?

Che usando lame senza Altivec Sam460EX e Pegasos2 con OS4.1Update2 danno gli stessi risultati.

Quindi al più arriviamo alla parità in questo test? Non mi sembra nulla di esaltante, a questo punto.

Su Lame ne parlo direttamente con Lecta, visto che ha risposto sull'argomento e chiarito la questione.

Non mi sembra che un solo test (quello con Lame; Blender riporta dati contrastanti e va approfondito) possa essere preso come campione di validità universale. Statisticamente è una posizione decisamente debole.

Si dovrebbero fare molti test, con codice quanto più variegato possibile. Che poi è quello che fa SPEC.

Mah io rimango dell'idea che una scheda grafica non vada testata con 3Dmark ma con i giochi e lo stesso vale per le CPU, applicazioni, applicazioni e ancora applicazioni ( i sintetici non mi interessano in genere) anche se concordo con te sul fatto che una rosa di benchs piu ampia sia necessaria, vedremo...

Infatti ho chiesto altri test. Vedremo quando arriveranno.

Quel test è tutto da vedere, come già detto. Per il resto un G4 che passa da 800Mhz a 1Ghz ha un incremento del 25%, mentre un 460 che passa da 1Ghz a 1,15Ghz ha un incremento del 15%. Questo per il clock. A livello prestazionale prendendo QUEL risultato direi che il G4 non è messo affatto male.

Ti ricordo però che il G4 parte in svantaggio (non partono dallo stesso tempo per poi aumentare il clock, il G4 partiva in svantaggio di un po di secondi) cosa che alla fine potrebbe si far sempre vincere il G4 di qualcosa, ma potremmo parlare di "strappaggio dei capelli" (nota pratica indonesiana )? dai, sarebbe comunque una differenza noiosa.

Considerato che il G4 non viaggiava alla sua normale velocità, il dato è rilevante, specialmente se ti vai a vedere i risultati di questo processore a 1Ghz.

Il 460, anche "scalando" il risultato del 15%, rimane dietro...

Fermo restando che siamo a due soli benchmark, e nessuno in grado di migliorare la situazione di quest'ultimo processore.

Embè? Puoi dimostrare che QUALUNQUE algoritmo in cui sia possibile impiegare un'unità SIMD possa essere portato su una GPU e funzionare (molto) meglio?

Se hai in tasca questa dimostrazione, allora il futuro è quello che ho dipinto: torniamo alle CPU da Commodore 64, lasciando che le GPU facciano praticamente tutto.

Ma mi sembra poco realistico, come quadro, no?

Io potrei farti alcuni esempi in cui l'uso di un'unità SIMD permetta di ottenere prestazioni ben più elevate di qualunque GPU, anche superpompata.

Forse stai fondendo troppo l'unità simd con l'intero concetto di CPU. Se mi dici che la GPU non puo fare tutto quello che fa una CPU sono con te, ma se separi l'unità SIMD ti accorgi che fa le stesse cose del GPGPU e che quest'ultimo invece di "sostituire" la CPU, puo attuare come se fosse la sua unità simd (per esempio, immagina un cell dove invece di un array di SPU, vi siano centinaia e centinaia di CudaCores). Insomma non mischiamo le due cose, la CPU serve, GPGPU può attuare in sostituzione della Vector unit e fare molto meglio in tandem.

La situazione è quella che ho spiegato meglio sopra, ed è bene, appunto, non mischiare due cose così diverse.

Com'è bene non mischiare al discorso anche Cell, che non è una GPU, ma una soluzione più affine al binomio CPU-SIMD e, meglio ancora, Larrabee.

Non è necessario scrivere in assembly per sfruttare le unità SIMD. E' sufficiente utilizzare un buon compilatore, con eventualmente alcune direttive per indicare la presenza di dati vettoriali (se il compilatore non ce la fa a riconoscerli da solo).

Come detto concordo con i "soli due benchs", per il resto mi ha detto Andrea Palmatè al quale ho chiesto proprio questa cosa esplicitamente che lui non ha avuto gran fortuna con i compilatori a nostra disposizione (e Andrea è un programmatore esperto, specie con i giochi) magari roba come il compilatore professionale intel (che ho sentito essere un vero e proprio mostro) farà 1000 volte meglio, ma su amiga...no luck a detta di Andrea.

Intel ha uno dei migliori compilatori al mondo, infatti, ed è in grado di riconoscere automaticamente codice "vettorizzabile".

Compilatori come GCC non sono alla sua altezza, ma possono fare un discreto lavoro. Dipende anche da chi ha scritto il back-end per una particolare CPU; non c'è molta gente che lavora sui PowerPC ormai, ma qualcosa si può fare.

Non vedo perché, visto che tutt'ora vengono prodotte schede video AGP con GPU moderne (anche se si tratta ormai di una nicchia di mercato).

Ok questo è un dato che non hai quindi non mi stupisce la tua risposta (finalmente ecco lo scoop ): la Pegasos2 ha un problema tecnico che gli impedisce di inizializare le schede RadeonHD AGP (anche quelle PCI su bus semplici) e Bplan, contatta da Hans De Ruiter ha dato il 2 di picche a qualsiasi aiuto al riguardo.
La mobo non ha dunque a disposizione (nemmeno in Mos) schede che utilizzino il paradigma Unified Shader Units, solo roba fixed function che non puo essere usata per il GPGPU.(bella fregatura...)

Ne avevo sentito già parlare, come dicevo prima, se l'OpenFirmware della Peg2 non è in grado di inizializzare correttamente la GPU, questo lavoro lo può fare il s.o. che ha pieno accesso al suo hardware, ai suoi registri. Il punto è: c'è qualcuno che ha interesse a farlo? Se sì, la situazione può essere sbloccata, altrimenti tutto rimane com'è.

Fermo restando che è da chiarire quanto ha scritto divina sull'argomento.

Ciò non toglie che il GP-GPU è utilizzabile anche su schede AGP (anzi, mi pare ci siano anche schede PCI, tra l'altro).

Come futuro possessore di X1000 mi auguro che quelle 2 unità Altivec non stiano sempre a pettinare le bambole quindi che ti devo dire? se esce un sacco di software che le usa non sarò io a protestare. Resta da vedere cosa si potrà ottenere in AmigaOS con codice non "preparato" a mano (una volta si è lamentato anche un evangelista Mos, Crumb, della stessa cosa).
Poi per il resto adesso sai del problema della Pegasos.

Come dicevo sopra, ne dubito, visto che parliamo di poche macchine. Da sviluppatore è un mercato che non prenderei in considerazione.

Lasciamo alle GPU questo tipo di calcolo, per i quali sono molto versate.

Anche con l'altiveq la Peg2 non gestisce video FullHD, mentre è notizia recente l'introduzione a breve in Gallium/Mesa (solo per schede RadeonHD) dell'accelerazione video HW.
Mi sembra che il quadro cominci a farsi chiaro...

E' chiarissimo: se c'è gente che ci lavora, il supporto arriva. Altrimenti no. Infatti, come dici tu stesso, arriverà soltanto per le schede RadeonHD, quando da tempo Ati/AMD permette di accelerare il video, e idem per altri produttori.

Allo stesso modo, si potrebbe anche sbloccare la situazione della peg2, se ci fosse la volontà di farlo.

E questo non dimostra forse che ottimizzare a manina il codice usando l'assembly x86 è cosa alquanto rara? Dunque perché continui a tirare in ballo quest'architettura?

Perche kas1e ha trovato blocchi Assembler mentre cercava di portare Return to Castle Wolfenstein? (vero però)

Titolo di... 10 anni fa.

Con ciò non voglio dire che oggi non si utilizzi più l'assembly (x86) nei giochi, ma, come dicevo, è sempre più raro, perché non conviene perdere tempo con questo linguaggio così poco produttivo, alla luce delle scadenze e dei continui progressi della tecnologia (è più conviente aggiornare).

E, come tu stesso hai detto, chi glielo fa fare a spendere tempo per un centinaio di utenti? La situazione sarà la stessa delle peg2, visto che hanno venduto qualche centinaio di licenze.
Perché per X1000 e per peg2, alle stesse condizioni? Visti i precedenti, c'è di che dubitarne fortemente...

Qui i discorsi (lo avrai ormai capito) sono due, per la Peg non è un accanimento è che il supporto era previsto, hanno scoperto l'arcano, hanno contattato Bplan e due di picche.

Per l'X1000 spero sia un successone (ed è alla base dei progetti futuri) comunque tutti gli utenti Sam riceveranno Gallium quindi andrà ai seguenti utenti: Sam440, SamFlex (che sono molti piu di 100 ;-)) Sam460EX e AmigaOne X1000.
Per le altre facilities si parla del futuro di Amiga, quindi o si fermano o vanno avanti con l'SMP etc etc etc.

L'X1000 costerà molto, per cui non credo che venderà migliaia di pezzi. Penso sia abbastanza realistico aspettarsi un centinaio di pezzi venduti.

Per la peg2 mi sono già espresso. Per il resto, al solito, vedremo.

Il test come ho già spiegato in precedenza (ma ovviamente non c'è peggior sordo di chi non vuol sentire come hai dimostrato più volte e come dimostrerai di nuovo rispondendo ancora a questo mio post con le solite trite e ritrite argomentazioni che ormai posti a macchinetta su qualsiasi thread venga aperto su iksnet) nel test ho preso il minimo comune denominatore disponibile per le due piattaforme. Non avendo a disposizione una versione ottimizzata per Sam460 o preso lo stesso identico eseguibile e lo usato su entrambe le piattaforme, unico modo secondo me (ma ovviamente tu non conosci il significato della frase "secondo me" visto che spacci per verità assoluta tutto quello che scrivi) di poter vedere come si comportavano due piattaforme alle stesse condizioni di utilizzo.

OK, ti ringrazio per aver chiarito la questione, che finora mi era del tutto oscura, e ne approfitto per riportarti il mio (mio, eh!) punto di vista.

A mio avviso avresti potuto compilare LAME ottimizzato per la CPU della 460 (per quanto possibile, cioé se esiste un'apposita opzione per specificare il modello di CPU, oppure abilitando specifici flag del compilatore), per il G4 della peg2 eventualmente con e senza l'uso di Altivec.

Se non fossero stati disponibili i sorgenti, ma soltanto i binari, utilizzare lo stesso eseguibile sarebbe stato giocaforza necessario e, quindi, il confronto nasceva e moriva lì. Di Photoshop c'è un solo eseguibile: c'era poco da fare.

Ma utilizzare un software open source permette di ottenere binari ottimizzati per la specifica piattaforma, proprio perché è possibile intervenire sul compilatore a tal fine.

A maggior ragione se vogliamo confrontare due sistemi / processori diversi, in una nicchia di mercato di utenti abbastanza scafati e attaccati ai benchmark.

Il tutto sempre IMHO.

[Alblino]

Io pur non essedo un maniaco dei test mi sono fatto l'idea che la
CPU della 460 a 1150 mhz abbia la potenza bruta di un G4 700-800 mhz
senza altivec.
Poi dipende sempre con quali programmi usi nel caso di Lame
per comprimere un file in mp3 il tempo di codifica era uguale
in pratica (1 secondo di differenza).
Chiaro che la versione di Lame era neutra non usava le
istruzioni altivec e non aveva ottimizzazioni per la Cpu della 460.
Sarebbe utile fare qualche test di rendering con blender sotto
OS4.1 stessa versione sul Pegaso 2 e sulla Sam460 e vedere
quali risultati escono.
In questo caso blender sarebbe un programma neutro se
non usa le istruzioni altivec.

[andres]

io mi sono fatto l'idea che un sistema Sam460ex al top sarà globalmente più prestante di un Pegasos 2 quando AmigaOS supporterà le GPU moderne...

[Alblino]

io mi sono fatto l'idea che un sistema Sam460ex al top sarà globalmente più prestante di un Pegasos 2 quando AmigaOS supporterà le GPU moderne...

Questo è chiaro ,si dovrebbero vedere filmati in full hd a pieno schermo
senza problemi visto che viene usata maggiormente la GPU.
Tutto quello che sfrutterà gallium e le GPU delle schede grafiche sarà
buono.
Poi bisognerà vedere effettivamente cosa e quanto si potrà scaricare
sulla GPU.

[Alblino]

Volevo fare una domandina ma secondo voi quando arriverà
Gallium esiste la possibilità che giri Doom3 sulla Sam460?
Magari non al massimo ma limitato.

[TheKaneB]

Volevo fare una domandina ma secondo voi quando arriverà
Gallium esiste la possibilità che giri Doom3 sulla Sam460?
Magari non al massimo ma limitato.

Doom3 non è open source... e non penso che la Activision abbia la minima idea di portarlo su Amiga >:-D

[Alblino]

Volevo fare una domandina ma secondo voi quando arriverà
Gallium esiste la possibilità che giri Doom3 sulla Sam460?
Magari non al massimo ma limitato.

Doom3 non è open source... e non penso che la Activision abbia la minima idea di portarlo su Amiga >:-D

Ok nulla allora....

[Lecta]

A mio avviso avresti potuto compilare LAME ottimizzato per la CPU della 460 (per quanto possibile, cioé se esiste un'apposita opzione per specificare il modello di CPU, oppure abilitando specifici flag del compilatore), per il G4 della peg2 eventualmente con e senza l'uso di Altivec.

Se non fossero stati disponibili i sorgenti, ma soltanto i binari, utilizzare lo stesso eseguibile sarebbe stato giocaforza necessario e, quindi, il confronto nasceva e moriva lì. Di Photoshop c'è un solo eseguibile: c'era poco da fare.

Ma utilizzare un software open source permette di ottenere binari ottimizzati per la specifica piattaforma, proprio perché è possibile intervenire sul compilatore a tal fine.

A maggior ragione se vogliamo confrontare due sistemi / processori diversi, in una nicchia di mercato di utenti abbastanza scafati e attaccati ai benchmark.

Il tutto sempre IMHO.

Guarda la tua è un'obiezione sensata. Purtroppo quando ho fatto l'articolo non avevo a disposizione un ambiente di compilazione per la 460 e visti i tempi già tirati e il mio poco tempo a disposizione non ho avuto modo di procedere altrimenti. Non escludo però di seguire il tuo consiglio in un eventuale articolo futuro (magari quando uscirà l'update 3 che dovrebbe mettere fuori dalla "beta" quei pochi componenti del S.O. ancora tali...)

Ovvio che se qualcuno ha già una versione ottimizzata di lame per sam460 e vuole mandarmela sarò lieto fare il test e pubblicarlo qui.