Confronto fra i486 e Motorola 68000

[fek]

Originariamente inviato da fantoibed

Infatti dovrebbe farlo dinamicamente il sistema operativo (o la virtual machine) e non staticamente il compilatore...

Ma questo e' improponibile, come fa il sistema operativo ad analizzare tutto il codice che dev'essere eseguito mentre viene eseguito e riordinare le istruzioni per evitare gli stalli? Dovrebbe avere accesso alla CPU, in pratica dovrebbe fare la CPU, tanto vale che lo faccia la CPU.

[Correx]

Originariamente inviato da Hal2001

Masterizzatore 0,5X

il mio primo masterizzatore SCSI fu il glorioso (ho dei cd che durano ancora oggi) Philips CDD2000, che già era 2x, non ricordo gli 1X sul mercato , italiano almeno....

[Hal2001]

Originariamente inviato da Correx

il mio primo masterizzatore SCSI fu il glorioso (ho dei cd che durano ancora oggi) Philips CDD2000, che già era 2x, non ricordo gli 1X sul mercato , italiano almeno....

Il mio primo.. se mio si può definire ( ) fu invece un plextor 4X sempre scsi, 1.200.000

Ma avevamo bisogno di velocità

Fine OT

[fantoibed]

Originariamente inviato da fek

Ma questo e' improponibile, come fa il sistema operativo ad analizzare tutto il codice che dev'essere eseguito mentre viene eseguito e riordinare le istruzioni per evitare gli stalli? Dovrebbe avere accesso alla CPU, in pratica dovrebbe fare la CPU, tanto vale che lo faccia la CPU.

Invece è proprio questo che intendono fare, almeno stando a quanto si dice su arstechnica:
http://arstechnica.com/articles/paedia/cpu/cell-1.ars

Back to the future, or, what do IBM and Transmeta have in common?

It seems like aeons ago that I first covered Transmeta's unvieling of their VLIW Crusoe processor. The idea that David Ditzel and the other Transmeta cofounders had was to try and re-do the "RISC revolution" by simplifying processor microarchitecture and moving complexity into software. Ditzel thought that out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream had increased processors' microarchitectural complexity to the point where way too much die real-estate was being spent on control functions and too little was being spent on actual execution hardware. Transmeta wanted to move register renaming, instruction reordering and the like into software, thereby simplifying the hardware and making it run faster.

I have no doubt that Ditzel and Co. intended to produce a high-performance processor based on these principles. However, moving core processor functionality into software meant moving it into main memory, and this move put Transmeta's designs on the wrong side of the ever-widening latency gap between the execution units and RAM. TM was notoriously unable to deliver on the intitial performance expectations, but a look at IBM's CELL design shows that Ditzel had the right idea, even if TM's execution was off.

IBM's Cell embodies many of the "RISC redivivus" principles outlined above, but it comes at these concepts from a completely different angle. Like TM, IBM started out with the intention of increasing microprocessor performance, but unlike TM, simplifying processor control logic wasn't the magic ingredient that would make this happen. Instead, IBM attacked from the very outset the problem that TM ran headlong into: the memory latency gap. IBM's solution to the memory latency problem is at once both simple and complex. In its most basic form IBM's Cell does what computer architects have been doing since the first cache was invented — Cell moves a small bit of memory closer to the execution units, and lets the processor store frequently-used code and data in that local memory. The actual implementation of this idea is a bit more complicated, but it's still fairly easy to grasp.

[fek]

Originariamente inviato da fantoibed

Invece è proprio questo che intendono fare, almeno stando a quanto si dice su arstechnica:
http://arstechnica.com/articles/paedia/cpu/cell-1.ars

Quello che e' scritto in quell'articolo e' molto diverso dall'analizzare ogni singola istruzione mentre viene eseguita per allocarla nel punto giusto del flusso e nascondere le latenze, che e' cio' che fa una CPU out-of-order.

Anzi, non dice proprio nulla a riguardo. Parla semplicemente delle memorie private degli SPE, che devono essere programmate a manina e non dal Sistema Operativo: il loro uso dipende fortemente dall'algoritmo ed e' quindi in mano al programmatore.

[fantoibed]

Originariamente inviato da fek

Quello che e' scritto in quell'articolo e' molto diverso dall'analizzare ogni singola istruzione mentre viene eseguita per allocarla nel punto giusto del flusso e nascondere le latenze, che e' cio' che fa una CPU out-of-order.

Anzi, non dice proprio nulla a riguardo. Parla semplicemente delle memorie private degli SPE, che devono essere programmate a manina e non dal Sistema Operativo: il loro uso dipende fortemente dall'algoritmo ed e' quindi in mano al programmatore.

