Ancora informazioni su Tiger

[Criceto]

Originariamente inviato da cdimauro

Vuoi dirmi che i driver per i sistemi 68K giravano tranquillamente sulle macchine PowerPC?

Sai che non mi ricordo?
Mi pare di sì, comunque.
Praticamente 1/2 OS è rimasto emulato per anni. Forse parte dell'ambiente Classic lo è ancora. Il bello è che l'emulazione era così efficiente che nemmeno te ne accorgevi (anzi i programmi 68K giravano più veloci sui nuovi PowerPC che sui più veloci 68040).

Perchè Win64 permetterà l'uso di driver a 32bit?
Avevo capito di no...

[Criceto]

Originariamente inviato da cdimauro

Chi ha scritto s.o. full 64 bit per i propri processori a 64 bit, come IBM, Sun, HP, ecc. non la pensa come te...

I server di fascia alta sono l'unica applicazione dove realmente possono servire i 64bit. E quelle macchine e OS da te citati sono tutte fatte per quel mercato.

Proprio per questo motivo non credo che Tiger sarà competitivo nel settore dei server.

Tiger non avrà nessuna limitazione in ambiente server dal suo approccio ai 64bit. I programmi server potranno tranquillamente essere scritti a 64 bit e il loro accesso potrà essere effettuato indifferentemente da applicazioni a 32 o a 64 bit.
E contemporaneamente si potrà far girare sulla macchina un qualsiasi applicativo a 32 bit (senza perdita di prestazioni).

Come vedi l'approccio Apple risulta sempre il migliore...

[cdimauro]

Originariamente inviato da Criceto
Quelli sono sistemi operativi dove è presente solo software iper-tecnico o con sorgente disponibile, e dove gli utenti non hanno grossi problemi a ricompilarsi a 64 bit le applicazioni che gli servono. Molto lontano da sistemi "consumer" come Mac o Windows...

Solaris conta una libreria con più di 10mila applicazioni, di cui ben poche disponibili come sorgenti. Solaris è disponibile per diverse piattaforme a 32 e 64 bit, anche per x86 e x86-64.
L'unica "pecca" è che non è molto diffuso.

Comunque Linux è abbastanza diffuso.

1 - Nessun problema. Chiami le routine di sistema per richiedere la memoria che vuoi. Il sistema operativo gestisce a 64 bit l'indirizzamento (fin da Panther).

Sì, ma serve un buffer di transito nello spazio di memoria a 32 bit, che verrà usato dal driver a 32 bit per leggere/scrivere i dati: si tratta di un passaggio in più rispetto a un driver a 64 bit che può direttamente leggere/scrivere i dati al/dall'indirizzo di memoria a 64 bit dell'applicazione.

I driver a basso livello, dove serve, sono implementati sia a 64bit che a 32 bit.

Mi puoi fornire dei link?

In ogni caso con tutti i driver a 32 bit già esistenti succederà quanto scritto sopra: complimenti per l'efficienza.

2- Se ci sono vantaggi prestazionali si compila MySQL ANCHE a 64 bit (facendo un fat binary), altrimenti è inutile perdere tempo e basta compilarlo a 32bit. MySQL è un server privo di interfaccia grafica e può essere compilato interamente a 64bit senza problemi.

Certo, ma non conosci a priori quali funzionalità di MySQL verranno usate: può essere che vengano usati poco i dati a 64 bit e molto quelli a 32 bit, e viceversa. Può essere che verranno usate macchine con più di 4GB di memoria perché dovrann gestire database molto grossi.
Quindi la soluzione migliore dovrebbe essere quella di fornire due compilati per MySQL, e dovrà essere l'utente, facendo delle prove a cercare di capire quale gli potrebbe fornire le prestazioni migliori.

3- Come sopra. L'algorimo JPEG è un programma ridotto che non necessita di interfaccia grafica. Si realizza come un classico binario Unix e si compila in FAT binary. L'accesso al programma dalle applicazioni viene fatto chiamando l'applicazione Unix, come viene tutt'ora per lo ZIP e altro.
Meglio ancora si fa un plug-in per QuickTime, se già non è presente, sempre in Fat-binary.

Qui la situazione è più felice rispetto a MySQL, perché il codice che fa uso dei 64 bit è localizzato in una parte ben precisa. Rimane il problema di compilare l'applicazione a 32 e 64 bit e testare quale si comporta meglio: la parte di codice a 64 si avvantaggerà in questa sezione, ma perderà in misura diversa nelle altre. Oltre a ciò, c'è da dire che a seconda dei dati dell'immagine certe sezioni di codice saranno più o meno usate rispetto alle altre.
Per avere un quadro completo bisognerebbe effettuare una serie di test con un campione abbastanza ampio e variegato di immagini, e trarne le conclusioni.

In tutti questi casi si ha accesso alla soluzione ottimale (prestazionalmente) sia dai G4 a 32bit che dai G5 a 64bit, in modo trasparente per l'utente.

La soluzione non è affatto ottimale, come puoi vedere.
Una soluzione migliore della compilazione a 32 o 64 bit sarebbe quella di analizzare i programmi e riconoscere quali parti potrebbero essere mantenute nell'applicazione a 32 bit e quali parti trasferire in un'applicazione a 64 bit: non è facile e sta interamente sulle spalle del programmatore.

Qualche esempio più difficile?

Hai tratto delle conclusioni un po' affrettate: la situazione non è semplice come credevi...

[cdimauro]

