Dimenticavo una ovvieta' che tanto ovvia non e': plugin per Linux...
Scusa la domanda molto tecnica, ma e' comunque una questione interessante:
Trattandosi di un plugin per Linux, non e' scontata la piattaforma, per cui
mi interesserebbe sapere se e' funzionante solo sui Linux + processori Intel
o anche sui linux con altri tipi di processori.
La questione e' legata al fatto che Intel e' little-endian, mentre
altri sono big-endian.
A meno che non ci pensi l' SDK-ECW a gestire le differenze.
E in questo caso, per gestire tale differenza occorre ricompilare
oppure nel run-time e' gia' compreso il codice per
riconoscere e gestire la differenza tra "little" and "big" ?
Grazie,
Andrea.
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
On Wed, Jun 11, 2008 at 09:07:42AM +0200, Andrea Peri wrote:
>Dimenticavo una ovvieta' che tanto ovvia non e': plugin per Linux...
Scusa la domanda molto tecnica, ma e' comunque una questione interessante:
Trattandosi di un plugin per Linux, non e' scontata la piattaforma, per cui
mi interesserebbe sapere se e' funzionante solo sui Linux + processori Intel
o anche sui linux con altri tipi di processori.
Funziona per tutti, ovviamente compilando nativamente sulla piattaforma
relativa, quindi i386 o x86_64 sono ovviamente diverse e va fatta
la compilazione su ciascuna.
La questione e' legata al fatto che Intel e' little-endian, mentre
altri sono big-endian.
ECW e' endianess-independent AFAIK.
A meno che non ci pensi l' SDK-ECW a gestire le differenze.
E in questo caso, per gestire tale differenza occorre ricompilare
oppure nel run-time e' gia' compreso il codice per
riconoscere e gestire la differenza tra "little" and "big" ?
--
Francesco P. Lovergine
Per come conosco la questione io, per fare un endianess, occorre avere
due routines di lettura/scrittura, una per i "little" e l'altra per i
"big" e far decidere al processo in esecuzione quale impiegare.
Il difetto di questo metodo che' che quando avviene una elaborazione incrociata:
ovvero dato prodotto su una piattaforma, e dato visionato sull'altra'
, si osserva una maggiore lentezza, perche' ovviamente la routine di
trasformazione ntroduce un passaggio obbligato che allunga i tempi ,
dovendo ribaltare i bytes (anche se si parla di microsecondi l'enorme
mole di ribaltamenti che devono essere compiuti porterebbe a ritardi
consistenti).
Questo comporterebbe che ad esempio su un mac (power-pc) la visione
dell' ecw sarebbe molto piu' lenta che su un pc-intel.
Ovviamente la maggior potenza di calcolo del power-pc attenuerebbe
questa discrepanza.
Funziona per tutti, ovviamente compilando nativamente sulla piattaforma
relativa, quindi i386 o x86_64 sono ovviamente diverse e va fatta
la compilazione su ciascuna.
La questione e' legata al fatto che Intel e' little-endian, mentre
altri sono big-endian.
ECW e' endianess-independent AFAIK.
--
Francesco P. Lovergine
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
On Fri, Jun 13, 2008 at 09:04:22AM +0200, Andrea Peri wrote:
Per come conosco la questione io, per fare un endianess, occorre avere
due routines di lettura/scrittura, una per i "little" e l'altra per i
"big" e far decidere al processo in esecuzione quale impiegare.
Il difetto di questo metodo che' che quando avviene una elaborazione incrociata:
ovvero dato prodotto su una piattaforma, e dato visionato sull'altra'
, si osserva una maggiore lentezza, perche' ovviamente la routine di
trasformazione ntroduce un passaggio obbligato che allunga i tempi ,
dovendo ribaltare i bytes (anche se si parla di microsecondi l'enorme
mole di ribaltamenti che devono essere compiuti porterebbe a ritardi
consistenti).
Questo comporterebbe che ad esempio su un mac (power-pc) la visione
dell' ecw sarebbe molto piu' lenta che su un pc-intel.
Ovviamente la maggior potenza di calcolo del power-pc attenuerebbe
questa discrepanza.
Questo vale anche per TIFF che usa il formato motorola oppure intel
indifferentemente a seconda della piattaforma su cui viene creato il
file e su ciascuna piattaforma la libreria deve essere in grado di
trattare entrambi i tipi di file. La maggior parte dei formati comunque
definisce un solo tipo di endianess indipendentemente dalla piattaforma.
E in questo le macchine intel sono generalmente sfigate, perche' si da
preferenza alla endianess usata in TCP/IP cioe' motorola.
Comunuque non capisco la rilevanza di tutto cio' dal momento
che il plugin devi usarlo necessariamente sulla architettura
per il quale e' compilato.
PS: la 'maggiore potenza di calcolo' di ppc e' tutta da dimostrare
comunque, o parli di ppc64?
--
Francesco P. Lovergine
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 §
~~~~~~~~~~~~~~~~~