Leggi tutto. Ho messo in grassetto un passaggio fondamentale.
In pratica dice che le nelle attuali architetture CISC, l'out-of-order execution, register renaming, speculation, branch prediction, and other techniques for latency hiding and for wringing more instruction-level parallelism out of the code stream ha aumentato a dismisura la complessità dell'hardware tanto che una parte troppo grande del die viene sprecata per le funzioni di controllo rispetto a quella che si occupa dell'esecuzione delle istruzioni.
L'idea che sta alla base dell'architettura dei processori Transmeta e TheCell è quella che conviene spostare queste funzioni dall'hardware al software.
L'errore che è stato fatto con le CPU Transmeta e che ha compromesso le prestazioni dei loro processori è stato quello di ospitare questa parte software (core processor functionality) in RAM con tutti i problemi di latenza elevata che ne derivano.
TheCell riprende il concetto di base, ma intende risolvere il problema prestazionale legato alla latenza della RAM con lo stesso principio che ha portato anni fa' all'introduzione della cache nei processori, ovvero spostare una piccola parte di memoria più vicino alle unità di esecuzione in modo da consentire al processore di memorizzare codice e dati più usati in quella memoria locale. L'implementazione vera e propria è più sofisticata, ma la spiegazione rende l'idea.

A questo aggiungo una riflessione. Dato che il software che viene eseguito (codice+dati) non è altro che un flusso di informazioni e dato che TheCell è impareggiabile come stream processor, vuoi vedere che, se opportunamente programmato, riesce ad eseguire le funzioni di controllo in software più efficientemente di quanto una GP-CPU classica riesca a fare via hardware?

Edit: Aggiungo da questo paper (ma consiglio di leggere il documento per intero che è molto interessante):
http://www.hpcaconf.org/hpca11/paper...ssor_final.pdf

4.4. Software branch prediction
Whereas modern hardware branch prediction structures do not do well on performance per transistor, software branch prediction tends to be an inexpensive means to gain a substantial performance improvement. In order to support high-frequency deeply pipelined designs efficiently, a branch hint instruction, present in the code well before the actual branch instruction allows for “just in time” prefetching of the instructions at the branch target. In combination with loop unrolling and interleaving, compilers can achieve near optimal performance even on deeply pipelined high-frequency processors.

[fek]

Originariamente inviato da fantoibed

L'idea che sta alla base dell'architettura dei processori Transmeta e TheCell è quella che conviene spostare queste funzioni dall'hardware al software.
L'errore che è stato fatto con le CPU Transmeta e che ha compromesso le prestazioni dei loro processori è stato quello di ospitare questa parte software (core processor functionality) in RAM con tutti i problemi di latenza elevata che ne derivano.

Leggi meglio, il testo che hai quotato non dice quello che hai scritto ma dice che e' secondo quella filosofia e' meglio spostare quei transistor in ulteriori unita' parallele d'esecuzione, che nel caso del Cell sono unita' dedicate all'elaborazione in streaming non in general purpose.

ovvero spostare una piccola parte di memoria più vicino alle unità di esecuzione in modo da consentire al processore di memorizzare codice e dati più usati in quella memoria locale.

Che e' l'idea alla base delle cache da decine di anni a questa parte, non c'e' nulla di nuovo, se non l'interessante discorso sul fatto che non essendo una cache la memoria privata va caricata a mano dall'applicazione (non dal sistema operativo), pero' questo consente alle SPE di avere un modello di latenze perfettamente prevedibile che aiuta il compilatore (non il sistema operativo) a schedulare le istruzioni in maniera efficiente.

A questo aggiungo una riflessione. Dato che il software che viene eseguito (codice+dati) non è altro che un flusso di informazioni e dato che TheCell è impareggiabile come stream processor, vuoi vedere che, se opportunamente programmato, riesce ad eseguire le funzioni di controllo in software più efficientemente di quanto una GP-CPU classica riesca a fare via hardware?

Il codice e' un flusso, i dati non sempre, anzi, nella stragrande maggioranza delle operazione non lo e'. Le applicazioni general purpose sono soprattutto ricerche e gestione di strutture dati con pattern di accesso casuale in un largo working set (ordini di grandezza maggiore della memoria privata di un SPE); in una situazione simile l'applicazione (e non il Sistema Operativo) si trovera' a dover caricare e scaricare l'intera memoria privata potenzialmente ad ogni accesso alla memoria, perche' questo accesso non sara' potenzialmente vicino al precedente ma in una zona random del working set. Esempi di algoritmi di questo tipo: gestione del grafo di una scena 3d, rasterizzazione di poligoni texturizzati, Intelligenza Artificiale, qualunque tipo di database, compilatori, filesystem. Esempi di applicazioni in streaming: codifica/decodifica audiovideo.

Edit: Aggiungo da questo paper (ma consiglio di leggere il documento per intero che è molto interessante):
http://www.hpcaconf.org/hpca11/paper...ssor_final.pdf