Originariamente inviato da Criceto
Sai che non mi ricordo?
Mi pare di sì, comunque.
Praticamente 1/2 OS è rimasto emulato per anni. Forse parte dell'ambiente Classic lo è ancora. Il bello è che l'emulazione era così efficiente che nemmeno te ne accorgevi (anzi i programmi 68K giravano più veloci sui nuovi PowerPC che sui più veloci 68040).

Dipendeva dalle applicazioni: i primi PowerPC non erano abbastanza veloci in generale. Con le successive versioni (e frequenze di clock) le cose sono migliorate.

Perchè Win64 permetterà l'uso di driver a 32bit?
Avevo capito di no...

No, infatti: richiede l'uso di driver a 64 bit.

[cdimauro]

Originariamente inviato da Criceto
I server di fascia alta sono l'unica applicazione dove realmente possono servire i 64bit. E quelle macchine e OS da te citati sono tutte fatte per quel mercato.

I 64 bit non servono solo per quel tipo di applicazioni: anche MySQL e JPEG 2000 ne fanno uso, come ho già scritto, e non si tratta di applicazioni di fascia alta.

Tiger non avrà nessuna limitazione in ambiente server dal suo approccio ai 64bit. I programmi server potranno tranquillamente essere scritti a 64 bit e il loro accesso potrà essere effettuato indifferentemente da applicazioni a 32 o a 64 bit.
E contemporaneamente si potrà far girare sulla macchina un qualsiasi applicativo a 32 bit (senza perdita di prestazioni).

Vedi messaggio precedente: la situazione non è così semplice.

Come vedi l'approccio Apple risulta sempre il migliore...

Oltre a quanto scritto prima, rimane sempre il problema dei driver, che faranno da collo di bottiglia, specialmente con macchine con più di 4GB.

[Criceto]

Originariamente inviato da cdimauro
Sì, ma serve un buffer di transito nello spazio di memoria a 32 bit, che verrà usato dal driver a 32 bit per leggere/scrivere i dati: si tratta di un passaggio in più rispetto a un driver a 64 bit che può direttamente leggere/scrivere i dati al/dall'indirizzo di memoria a 64 bit dell'applicazione.

Non ho capito dove vuoi arrivare. Il filesystem è a 64 bit per tutti, l'indirizzamento è a 64bit per i G5 (cioè quando possibile). Cos'è che vorresti poter fare, indirizzare 64bit con un G4?! Accedere direttamente al disco o alla memoria senza passare per l'OS? (questo no, non lo puoi fare).

Mi puoi fornire dei link?

Falla tu la ricerchina su developer.apple.com. Da qualche parte c'è scritto.

Certo, ma non conosci a priori quali funzionalità di MySQL verranno usate: può essere che vengano usati poco i dati a 64 bit e molto quelli a 32 bit, e viceversa. Può essere che verranno usate macchine con più di 4GB di memoria perché dovrann gestire database molto grossi.
Quindi la soluzione migliore dovrebbe essere quella di fornire due compilati per MySQL, e dovrà essere l'utente, facendo delle prove a cercare di capire quale gli potrebbe fornire le prestazioni migliori.

Quella di compilare, o meno, un'applicazione a 64bit è una decisone che spetta al produttore del software, non certo all'utilizzatore finale.
Lo sviluppatore si farà i suoi profiling e deciderà lui se implementare o meno una versione a 64bit.
Con Win, invece, per scegliere una versione o l'altra devi cambiare sistema operativo!

La soluzione non è affatto ottimale, come puoi vedere.
Una soluzione migliore della compilazione a 32 o 64 bit sarebbe quella di analizzare i programmi e riconoscere quali parti potrebbero essere mantenute nell'applicazione a 32 bit e quali parti trasferire in un'applicazione a 64 bit: non è facile e sta interamente sulle spalle del programmatore.

Volendo, e scomponendo il programma in più processi distinti, su Tiger uno sviluppatore attento alle prestazioni potrebbe farlo. Con l'approccio di Windows no. Qual'è il limite di Tiger?

Hai tratto delle conclusioni un po' affrettate: la situazione non è semplice come credevi...

Mi sembra che sei tu che non capisci che l'approccio ai 64bit di Apple è il migliore possibile, non un compromesso.

[cdimauro]

Originariamente inviato da Criceto
Non ho capito dove vuoi arrivare. Il filesystem è a 64 bit per tutti, l'indirizzamento è a 64bit per i G5 (cioè quando possibile). Cos'è che vorresti poter fare, indirizzare 64bit con un G4?! Accedere direttamente al disco o alla memoria senza passare per l'OS? (questo no, non lo puoi fare).

Non sto parlando di FileSystem né di un G4 che chiaramente non può indirizzare la memoria a 64 bit: sto parlando un generico driver a 32 bit a cui viene fatta una richiesta. Poiché questo driver riceve puntatori a 32 bit per le applicazioni a 64 bit che fanno richiesta dei suoi servizi, sarà necessario un buffer "di transito" per far comunicare i due software, mentre con driver a 64 bit non c'è alcun problema.

Falla tu la ricerchina su developer.apple.com. Da qualche parte c'è scritto.

C'è un solo link che parla di Tiger in quella pagina: http://developer.apple.com/macosx/ti...html?headlines che a sua volta riporta un solo link utile per gli sviluppatori http://developer.apple.com/macosx/tiger/index.html e che non parla di driver a 64 bit per Tiger. Anzi, dice questo: "For example, there is only one version of the kernel for all Apple hardware" il che lascia presagire l'assenza di driver a 64 bit. Infatti finora ho sempre e soltanto sentito parlare di applicazioni a 64 bit.

