> E in questo le macchine intel sono generalmente sfigate, perche' si da > preferenza alla endianess usata in TCP/IP cioe' motorola. >
Si, lo so'. Il formato big e' piu' naturale, mentre il little e' piu' macchinoso. Per cui da questo punto di vista le cpu big-endian sono avvantaggiate. Storicamente Intel uso' il formato little, perche' era meno costoso. (le cpu little endian costavano meno come processo produttivo) > Comunuque non capisco la rilevanza di tutto cio' dal momento > che il plugin devi usarlo necessariamente sulla architettura > per il quale e' compilato. > Non conta la compilazione sulla architettura. Il fatto e' che se il file ECW che vuoi leggere usa little-endian per contenere i dati binari, nella macchina "big" occorre sempre leggere il dato e poi "ribaltarlo", questo implica un passaggio in piu' che allunga i tempi. ovviamente se i dati fossero salvati nell'ecw in "big" il discorso sarebbe all'inverso. Per cui e' importante ai fini della performance, anche sapere con quale piattaforma e' stato realizzato il file ECW (idem per i TIFF certamente). Le massime prestazioni si avrebbero quando si rilegge il file con la medesima piattaforma con cui e'stato creato. > PS: la 'maggiore potenza di calcolo' di ppc e' tutta da dimostrare > comunque, o parli di ppc64? No, anche di 32. Forse sono stato un po' precipitoso, il ppc e' in ribasso, ma secondo me in generale i RISC (e non il ppc specificamente) possono giocarsela alla pari con Intel, e anzi hanno buone prospettive di vincere. Tutto sta' a usare un buon compilatore ottimizzante. > > -- > Francesco P. Lovergine > -- ~~~~~~~~~~~~~~~~~ § Andrea § § Peri § ~~~~~~~~~~~~~~~~~ _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it.