Questo paper conferma quello che ho scritto: l'idea e' di spostare la schedulazione delle istruzioni a livello del compilatore (non del Sistema Operativo) sfruttando il modello di latenze fisso della memoria privata. Quest'idea e' ottima per le applicazioni in streaming, e' molto meno buona per applicazioni general purpose non in streaming dove il codice ha figure prestazionali diverse a seconda di quando e' eseguito e dei pattern d'accesso dei dati su cui e' eseguito, cosa che un compilatore non puo' ovviamente ottimizzare.

. In combination with loop unrolling and interleaving, compilers can achieve near optimal performance even on deeply pipelined high-frequency processors.

Compilatori, non il Sistema Operativo che non e' mai citato eseguire alcun tipo di analisi dinamica del flusso di istruzioni per riordinarne l'esecuzione. Sarebbe pura fantascienza, oltre che incredibilmente lento.

[fantoibed]

Originariamente inviato da fek

Leggi meglio, il testo che hai quotato non dice quello che hai scritto ma dice che e' secondo quella filosofia e' meglio spostare quei transistor in ulteriori unita' parallele d'esecuzione, che nel caso del Cell sono unita' dedicate all'elaborazione in streaming non in general purpose.

No. Rileggi.

Originariamente inviato da fek

Che e' l'idea alla base delle cache da decine di anni a questa parte, non c'e' nulla di nuovo, se non l'interessante discorso sul fatto che non essendo una cache la memoria privata va caricata a mano dall'applicazione (non dal sistema operativo), pero' questo consente alle SPE di avere un modello di latenze perfettamente prevedibile che aiuta il compilatore (non il sistema operativo) a schedulare le istruzioni in maniera efficiente.

No. Viene fatta dal software, non dall'applicazione. Prendi i Transmeta (società a cui Sony ha rilevato 100 ingegneri su 208 totali). Sui Crusoe ed Efficeon tale software (code morphing) è ad un livello inferiore a quello del Bios e del sistema operativo.

Originariamente inviato da fek

Il codice e' un flusso, i dati non sempre, anzi, nella stragrande maggioranza delle operazione non lo e'. Le applicazioni general purpose sono soprattutto ricerche e gestione di strutture dati con pattern di accesso casuale in un largo working set (ordini di grandezza maggiore della memoria privata di un SPE); in una situazione simile l'applicazione (e non il Sistema Operativo) si trovera' a dover caricare e scaricare l'intera memoria privata potenzialmente ad ogni accesso alla memoria, perche' questo accesso non sara' potenzialmente vicino al precedente ma in una zona random del working set. Esempi di algoritmi di questo tipo: gestione del grafo di una scena 3d, rasterizzazione di poligoni texturizzati, Intelligenza Artificiale, qualunque tipo di database, compilatori, filesystem. Esempi di applicazioni in streaming: codifica/decodifica audiovideo.

Ripeto. Le funzioni di reordering, register renaming, latency hiding, ecc.. vengono eseguite dal layer di code morphing sui Transmeta e probabilmente avverrà qualcosa di analogo sui Cell. L'architettura logica vista dai processori sarà probabilmente diversa da quella fisica...

Originariamente inviato da fek

Questo paper conferma quello che ho scritto: l'idea e' di spostare la schedulazione delle istruzioni a livello del compilatore (non del Sistema Operativo) sfruttando il modello di latenze fisso della memoria privata. Quest'idea e' ottima per le applicazioni in streaming, e' molto meno buona per applicazioni general purpose non in streaming dove il codice ha figure prestazionali diverse a seconda di quando e' eseguito e dei pattern d'accesso dei dati su cui e' eseguito, cosa che un compilatore non puo' ovviamente ottimizzare.
Compilatori, non il Sistema Operativo che non e' mai citato eseguire alcun tipo di analisi dinamica del flusso di istruzioni per riordinarne l'esecuzione. Sarebbe pura fantascienza, oltre che incredibilmente lento.

Si riferisce a compilatori "just in time", però, che saranno integrati nel sistema operativo oppure ad un layer ancor più basso come nei Transmeta.

Per ora si sa che le applicazioni non avranno accesso diretto alle SPE ma sarà il kernel linux a mettere a disposizione un layer di astrazione attraverso device drivers e system calls:
http://www.linuxtag.org/typo3site/fr...tml?talkid=156

[fek]

Originariamente inviato da fantoibed

No. Rileggi.

Si', ho riletto. Dice esattamente quello che ho detto io, non parla di code morphing o nulla di analogo (ovviamente perche' chi ha scritto quell'articolo e' molto preparato e non lo scriverebbe mai).

No. Viene fatta dal software, non dall'applicazione. Prendi i Transmeta (società a cui Sony ha rilevato 100 ingegneri su 208 totali). Sui Crusoe ed Efficeon tale software (code morphing) è ad un livello inferiore a quello del Bios e del sistema operativo.