Quella di compilare, o meno, un'applicazione a 64bit è una decisone che spetta al produttore del software, non certo all'utilizzatore finale.
Lo sviluppatore si farà i suoi profiling e deciderà lui se implementare o meno una versione a 64bit.

Allora non hai capito bene: non è detto che la sua scelta sarà quella più azzecata per le esigenze dell'utente finale!

Con Win, invece, per scegliere una versione o l'altra devi cambiare sistema operativo!

Per le macchine a 32 bit c'è soltanto Windows XP disponibile, mentre per quelle a 64 bit si potrà scegliere fra la versione a 32 o 64 bit (quest'ultima sarà da preferire, chiaramente): non vedo tutte queste differenze...

Volendo, e scomponendo il programma in più processi distinti, su Tiger uno sviluppatore attento alle prestazioni potrebbe farlo.

Potrebbe, ma come ti ho detto non è affatto facile.

Con l'approccio di Windows no.

Con Windows compili a 32 bit per XP a 32 bit e a 64 bit XP a 64 bit: mi sembra decisamente più semplice, no?

Qual'è il limite di Tiger?

L'essere un ibrido, appunto, con le conseguenze di cui ho già parlato ampiamente.

Mi sembra che sei tu che non capisci che l'approccio ai 64bit di Apple è il migliore possibile, non un compromesso.

Dal punto di vista del minimo lavoro per Apple e della maggior compatibilità col passato, sicuramente sì.
Ma questo è UN punto di vista: per il resto ho già spiegato quali sono i limiti di quest'approccio...

[Criceto]

Originariamente inviato da cdimauro
Non sto parlando di FileSystem né di un G4 che chiaramente non può indirizzare la memoria a 64 bit: sto parlando un generico driver a 32 bit a cui viene fatta una richiesta. Poiché questo driver riceve puntatori a 32 bit per le applicazioni a 64 bit che fanno richiesta dei suoi servizi, sarà necessario un buffer "di transito" per far comunicare i due software, mentre con driver a 64 bit non c'è alcun problema.

Le richieste di memoria passano per l'OS. E l'OS sa cosa fare, sia nel caso abbia sotto sotto un G4 o un G5. Sia che abbia 256MB o 8 GB. Non penso che il caso da te citato sia possibile.

C'è un solo link che parla di Tiger in quella pagina: http://developer.apple.com/macosx/ti...html?headlines che a sua volta riporta un solo link utile per gli sviluppatori http://developer.apple.com/macosx/tiger/index.html e che non parla di driver a 64 bit per Tiger. Anzi, dice questo: "For example, there is only one version of the kernel for all Apple hardware" il che lascia presagire l'assenza di driver a 64 bit. Infatti finora ho sempre e soltanto sentito parlare di applicazioni a 64 bit.

Forse la memoria viene gestita tramite una kernel extension. Cioè un plug-in del kernel. La maggior parte (o tutti?) i drivers sono fatti in questo modo. Prova a vedere cosa dice l'I/O Kit, se sei proprio curioso... Non ti saprei dire con precisione come funziona la cosa. Ma devono esserci necessariamente drivers differenti (o FAT) per i G4 e per i G5 per quanto riguarda la gestione della memoria. E questo già in Panther.

Con Windows compili a 32 bit per XP a 32 bit e a 64 bit XP a 64 bit: mi sembra decisamente più semplice, no?

Forse per lo sviluppatore. Meno per l'utente che si trova davanti 2 versioni di Windows e non sa quale comprare. Peggio, con probabilità sceglierà la più nuova e pubblicizzata a 64bit non sapendo ai problemi che va incontro...

L'essere un ibrido, appunto, con le conseguenze di cui ho già parlato ampiamente.

Mantenere compatibilità con il passato e ALLO STESSO tempo poter utilizzare la versione dell'applicativo ottimale, mi sembra una gran bel compromesso!!

[cdimauro]

Originariamente inviato da Criceto
Le richieste di memoria passano per l'OS. E l'OS sa cosa fare, sia nel caso abbia sotto sotto un G4 o un G5. Sia che abbia 256MB o 8 GB. Non penso che il caso da te citato sia possibile.

Ti ho semplicemente esposto il funzionamento dei driver a 32 bit. E' chiaro che la gestione della memoria passa dal s.o. (ci mancherebbe), ma nel caso in cui sia un'applicazione a 64 bit a richiedere un servizio a un driver (a 32 bit), si va incontro ai problemi che ho esposto. E' chiaro che questi problemi li risolve il s.o. (è lui che provvede a ricopiare i buffer dal "mondo" a 64 bit a quello a 32 bit e a viceversa), ma è il prezzo da pagare.

Forse la memoria viene gestita tramite una kernel extension. Cioè un plug-in del kernel. La maggior parte (o tutti?) i drivers sono fatti in questo modo. Prova a vedere cosa dice l'I/O Kit, se sei proprio curioso...

Non credo che sia quello il caso. Un driver o funziona con puntatori a 64 bit o con puntatori a 32 bit: non ci sono altre possibilità.

Non ti saprei dire con precisione come funziona la cosa. Ma devono esserci necessariamente drivers differenti (o FAT) per i G4 e per i G5 per quanto riguarda la gestione della memoria. E questo già in Panther.