Scusami, no. Gli algoritmi per scaricare e ricaricare la memoria privata dipendono dall'applicazione. Un filtro digitale carica il kernel del filtro e blocchi di dati, un compilatore caricherebbe una parte del sorgente e la tabella dei simboli, un grafo caricherebbe i nodi adiacenti. Dipende dall'applicazione.
Hai mai programmato qualcosa di analogo ad uno stream processor?

Ripeto. Le funzioni di reordering, register renaming, latency hiding, ecc.. vengono eseguite dal layer di code morphing sui Transmeta e probabilmente avverrà qualcosa di analogo sui Cell. L'architettura logica vista dai processori sarà probabilmente diversa da quella fisica...

E' tutto un probabilmente, sono piu' speranza che realta', al momento non e' neppure previsto nulla di simile. Pura fantascienza, per quanto ne so avrebbe la stessa valenza dire che l'analisi del codice verra' fatta da un alieno per via telepatica.
E come spiego dopo analizzare il codice mentre viene eseguito richiede istruzioni e tempo e sarebbe altamente inefficiente.

Si riferisce a compilatori "just in time", però, che saranno integrati nel sistema operativo oppure ad un layer ancor più basso come nei Transmeta.

No. Si sta riferendo ai compilatori, la parola just in time non appare in tutto il testo. Neppure il termine code morphing. Sono interpretazioni tue (sbagliate).

Per altro, anche se fosse just in time (che non e' un compilatore ma e' un traduttore), la traduzione del metodo viene effettuata ovviamente alla sua prima esecuzione, non ad ogni sua esecuzione, cosa che sarebbe oltremodo inefficiente.

Per ora si sa che le applicazioni non avranno accesso diretto alle SPE ma sarà il kernel linux a mettere a disposizione un layer di astrazione attraverso device drivers e system calls:
http://www.linuxtag.org/typo3site/f...html?talkid=156

Ho delle pre-release dell'SDK della PS3 e l'accesso diretto alle SPE e' garantito sia in assembly sia in un linguaggio ad alto livello.

Infatti il link che hai postato conferma esattamente quello che ho detto io fino ad ora:

The most important functions of the user interface including loading a program binary into an SPU, transferring memory between an SPU program and a Linux user space application and synchronizing the execution. Other challenges are the integration of SPU program execution into existing tools like gdb or oprofile.

Traduco: "Le funzioni piu' importanti dell'interfaccia verso l'utente includono il caricamento di un programma binario nella SPU, il trasferimento della memoria fra un programma nella SPU e lo spazio utente di Linux e la sincronizzazione dell'esecuzione".

Conferma quindi che queste funzioni sono a carico dell'utente e non del sistema operativo, come ho detto: dipendono dall'applicazione e non dal sistema operativo.

Da notare infine il paragrafo finale che toglie ogni dubbio sulla questione:

A model has been proposed to provide an interface that attempts to integrate well into the existing set of Linux system calls and enable software authors to easily integrate the use of SPUs into their own libraries and applications.

... che permettono agli autori del software di integrare l'uso delle SPE (SPU) nelle loro librerire e applicazioni, perche' evidentemente non puo' essere a solo carico del Sistema Operativo. Come ho detto fin dall'inizio: le SPU non vengono nascoste all'utente come affermi tu, ma vengono esposte all'utente per poterle utilizzare attraverso le system calls.

Direi che non c'e' altro da aggiungere a riguardo.

[jappilas]

Originariamente inviato da MadRat

Se metto un floppy con un dos dentro sul mio pc gira perfettamente e non in emulazione.. su un atari o un commodore non gira.. non mi pare che le infrastrutture siano poi cosi' cambiate..

forse lui si riferiva al fatto che si riesce ad avviare il DOS anche su un P4 o athlon attuale, e che il dos stesso non distingua la macchina dall' AT su cui veniva usato già negli anni 80...

ma in realtà questo accade perchè il p4: da un lato emula le istruzioni x86 a 16 bit, dall' altro la modalità reale
inoltre, cosa fondamentale, i bios moderni continuano a supportare il sistema a memoria base/estesa/espansa, lasciano come opzionale l' attivazione del gate a20, emulato nel chipset o via SW...
chipset che dal canto suo, va secondo me pensato come l' implementazione della "piattaforma" con il suo modello I/O, gli IRQ, eccetera...e la piattaforma che appunto costituisce, allo stato attuale è tutto sommato elegante (praticamente tutti i nuovi chipset di intel via, sis, sono "legacy free" basati su architetture crossbar...) e poco (magari l' interrupt controller e l' 8042 per la tastiera) ha a che vedere con gli antichi AT e le limitazioni ad esso imposte
in pratica, se MadRat volesse una piattaforma "nuova" e "fresca" gli basterebbe prendere un pc normale e installargli un firmware di tipo EFI: di suo questo è sostanzialmente legacy free essendo stato progettato da zero con l' obiettivo , tra l' altro, del cross-platforming (ia32, itanium, arm)... nella versione x86 è previsto un modulo di retrocompatibilità che implementi le chiamate del BIOS classico: non installando tale modulo ci lascia alle spalle la compatibilità DOS (ed anche la VGA col suo bios, infatti le specifiche EFI includono anche quelle per un nuovo tipo di firmware destinato alle schede di espansione come schede grafiche, controller scsi/raid, rete ecc)

Originariamente inviato da fek

Hai mai programmato qualcosa di analogo ad uno stream processor?

io no, in effetti non ho idea di cosa implichi e sono estremamente curioso

[fantoibed]

Originariamente inviato da fek

Si', ho riletto. Dice esattamente quello che ho detto io, non parla di code morphing o nulla di analogo (ovviamente perche' chi ha scritto quell'articolo e' molto preparato e non lo scriverebbe mai).

Io ho parlato di code morphing riferendomi a Transmeta non a Cell.

Originariamente inviato da fek

Scusami, no. Gli algoritmi per scaricare e ricaricare la memoria privata dipendono dall'applicazione. Un filtro digitale carica il kernel del filtro e blocchi di dati, un compilatore caricherebbe una parte del sorgente e la tabella dei simboli, un grafo caricherebbe i nodi adiacenti. Dipende dall'applicazione.
Hai mai programmato qualcosa di analogo ad uno stream processor?

In effetti no.

Originariamente inviato da fek

E' tutto un probabilmente, sono piu' speranza che realta', al momento non e' neppure previsto nulla di simile. Pura fantascienza, per quanto ne so avrebbe la stessa valenza dire che l'analisi del codice verra' fatta da un alieno per via telepatica.
E come spiego dopo analizzare il codice mentre viene eseguito richiede istruzioni e tempo e sarebbe altamente inefficiente.

E' una congettura, ma l'alleanza Sony/Transmeta e le similitudini di fondo tra le due tipologie di CPU (entrambe basate su in-order VLIW core) lascia ampio spazio a queste idee.
http://arstechnica.com/news.ars/post/20050401-4765.html
D'altra parte pare ormai certa l'implementazione di LongRun2 (parte integrante del layer di code morphing degli Efficeon)

Originariamente inviato da fek

No. Si sta riferendo ai compilatori, la parola just in time non appare in tutto il testo.

Se non è riferito ai compilatori, il “just in time” prefetching a chi sarebbe riferito?

Originariamente inviato da fek

Neppure il termine code morphing. Sono interpretazioni tue (sbagliate).

Non ho mai parlato di "code morphing" sui Cell, solo sui Transmeta. Casomai ho detto "qualcosa di analogo"...

Originariamente inviato da fek

Per altro, anche se fosse just in time (che non e' un compilatore ma e' un traduttore), la traduzione del metodo viene effettuata ovviamente alla sua prima esecuzione, non ad ogni sua esecuzione, cosa che sarebbe oltremodo inefficiente.

Perché la traduzione dovrebbe essere effettuata solo alla prima esecuzione?
Nei Transmeta non mi pare sia così...

Originariamente inviato da fek

Ho delle pre-release dell'SDK della PS3 e l'accesso diretto alle SPE e' garantito sia in assembly sia in un linguaggio ad alto livello.

Non ho a disposizione tali sdk quindi non posso che credere sulla parola.

Originariamente inviato da fek

Infatti il link che hai postato conferma esattamente quello che ho detto io fino ad ora:

Traduco: "Le funzioni piu' importanti dell'interfaccia verso l'utente includono il caricamento di un programma binario nella SPU, il trasferimento della memoria fra un programma nella SPU e lo spazio utente di Linux e la sincronizzazione dell'esecuzione".

Conferma quindi che queste funzioni sono a carico dell'utente e non del sistema operativo, come ho detto: dipendono dall'applicazione e non dal sistema operativo.

Hai tradotto giusto ma parafrasato male. L'interfaccia verso l'utente (come lo sono le API di windows) è una parte del sistema operativo e si prende carico lei del caricamento..., del trasferimento della memoria ... e della sincronizzazione dell'esecuzione. Se tutto ciò dovesse essere fatto dall'utente perché avrebbero creato un'interfaccia apposita?

Originariamente inviato da fek

Da notare infine il paragrafo finale che toglie ogni dubbio sulla questione:

... che permettono agli autori del software di integrare l'uso delle SPE (SPU) nelle loro librerire e applicazioni, perche' evidentemente non puo' essere a solo carico del Sistema Operativo. Come ho detto fin dall'inizio: le SPU non vengono nascoste all'utente come affermi tu, ma vengono esposte all'utente per poterle utilizzare attraverso le system calls.

Direi che non c'e' altro da aggiungere a riguardo.

Sì, ma non hanno certo scritto, come affermi tu, che tutte le singole operazioni sulle SPE devono essere effettuate "a manina". Esiste un'interfaccia dell'OS verso l'utente, esistono delle syscalls, ecc... Il fatto che il programmatore possa integrare l'uso delle SPE nel suo software in modo indiretto (basandosi sulle interfacce (API) del sistema operativo) o in modo diretto (programmandosele in asm) non cambia le carte in tavola...