Questo succede esclusivamente per una questione di ottimizzazione del codice, perché le due architetture sono differenti. Ma l'ISA rimane la stessa, per cui il modello non cambia (quello dei driver è e rimane sempre un ambiente a 32 bit, con puntatori a 32 bit)

Forse per lo sviluppatore. Meno per l'utente che si trova davanti 2 versioni di Windows e non sa quale comprare. Peggio, con probabilità sceglierà la più nuova e pubblicizzata a 64bit non sapendo ai problemi che va incontro...

Il discorso, invece, mi sembra abbastanza chiaro: con macchine a 64 bit sarà consigliato a venduto XP a 64 bit, che potrà far girare tranquillamente software a 32 o 64 bit.
L'unico problema starebbe nell'eventualità che un utente con Windows a 32 bit (e quindi macchina a 32 bit) compri un programma per XP/64 e provi a farlo girare.

Mantenere compatibilità con il passato e ALLO STESSO tempo poter utilizzare la versione dell'applicativo ottimale, mi sembra una gran bel compromesso!!

Il problema è che l'applicativo non è ottimale: è tutto lì il problema! Non puoi decidere a priori quale applicativo funzionerà bene: quest'onere se lo dovrà accollare l'utente, non lo sviluppatore, perché quest'ultimo al più fornirà le due versioni del software (e quella a 64 bit sarà una semplice ricompilazione, perché l'analisi e la separazione del codice a 32 e 64 bit richiede non poco tempo) e basta.

[Criceto]

Originariamente inviato da cdimauro
Il problema è che l'applicativo non è ottimale: è tutto lì il problema! Non puoi decidere a priori quale applicativo funzionerà bene: quest'onere se lo dovrà accollare l'utente, non lo sviluppatore, perché quest'ultimo al più fornirà le due versioni del software (e quella a 64 bit sarà una semplice ricompilazione, perché l'analisi e la separazione del codice a 32 e 64 bit richiede non poco tempo) e basta.

L'approccio di Tiger ai 64 bit E' ottimale. Decidere se vale la pena o no avere una versione a 64bit è compito dello sviluppatore, NON DELL'UTENTE.

Tiger lascia la libertà di scelta, con un unico OS, di avere applicativi sia a 32bit che a 64bit, entrambi NATIVI (non girano sotto una qualche modalità ridotta o in un ambiente di emulazione come su x86) quindi SENZA PENALIZZAZIONI.

Con Windows devi scegliere di avere un OS tutto a 32bit o un OS tutto a 64bit, in entrambi i casi ci saranno applicativi che girano in modo non ottimale (la situazione peggiore la vedo per Win64). In più in Win64 si perde la compatibilità con i driver a 32bit, cioè la maggior parte delle periferiche non funzioneranno per lungo tempo (e molte mai) sul nuovo OS.

Come fai a sostenere che l'approccio di Windows sia migliore, non lo capisco proprio...

[cdimauro]

Originariamente inviato da Criceto
L'approccio di Tiger ai 64 bit E' ottimale.

Non lo è. Te lo rispiego sotto.

Decidere se vale la pena o no avere una versione a 64bit è compito dello sviluppatore, NON DELL'UTENTE.

Indubbiamente. Quando sono disponibili entrambe le versioni, la scelta dei due però non è scontata e sarà l'utente a doverla fare, a seconda dell'uso che ne farà.

Tiger lascia la libertà di scelta, con un unico OS, di avere applicativi sia a 32bit che a 64bit, entrambi NATIVI (non girano sotto una qualche modalità ridotta o in un ambiente di emulazione come su x86) quindi SENZA PENALIZZAZIONI.

E' qui che sbagli: le penalizzazione ci sono per le applicazioni a 64 bit.

L'approccio di Tiger non penalizza le applicazioni a 32 bit e non richiede la riscrittura dei driver, perché Apple ha deciso di fare il minimo sforzo per la creazione di questo s.o.: rappresenta, quindi, la soluzione ottimale, solo per questo tipo di applicazioni.

Le applicazioni a 64 bit saranno penalizzate a causa:
- del meccanismo di scambio di messaggi fra applicazione a 32 bit (per la GUI) e quella a 64 bit, necessario per fale comunicare;
- dei driver a 32 bit, che richiederanno l'uso di un buffer di "transito" per le zone di memoria dell'applicazione a 64 bit (le applicazioni a 32 bit non ne hanno bisogno, perché lo spazio d'indirizzamento è in comune con i driver, perché entrambi usano puntatori a 32 bit).

A ciò aggiungiamo la difficoltà di suddividere il codice a 32 bit da quello a 64 bit, per cui la via "preferita" dagli sviluppatori sarà quello di compilare un'applicazione interamente a 32 o 64 bit, penalizzando queste ultime perché del codice che potrebbe essere eseguito a 32 bit (più velocemente) sarà eseguito a 64 bit (con ciò intendo utilizzando puntatori a 64 bit).

Con Windows devi scegliere di avere un OS tutto a 32bit o un OS tutto a 64bit,

Windows è l'ultimo s.o. ad aver seguito quest'approccio. Anzi, possiamo dire che Tiger è forse l'unico s.o. "ibrido" a 64 bit...

in entrambi i casi ci saranno applicativi che girano in modo non ottimale (la situazione peggiore la vedo per Win64).

Il problema è che tu confondi il passaggio da 32 a 64 bit per le due architetture (PowerPC e x86), che è nettamente diverso: x86-64 OLTRE a estendere registri e indirizzamento a 64 bit (cosa che accade passando da G4 a G5), AGGIUNGE anche diverse altre caratteristiche nell'ISA che permettono di migliorare le prestazioni.

Windows XP/64, come qualunque altro s.o. per x86-64, presenta driver e a API a 64 bit, che traggono vantaggio proprio di queste nuove caratteristiche, permettendo un miglioramento delle prestazioni medio del 15-20% (nell'esecuzione del codice di queste API e dei driver). Questo a livello di s.o. e driver.

A livello di applicazioni ci sono due casi diversi a seconda che se ne esegua una a 64 bit e una a 32 bit; nel primo caso, il codice dell'applicazione avrà un miglioramento medio del 15-20%; nel secondo caso, invece, l'esecuzione del codice dell'applicazione a 32 bit è la stessa che si avrebbe all'interno di Window XP (a 32 bit), con il vantaggio, però, che le chiamate alle API del s.o. o ai servizi dei driver si traduce nell'esecuzione non di codice a 32 bit, ma di codice a 64 bit, e che quindi si avvantaggia delle nuove caratteristiche di x86-64.

Questo perché con le applicazioni a 32 bit non c'è nessun tipo di emulazione, come erroneamente riporti tu: il codice viene eseguito allo stesso modo in cui un processore a 32 bit girerebbe all'intero di un s.o. a 32 bi.t

In più in Win64 si perde la compatibilità con i driver a 32bit, cioè la maggior parte delle periferiche non funzioneranno per lungo tempo (e molte mai) sul nuovo OS.

Questo, come ti ho già detto, si è già verificato col passaggio da Windows 9x a Windows 2000/XP: inizialmente per questi ultimi s.o. ci sono stati pochi driver, ma in poco tempo il supporto è arrivato, e da qualche anno il supporto maggiore è riservato a questi s.o. (alcune periferiche non hanno driver per Windows 9x).

MS avrebbe potuto adottare un meccanismo simile a quello di Tiger, quindi permettendo di usare i "vecchi" driver a 32 bit, ma ciò avrebbe penalizzato le prestazioni del s.o. e delle applicazioni a 64 bit, oltre al fatto che avrebbe spinto i produttori a continuare a sviluppare driver a 32 bit, senza curarsi di farne altri (migliori e più performanti) a 64 bit...

Come fai a sostenere che l'approccio di Windows sia migliore, non lo capisco proprio...

Spero che dopo questo messaggio finalmente lo capirai: perché Windows, come QUALUNQUE altro s.o. per x86-64, è una soluzione senza compromessi di alcun tipo, che non penalizza in alcun modo le applicazioni a 64 bit, come invece fa Tiger.

D'altra parte, come per tutte le cose, ci sono pregi e difetti nell'adozione della soluzione. Il pregio di Tiger è che non è un taglio netto col passato, e che ha richiesto ad Apple (e agli sviluppatori di driver) il minimo sforzo per abilitare l'uso dell'architettura a 64 bit dei G5. Per contro, le applicazioni a 64 bit sono penalizzate da quest'approccio.

Chiaro?

[Criceto]

Perdita di compatibilità e biforcazione del sitema operativo per non avere nessuna feature in più (se non per server/workstation di fascia molto alta) e per avere in casi ottimali un 20% di prestazioni in più (4 mesi di sviluppo dei processori, secondo la legge di Moore).
In più c'è LongHorn quasi dietro l'angolo (altre 2 biforcazioni?).

Mi sembra che il gioco non valga la candela per Windows 64.

Viceversa su Tiger i 64 bit saranno utilizzati solo dove ci sono reali benefici (senza le penalizzazioni che tu citi, che sono ridicole) e soprattuto in modo del tutto trasparente per l'utilizzatore e senza alcuna perdita di compatibilità.

Apple è la prima con questo approccio ai 64bit?
Apple è stata la prima a cambiare processore ad un OS in modo praticamente indolore.
Apple è stata la prima a cambiare OS ad una piattaforma hardware, in modo QUASI indolore.
Apple sarà la prima ad avere un OS ibrido 32/64bit che riunisce i VANTAGGI di entrambe le modalità senza assumerne i DIFETTI.

Apple è sempre la prima in tutto, sono gli altri che la copiano.

[cdimauro]

Originariamente inviato da Criceto
Perdita di compatibilità e biforcazione del sitema operativo per non avere nessuna feature in più (se non per server/workstation di fascia molto alta) e per avere in casi ottimali un 20% di prestazioni in più (4 mesi di sviluppo dei processori, secondo la legge di Moore).
In più c'è LongHorn quasi dietro l'angolo (altre 2 biforcazioni?).

Mi sembra che il gioco non valga la candela per Windows 64.

Il gioco vale la candela perché il 15-20% è l'aumento MEDIO di prestazioni, quindi "generalizzato". In casi ottimali si è superato anche il 100% di prestazioni in più (con MiniGzip. )

Viceversa su Tiger i 64 bit saranno utilizzati solo dove ci sono reali benefici (senza le penalizzazioni che tu citi, che sono ridicole)

Come in tutte le cose, dipende al contesto: saranno ridicole nei casi migliori, in cui ci saranno pochi passaggi di buffer fra applicazioni a 64 bit e driver e pochi messaggi scambiati fra il codice a 32 bit e quello a 64 bit di un'applicazione, ma tutt'altro che ridicoli in caso contrario.

e soprattuto in modo del tutto trasparente per l'utilizzatore e senza alcuna perdita di compatibilità.

Non è affatto vero che verranno usati dove ci sono reali benefici: questo succederà SE gli sviluppatori perderanno tempo a suddividere il codice a 32 bit da quello a 64 bit, come ho già detto.
Non so tu, ma al posto loro lascerei perdere e mi limiterei a fornire l'applicazione compilata interamente a 32 bit o 64 bit.

Apple è la prima con questo approccio ai 64bit?
Apple è stata la prima a cambiare processore ad un OS in modo praticamente indolore.
Apple è stata la prima a cambiare OS ad una piattaforma hardware, in modo QUASI indolore.
Apple sarà la prima ad avere un OS ibrido 32/64bit che riunisce i VANTAGGI di entrambe le modalità senza assumerne i DIFETTI.

Ma li leggi i messaggi che scrivo? I difetti ci sono, eccome per le applicazioni a 64 bit!

Apple è sempre la prima in tutto, sono gli altri che la copiano.

Poi mi spieghi che c'entra questa frase con la discussione...

[Criceto]

Originariamente inviato da cdimauro
Il gioco vale la candela perché il 15-20% è l'aumento MEDIO di prestazioni, quindi "generalizzato". In casi ottimali si è superato anche il 100% di prestazioni in più (con MiniGzip. )

E quindi significa anche che altre applicazioni gireranno più LENTAMENTE...

Come in tutte le cose, dipende al contesto: saranno ridicole nei casi migliori, in cui ci saranno pochi passaggi di buffer fra applicazioni a 64 bit e driver e pochi messaggi scambiati fra il codice a 32 bit e quello a 64 bit di un'applicazione, ma tutt'altro che ridicoli in caso contrario.

Il Kernel è a 32 bit. I drivers sono a 32bit.
Non mi sembra proprio che ci possa essere accesso ai drivers dalle applicazioni a 64bit, senza passare per il kernel, quindi il problema non si pone.
E a che servirebbe poi un driver non di sistema che indirizza più di 4Gb di ram? O usa interi a 64 bit? A nulla...

Non è affatto vero che verranno usati dove ci sono reali benefici: questo succederà SE gli sviluppatori perderanno tempo a suddividere il codice a 32 bit da quello a 64 bit, come ho già detto.
Non so tu, ma al posto loro lascerei perdere e mi limiterei a fornire l'applicazione compilata interamente a 32 bit o 64 bit.

Ma li leggi i messaggi che scrivo? I difetti ci sono, eccome per le applicazioni a 64 bit!

Credo che sei tu che continui a non voler capire.
Ti porto un paio di messaggi presi da un altro forum e poi io chiudo qui.


-------------


I don't think that people really understand the what does it mean to do 64-bit computation. 64-bit cpmputation means two things:
- 64 bit math computing (to be precise 64 bit interger math).

- Support of 64 bit adressing, in order to get ride of the 4 go of memory adressable with the 32 bit mode.

Ok that's the definition of 64 bit computation, there is nothing else, no other magic things that can appear when doing 64 bits conputations. A lot of people that their applications becomes magically fast if they run it on 64 bit. That's not true at all, 64-bit computing only delivers better performance in very defined and specific situations.

So now imagine and try to quantify your need. What are doing with a computer usually. Well you go to surf on the web, you use for that a web browser. You write mails, you use word processing softwares, you listen music, you burn CD/DVD, you play games, you manage your photos, your movies,etc....

And know ask yourself, do i need the 64 bit computation (as described above) to write mails, surf on interbet, or even play games. Does a mail application needs to make 64 bit math computation, or does it need to address more than 4 go of memory?....... of course not! The same for the application that goes on internet, manages your photos and your holidays movies, or writes your text. Even games do not need 64 bits computations. Many game developpers have noticed that they don't even use 64 bits interger math, they rather manipulate 64 bit floating point numbers. Moreover does a game need to address more than 64 bits of memory, of course not. Do you imagine that the developers of Doom come one day, and ask you to have more than 4 go of memory on your machine to run their last game. Maybe tomorrow, in the future, it will be the case, but now, absolutaley not....

So why 64 bits? Well high end computations have been using 64-bit computation for a while, in the workstation market and high end servers. Many people working in science, engeneering, or who manipulate huge data bases have the need to adress more than 4 go. Scientists often write processes that manipulate memory chunks greater than 4 go of memory, in order to increase the computation throughput and speed.Today's high end 3D applications, viseo applications also need to access large portion of data for fast processing, and so they may need to run 64 bit processes.

So form the above description, the stratege of Apple is smart, as it allows all the people who really needs 64-bit computation to write 64 bit applications on Tiger. 64 bit processes, command line application and servers processes can be developped on Tiger. And as many of those applications still does not use a GUI (i know it because i am always dealing with this staff), not supporting 64 bit GUI is normal. Why should it be anyway, its not a duty, we are talking about number crunching here, that's where the 64-bit computation is good for....
For people who need it, Tiger is gonna to deliver on 64 bits. Any 64 bit process can be done on Tiger, and Tiger fullt supports 64 bit interger math.

And again, apple approach is nice, as they allows 64 bit computing without to change the kernel, or to make it more complex. 32 bits applications do not have to run on a compatibility mode or something like that, and they still can profit from the 64 registers, access to the 64 bit load/store unit and the 64 bit logical units.
So people who really needs to make 64 bit computation , will be able to do it with Tiger, and even Gui can be created with their 64 bit processes by using messages passing with the two executables, as explained by Apple. For this reason Tiger competes with Solaris, 64 bits Linux, or any Os that support 64 bits computation, specially in the workstation market where again 64 bit computation is used.
For all the other users, Tiger support 32 bit applications, and again i don't see really the need to have a GUI that can run on 64 bit mode, so Tigers delivers as it supposed to do......

----------------------------------

OS X 10.4 (Tiger) can, indeed, execute 64-bit applications. They are providing a 64-bit libsystem, as well as a 64-bit ABI, which is all anyone who actually knows what 64-bit computing means (...) will need to build a 64-bit binary, of say, MySQL, from source.

Tiger supports LP64, the exact same 64-bit model as Linux, Solaris and IRIX.

What they are -not- shipping is a 64-bit kernel or 64-bit applications, since the Cocoa and Carbon frameworks will remain 32-bit.

AND THIS IS A GOOD THING.

Shipping a 64-bit kernel means needing 64-bit drivers. This is fine for Apple's drivers, but 3rd party drivers would need to be re-built. This is no different on Solaris, where both a 64-bit driver is needed on UltraSPARC. Apple is actually saving a lot of hassle going this route.

64-bit BSD binary support -is all- that Tiger needs, and Apple is delivering it. The PowerPC ISA is not any faster in 64-bit mode... in fact, it's actually slower due to the bus overhead. Opteron apps get faster in 64-bit mode only because AMD64 adds more registers, but on PowerPC there are already 32 registers.

I don't -want- a 64-bit Finder. I -do- want a 64-bit ABI for building binaries from source.

They are delivering.

----------------------------

Saluti

[cdimauro]

Originariamente inviato da Criceto
E quindi significa anche che altre applicazioni gireranno più LENTAMENTE...

Pochissime e con differenze trascurabili: infatti per quasi tutte si assiste a un incremento delle prestazioni, più o meno marcato.
Ci sono un bel po' di benchmark in rete, con applicazioni a 32 e 64 bit: prova a dargli un'occhiata...

Il Kernel è a 32 bit. I drivers sono a 32bit.

Un kernel a 32 bit non può gestire task a 64 bit: almeno la parte di context switch dev'essere a 64 bit.

Non mi sembra proprio che ci possa essere accesso ai drivers dalle applicazioni a 64bit, senza passare per il kernel, quindi il problema non si pone.

Non si pone semplicemente perché non è possibile: abbiamo scoperto l'acqua calda...

E a che servirebbe poi un driver non di sistema che indirizza più di 4Gb di ram? O usa interi a 64 bit? A nulla...

Allora a questo punto a che servono i 64 bit? A nulla!
I driver sono applicazioni, semplicemente specializzate per alcuni compiti: ci sono casi in cui si possono avvantaggiare del fatto di manipolare dati a 64 bit, e soprattutto per le applicazioni a 64 bit non ci sarebbe alcun overhead se fosse possibile passare direttamente i puntatori a 64 bit anziché usare un buffer di transito, come ho già detto.

Credo che sei tu che continui a non voler capire.
Ti porto un paio di messaggi presi da un altro forum e poi io chiudo qui.

Non c'è scritto nulla di nuovo rispetto a quanto abbiamo già discusso. Comunque sottolineo qualche cosa:

So people who really needs to make 64 bit computation , will be able to do it with Tiger, and even Gui can be created with their 64 bit processes by using messages passing with the two executables, as explained by Apple.

Quest'approccio comporta una perdita di prestazioni, come ho già detto.

For this reason Tiger competes with Solaris, 64 bits Linux, or any Os that support 64 bits computation, specially in the workstation market where again 64 bit computation is used.

Ciò non è esatto: in questi casi Tiger parte svantaggiato, a causa dei driver a 32 bit e dell'uso dei messaggi fra il codice a 32 e 64 bit.

Shipping a 64-bit kernel means needing 64-bit drivers. This is fine for Apple's drivers, but 3rd party drivers would need to be re-built.

Quindi come vedi la soluzione migliore sarebbe quella di avere kernel e driver a 64 bit.

This is no different on Solaris, where both a 64-bit driver is needed on UltraSPARC. Apple is actually saving a lot of hassle going this route.

Che è quello che ho detto io: lavoro in meno per Apple per gli sviluppatori di driver. Ma NON E' la soluzione migliore (vedi sopra).

The PowerPC ISA is not any faster in 64-bit mode... in fact, it's actually slower due to the bus overhead.

Non è esatto: dipende dall'applicazione.

Opteron apps get faster in 64-bit mode only because AMD64 adds more registers, but on PowerPC there are already 32 registers.

Anche aggiungendone altri, la situazione non cambierebbe.

Come vedi le cose non stanno esattamente come pensi o vorresti far credere...

[Criceto]

Originariamente inviato da cdimauro

Non si pone semplicemente perché non è possibile: abbiamo scoperto l'acqua calda...
Allora a questo punto a che servono i 64 bit? A nulla!

A molto poco, infatti...
Motivo per cui il kernel l'hanno lasciato tutto a 32bit (potevano farlo FAT anche lui, volendo).

Quest'approccio comporta una perdita di prestazioni, come ho già detto.

Allora, visto che insisti su questo punto:

1. Mach è un sistema operativo "message-passing", è nato con quel concetto al suo centro, quindi è ottimizzato per quello.

2. Dove servono le prestazioni è nel codice 64bit, non nella visualizzazione del suo risultato. La perdita di prestazioni nello scambio dei messaggi dal backend a 64 bit alla GUI a 32 bit (per la fruizione dei dati computati) è del tutto irrilevante in questo contesto.

Quindi le tue riserve prestazionali sull'approccio a 64bit di Tiger mi sembrano del tutto gratuite.

E sono niente in confronto alle controindicazioni prestazionali e di efficienza (occupazione memoria) che un OS totalemente 64 bit, come Win64, va incontro con il 99% del codice che NON NECESSITA dei 64 bit!

[cdimauro]

Originariamente inviato da Criceto
A molto poco, infatti...
Motivo per cui il kernel l'hanno lasciato tutto a 32bit (potevano farlo FAT anche lui, volendo).

Lo è già, visto che gestisce correttamente i task a 32 e 64 bit.

Allora, visto che insisti su questo punto:

1. Mach è un sistema operativo "message-passing", è nato con quel concetto al suo centro, quindi è ottimizzato per quello.

E questo che c'entra? Un'applicazione normalmente non utilizza message-passing internamente (vengono chiamate direttamente le routine o i metodi delle classi), ma per interfacciarsi col s.o., mentre un'applicazione a 64 bit con Tiger dovrà farlo per comunicare con sé stessa (col codice a 32 bit).

La differenza mi sembra notevole.

2. Dove servono le prestazioni è nel codice 64bit, non nella visualizzazione del suo risultato. La perdita di prestazioni nello scambio dei messaggi dal backend a 64 bit alla GUI a 32 bit (per la fruizione dei dati computati) è del tutto irrilevante in questo contesto.

1) Dipende dal contesto applicativo (se c'è un consistente scambio di messaggi fra codice a 32 e 64 bit, la prestazioni ne risentiranno)
2) Dimentichi l'overhead nel caso in cui un'applicazione a 64 bit richiami un driver (a 32 bit).

Quindi le tue riserve prestazionali sull'approccio a 64bit di Tiger mi sembrano del tutto gratuite.

Non lo sono fatto: sono una precisa analisi tecnica del funzionamento di Tiger e delle applicazioni che in esso gireranno.

E sono niente in confronto alle controindicazioni prestazionali e di efficienza (occupazione memoria) che un OS totalemente 64 bit, come Win64, va incontro con il 99% del codice che NON NECESSITA dei 64 bit!

1) Mediamente si assisterà a un incremento del 15-20% delle prestazioni.

2) Ci sarà un maggior consumo di memoria dovuto ai puntatori di dimensione doppia, ma un minor consumo dovuto alle innovazioni dell'ISA a 64 bit (raddoppio dei registri -> meno riferimenti alla memoria, ecc.)

3) I 64 bit verranno usati automaticamente dove servono, nel modo migliore: non c'è alcuna necessità di suddividere il codice a 32 o 64 bit, perché questo lavoro lo fa già il compilatore.