[fek]

Originariamente inviato da fantoibed

Se non è riferito ai compilatori, il “just in time” prefetching a chi sarebbe riferito?

E' riferito al fatto che tutti gli accessi a memoria avvengono da e verso una memoria privata che ha latenze di prefetching dei dati fisse, mentre le latenze di una cache dipendono dal fatto che il dato sia in cache o meno. Questo permette al compilatore di avere una buona idea delle latenze al momento della compilazione del codice e puo' fare un buon lavoro (non ottimo) di schedulazione delle istruzioni.

Non ho mai parlato di "code morphing" sui Cell, solo sui Transmeta. Casomai ho detto "qualcosa di analogo"...

E qualcosa di analogo al code morphing che cos'e'?

Perché la traduzione dovrebbe essere effettuata solo alla prima esecuzione?
Nei Transmeta non mi pare sia così...

Perche' i JIT compiler funzionano cosi'.

Hai tradotto giusto ma parafrasato male. L'interfaccia verso l'utente (come lo sono le API di windows) è una parte del sistema operativo e si prende carico lei del caricamento..., del trasferimento della memoria ... e della sincronizzazione dell'esecuzione. Se tutto ciò dovesse essere fatto dall'utente perché avrebbero creato un'interfaccia apposita?

No, l'API si prende carico di esporre il caricamento e la sincronizzazione al programmatore, non decide che cosa caricare e quando caricare al posto del programmatore. Sarebbe come dire che le D3D esponendo l'API per renderizzare i triangoli si prende carico anche di decidere quali triangoli renderizzare e quando.
Il testo e' piuttosto chiaro su questo punto, impossibile fraintenderlo (se non volutamente).

Lo riquoto:

A model has been proposed to provide an interface that attempts to integrate well into the existing set of Linux system calls and enable software authors to easily integrate the use of SPUs into their own libraries and applications.

Il termine interfaccia e' piuttosto chiaro ed impossibile da fraintendere per chiunque ha programmato. API = Application Programming Interface.

Sì, ma non hanno certo scritto, come affermi tu, che tutte le singole operazioni sulle SPE devono essere effettuate "a manina".

Non ho mai affermato una cosa simile.
Ho affermato che il modello di programmazione del Cell prevede che il programmatore decide e programma a manina che cosa e quando caricare in memoria privata ed eseguire, un modello che funziona bene per calcoli in streaming, e non e' trasparente come il funzionamento di una cache che decide quando e che cosa caricare in memoria veloce in maniera del tutto trasparente al programmatore, cosa che funziona bene per applicazioni general purpose, ma non per applicazioni in streaming.

Mai affermato nulla di diverso da questo.

Come ti ho detto, il testo quotato e' conclusivo sull'argomento, non ci sarebbe bisogno di aggiungere altro sarebbe solo noioso spaccare il capello e rendere questa discussione totalmente illeggibile. Possiamo muoverci su un altro punto piu' interessante.

[fek]

Originariamente inviato da jappilas

io no, in effetti non ho idea di cosa implichi e sono estremamente curioso

L'idea e' avere un flusso di dati in entrata, eseguire una qualche trasformazione su di esso e scrivere un flusso di dati in uscita. In una situazione di questo tipo una cache e' perfettamente inutile perche' si basa sul principio di localita' degli accessi alla memoria (se ho letto in una zona X della memoria, presumibilmente continuero' a leggere quella zona anche in futuro).

Se entra un flusso di dati, se ho letto in una zona X, in futuro leggero' presumibilmente in una zona X + 1, poi X + 2, X + n e cosi' via. Una cache continuerebbe a caricare in memoria porzioni di memoria che non verranno mai usate.

In questa situazione e' piu' conveniente dividere il flusso in ingresso in blocchi, caricare il blocco di dati A in memoria privata, iniziare l'esecuzione del programma sul blocco di dati e in contemporanea caricare il blocco A + 1 in memoria parallelamente. In questa situazione lavori sempre su un blocco mentre carichi in memoria il successivo su cui lavorerai dopo. Il Cell aiuta il compilatore per il fatto che questa memoria privata sulla quale ogni SPE lavora ha una latenza di accesso fissa che non cambia (mi sembra 3 cicli), quindi come ho detto il compilatore e' in grado di usare le latenze per schedulare altre istruzioni non legate a quell'accesso a memoria.

[fantoibed]

Originariamente inviato da fek

E' riferito al fatto che tutti gli accessi a memoria avvengono da e verso una memoria privata che ha latenze di prefetching dei dati fisse, mentre le latenze di una cache dipendono dal fatto che il dato sia in cache o meno. Questo permette al compilatore di avere una buona idea delle latenze al momento della compilazione del codice e puo' fare un buon lavoro (non ottimo) di schedulazione delle istruzioni.

Ok. Ora mi è un po' più chiaro.

Originariamente inviato da fek

E qualcosa di analogo al code morphing che cos'e'?

Un layer software che si frapponga tra l'hardware e le applicazioni.

Originariamente inviato da fek

No, l'API si prende carico di esporre il caricamento e la sincronizzazione al programmatore, non decide che cosa caricare e quando caricare al posto del programmatore. Sarebbe come dire che le D3D esponendo l'API per renderizzare i triangoli si prende carico anche di decidere quali triangoli renderizzare e quando.

ok.

Originariamente inviato da fek

Ho affermato che il modello di programmazione del Cell prevede che il programmatore decide e programma a manina che cosa e quando caricare in memoria privata ed eseguire, un modello che funziona bene per calcoli in streaming, e non e' trasparente come il funzionamento di una cache che decide quando e che cosa caricare in memoria veloce in maniera del tutto trasparente al programmatore, cosa che funziona bene per applicazioni general purpose, ma non per applicazioni in streaming.

Ok. Ma a prescidere dalle congetture sulla possibile scelta o meno da parte di Sony/IBM/Toshiba di creare un layer di emulazione software, non pensi che creandolo si potrebbe emulare un'architettura diversa in modo efficiente con Cell? D'altra parte è il principio cardine dei processori Transmeta che sono anch'essi VLIW in-order core! Certamente le prestazioni dei transmeta non sono mai state esaltanti, ma si è già parlato dei limiti dovuti alla scelta di tenere in RAM il codice che implementa le funzioni di controllo a cui conseguono problemi di latenza, e poi le prestazioni non sono mai state l'obiettivo primario di Transmeta, visto che ha puntato tutto sulla riduzione dei consumi.
La similitudine con le cpu transmeta nell'idea di fondo e l'elevatissimo numero di istruzioni che Cell è in grado di eseguire per ogni ciclo di clock su registri SIMD mi fa pensare a Cell come una cpu in grado di rendere il massimo come emulatore di una CPU general purpouse.

Originariamente inviato da fek

Possiamo muoverci su un altro punto piu' interessante.

Ok, proponi. Mi hai già chiarito diversi dubbi e la discussione è già interessante così anche se non c'entra molto con 486 e motorola...

[fek]

Originariamente inviato da fantoibed

Un layer software che si frapponga tra l'hardware e le applicazioni.

E questo layer che cosa dovrebbe fare? Analizzare continuamente il flusso di istruzioni e riordinarlo, il lavoro che fa un'architettura OOO e la cosa ovviamente consuma cicli di clock, tanto vale farlo in software per applicazioni general purpose. Mentre per uno streaming processor e' giustissimo non farlo proprio, perche' non serve.

Ok. Ma a prescidere dalle congetture sulla possibile scelta o meno da parte di Sony/IBM/Toshiba di creare un layer di emulazione software, non pensi che creandolo si potrebbe emulare un'architettura diversa in modo efficiente con Cell?

No. Credo sarebbe altamente inefficiente.

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

[fantoibed]

Originariamente inviato da fek

E questo layer che cosa dovrebbe fare? Analizzare continuamente il flusso di istruzioni e riordinarlo, il lavoro che fa un'architettura OOO e la cosa ovviamente consuma cicli di clock, tanto vale farlo in software per applicazioni general purpose. Mentre per uno streaming processor e' giustissimo non farlo proprio, perche' non serve.

In un'architettura come quella di Cell il rischio è quello di sprecare unità di esecuzione non cicli di clock. Quel layer potrebbe preoccuparsi di parallelizzare threads e istruzioni, rinominare i registri, ecc... Con 8 unità di esecuzione il problema è quello di sfruttarle tutte, non di sprecare qualche ciclo di clock su una delle 8...

D'altra parte il minikernel contenuto nelle SPE potrebbe occuparsi anche di questo...
http://research.scea.com/research/ht...lGDC05/26.html ..e seguenti

Originariamente inviato da fek

Io credo che in informatica esistano degli strumenti ed ogni strumento serve per uno scopo. Il Cell e' evidentemente nato con lo scopo di essere un velocissimo streaming processor, un dsp intelligente, veloce, e poco costoso.
Forzarlo a diventare un general purpose, qualcosa che non e' stato progettato per fare, sarebbe altamente inefficiente rispetto all'uso di quei transistor con lo scopo di risolvere un'altra classe di problemi. Qualunque archiettura software si possa immaginare non aiuterebbe.

Boh, probabilmente hai ragione, ma non sono molto convinto...
Per ora si sa che la ps3 supporterà i giochi della ps1 e ps2 e che la stessa Sony parla di Virtual Machine (JIT) all'interno delle SPE:
http://research.scea.com/research/ht...lGDC05/51.html

[fek]

Originariamente inviato da fantoibed