Il problema è che tu confondi il passaggio da 32 a 64 bit fra PowerPC e x86: coi primi si ha semplicemente un raddoppio della dimensione dei registri e dell'indirizzamento della memoria, SENZA ALCUN'ALTRA MIGLIORIA; coi secondi, oltre a quanto avviene coi PPC, l'ISA viene arrichita con molte caratteristiche interessanti che contribuiscono a diminuire le dimensioni del codice e migliorare le prestazioni (in particolare grazie al raddoppio dei registri GPR).

Per questo motivo un s.o. full 64 bit come Windows XP, o Linux, o BSD, o Solaris, o quel che ti pare, trae vantaggio passando da x86 a x86-64, mentre va incontro ai problemi di cui abbiamo discusso passando da PPC-32 a PPC-64.

In particolare rifletti bene sul punto 3 che ho scritto, e cerca di capire come mai con Windows (e gli altri s.o.) è il compilatore che genera il codice migliore, mentre per PPC/Tiger dovrebbe essere il programmatore a farlo per ottenere le prestazioni migliori.

[DioBrando]

Originariamente inviato da cdimauro
Un controsenso è quello di dire che ci si trova in un libero mercato, ma discriminare le società in base al peso che in esso hanno...

La discriminazione viene fatta a monte, quando n vengono tutelate le società + piccole ed incapaci di difendersi nel momento in cui vi sn in atto dei comportamenti sleali e lesivi da parte di chi ha una posizione dominante proprio dei dogmi del libero mercato e della concorrenza.
Quando questi accadono e n vengono sanzionati, già parlare di libero mercato è un controsenso, un paradosso.


La discriminazione di cui parli, se vuoi, è un effetto feedback o un atto di compensazione
Ingiusto, ma capita sia così...e che cmq n risolve il problema che ripeto andava risolto a monte; quando le % sn preponderanti la situazione non è sanabile, si può solo fare in modo che certe politiche lassiste non si verifichino +. ( un'utopia perchè tutti possono essere comprati con soldi, promesse ecc...il caso recente sulle SW Patents, la Danimarca, Dell ecc. ne sn piccole dimostrazioni, purtroppo...)

[cdimauro]

Non sono d'accordo: non si possono mettere le corde al collo soltanto perché il sistema fallisce nel suo compito di controllo. Se il problema è il sistema che non funziona, è questo che si deve cambiare, non chi ha beneficiato della sua assenza...

[SilverXXX]

Anche se poi si dovrebbe cercare (dopo la "sistemazione" del sistema) di permetterla, la competizione. E cmq se adesso abbiamo tutti un pc o + in casa lo si deve principalmentre a ms.