In un'architettura come quella di Cell il rischio è quello di sprecare unità di esecuzione non cicli di clock. Quel layer potrebbe preoccuparsi di parallelizzare threads e istruzioni, rinominare i registri, ecc... Con 8 unità di esecuzione il problema è quello di sfruttarle tutte, non di sprecare qualche ciclo di clock su una delle 8...

Ma c'e' solo un'unita' che agisce da coordinate ed e' su quella che esegui le applicazione general purpose ed e' su quella che non devi sprecare cicli di clock perche' e' gia' lenta di suo.

A meno che tu non voglia implementare un algoritmo di ricerca in un grafo su una SPE caricando e scaricando parti del grafo dalla memoria privata ad ogni accesso. Oddio, e' teoricamente possibile, quando esce provaci e soprattutto prova a farlo andare veloce

Il problema non e' farcelo girare un algoritmo, il problema e' farcelo girare velocemente, o meglio altrettanto velocemente di come girerebbe su una CPU OOO a parti numero di transistor. Teoricamente una GPU e' perfettamente in grado di compilare un programma in C++. Prova a implementarlo pero'.

Sony parla di Virtual Machine (JIT) all'interno delle SPE:
http://research.scea.com/research/ht...lGDC05/51.html

"Will be". Sony parlava anche di far girare Toy Story in tempo reale sulla PS2. Finche' parlano...

[fantoibed]

Originariamente inviato da fek

Ma c'e' solo un'unita' che agisce da coordinate ed e' su quella che esegui le applicazione general purpose ed e' su quella che non devi sprecare cicli di clock perche' e' gia' lenta di suo.

Sono le SPE che caricano dalla memoria i propri job, li eseguono e salvano l'output in memoria ed eseguono il load/store molto più velocemente di quanto non possa fare la PPU.

Originariamente inviato da fek

A meno che tu non voglia implementare un algoritmo di ricerca in un grafo su una SPE caricando e scaricando parti del grafo dalla memoria privata ad ogni accesso. Oddio, e' teoricamente possibile, quando esce provaci e soprattutto prova a farlo andare veloce

Non è necessario. Le SPE possono accedere direttamente alla RAM.

Originariamente inviato da fek

Il problema non e' farcelo girare un algoritmo, il problema e' farcelo girare velocemente, o meglio altrettanto velocemente di come girerebbe su una CPU OOO a parti numero di transistor. Teoricamente una GPU e' perfettamente in grado di compilare un programma in C++. Prova a implementarlo pero'.

Esistono tecniche apposite per la gestione dei grafi sfruttando architetture parallele e SIMD.
http://citeseer.ist.psu.edu/hsu95implementation.html
http://portal.acm.org/citation.cfm?id=131274
http://portal.acm.org/citation.cfm?id=148046
http://ad.informatik.uni-freiburg.de...ngen/download/
....

[fek]

Originariamente inviato da fantoibed

Sono le SPE che caricano dalla memoria i propri job, li eseguono e salvano l'output in memoria ed eseguono il load/store molto più velocemente di quanto non possa fare la PPU.

Ma i job devono essere coordinati dalla PPU.

Non è necessario. Le SPE possono accedere direttamente alla RAM.

Molto lentamente e non e' piu' possibile sfruttare le latenze fisse.

Esistono tecniche apposite per la gestione dei grafi sfruttando architetture parallele e SIMD.

Esistono anche tecniche per implementare query di un database nella GPU.

Il problema non e' l'esistenza o meno delle tecniche, esistono; il problema e' inerente all'accedere casualmente un largo working set, cosa che le SPE non fanno in maniera efficiente. Ne parlammo gia' tempo fa.

[TNR Staff]

C'ho capito pochetto ,ma per quel che è la mia esperienza,vado particolarmente a braccetto con fek.

Quando ho letto un annetto fa che qualcuno voleva far eseguire ad una GPU delle applicazioni general purpose,mi è venuto da ridere

Quando poi ho letto i commenti degli utenti mi sono proprio capottato,è impensabile far eseguire un lavoro del genere ad una GPU,avrebbe prestazioni ridicole.

La stessa cosa imho vale per il Cell,è stato pensato per altri scopi,cercare di mettere delle "vie di mezzo" rallenta solo le cose (soprattutto quando le "vie di mezzo" sono software),anche perchè alla fine qualcuno deve pur elaborarle,a quel punto tanto vale affiancarci un altro processore,no?

Mi ricordo che già all'uscita delle istruzioni MMX nei Pentium si parlava di miracoli,miracoli che non ho visto (si parlava di spendere centinaia di migliaia di lire per un mmx,che sarebbe stato usato per "emulare" (male) una scheda audio da 30.000 lire)

Imho l'unica è aspettare,come ha detto fek secondo quanto disse la Sony,la ps2 doveva far girare Toy Story....l'unico Toy Story che gira su ps2 è il film,e quello gira pure su un cessoso lettore dvd