tiger e mac mini

[kinggiamma]

...ciao a tutti, sto per acquistare il mio primo mac...e ho deciso di investire in un mac mini versione base.
volevo sapere però se tale configurazione reggerà la nuova versione del sistema operativo os X...e cioè la 10.4 che si dovrebbe chiamare tiger.
grazie.

[Criceto]

Originariamente inviato da kinggiamma
...ciao a tutti, sto per acquistare il mio primo mac...e ho deciso di investire in un mac mini versione base.
volevo sapere però se tale configurazione reggerà la nuova versione del sistema operativo os X...e cioè la 10.4 che si dovrebbe chiamare tiger.
grazie.

Certo!
OS-X ogni versione che passa diventa più veloce, a differenza di Windows...
L'unica limitazione viene dalla scheda video che forse non supporterà alla massima velocità (cioè in real-time) una nuova caratteristica di Tiger che è Core-Image (http://www.apple.com/macosx/tiger/coreimage.html).
Inoltre 256MB per OS-X sono pochi. Mentre il doppio (512 MB) è un quantitativo decisamente più adeguato (la memoria virtuale di OS-X è molto efficiente, ma il sistema è anche molto grande e l'interfaccia grafica, per come è implementata, richiede MOLTA memoria).

[ioan]

Certamente. Perché no? :confused:

Il Panther gira anche negli imac g3 oppure negli powermac g3... Il tiger pure... Quindi lo stesso vale ampiamente per il mini mac.

Anzi l'Apple offre un sistema operativo che non solo gira benissimo su tante delle sue macchine, ma in più allunga la vita del suo parco macchine :cool:

La limitazione non ufficiale per Tiger è:
--> tecnologia usb e firewire integrata (cioè i mac senza firewire non ci saranno)

...come per Panther non ci sono i mac senza usb integrata.

[ioan]

Per la ram: è decisamente meglio 512MB di ram... però le minime sono 128MB per Panther e rimangono le stesse per Tiger.

Certamente 256MB di ram bastano per avere un sistema funzionante, però gli accessi al disco rigido saranno troppo frequenti per avere un sistema bene performante (in ogni caso rimane stabile e funzionante, non è mica winxp ;) )

Di solito l'utente medio usa sui 384/512MB di ram senza stancare il disco rigido. Ovviamente più si ha meglio è :)

[Fez]

non vorrei far polemica solo che se si sta parlando di mac mi sembra inutile tirare in ballo win.
Lo dico da utente mac e pc...

[OkKi0]

Originariamente inviato da Fez
non vorrei far polemica solo che se si sta parlando di mac mi sembra inutile tirare in ballo win.
Lo dico da utente mac e pc...

Se si deve fare un paragone si tende a farlo, giustamente, con windows.... :rolleyes:

[cdimauro]

Core-Image non sfrutterà la GPU della scheda video del Mac Mini.

[Caesar_091]

Originariamente inviato da cdimauro
Core-Image non sfrutterà la GPU della scheda video del Mac Mini.

Esattamente.

Ma per girare il 10.4 girerà senza problemi... mi piace così tanto la GUI di Mac OS X che il mancato supporto per il Pixel Shader 2.0 (GPU VS VPU) e di qualche altra chicca da parte della ATI9200 è ciò che veramente mi blocca dal regalrmi (non pe ruso personale) un MAc mini...

x kinggiamma
All'atto pratico con quella scheda video non vedrai certi effetti grafici (tipo le onde al richiamo di un nuovo elemento della dashboard) e, tutte le applicazioni che varrano scritte appositamente per sfruttare Core Image e Core Video, non andranno come potrebbero.

Per il resto tutto funzionerà perfettamente.

[Ockley]

x kinggiamma
All'atto pratico con quella scheda video non vedrai certi effetti grafici (tipo le onde al richiamo di un nuovo elemento della dashboard) e, tutte le applicazioni che varrano scritte appositamente per sfruttare Core Image e Core Video, non andranno come potrebbero.

Per il resto tutto funzionerà perfettamente.

Onde di richiamo? Cioè :confused:
Essendo un Pc-user non capisco :p
In pratica cosa si avrà in meno?

P.S. Ovviamente comprando un macmini ora si dovrà a giugno comprare exnovo il tiger giusto?O è un aggiornamento?E' difficile da mettere?

Grazie :)

[Caesar_091]

Originariamente inviato da Ockley
Onde di richiamo? Cioè :confused:
Essendo un Pc-user non capisco :p

Quando richiami a schermo un nuovo elemento della dashboard questo appare con un effetto "tipo sasso in un lago"... prova delle onde sullo schermo.
Forse in questo video si vede:
http://www.apple.com/macosx/tiger/dashboard.html
Eventualmente vai a guardare l'ultimo keynote dal ventitreesimo minuto:
http://www.apple.com/quicktime/qtv/mwsf05/
(lo vedi o con QT o con VLC)

In pratica cosa si avrà in meno?

Quello che ho già scritto: Core Image e Core Video.
http://www.apple.com/macosx/tiger/core.html
(la pagina sembra essere stata rimossa... ma la posto lo stesso che non si sa mai.. prova nella cache di Google)
Comunque un'anteprima delle principali novità di Tiger la trovi qui:
http://www.apple.com/macosx/tiger/


P.S. Ovviamente comprando un macmini ora si dovrà a giugno comprare exnovo il tiger giusto?O è un aggiornamento?E' difficile da mettere?


Solitamente quando annunciano la data di rilascio di un nuovo OS dicono anche chi rientra nel programma di aggiornamento gratuito dal vecchio al nuovo OS (magari pagando solo le psese di spedizione). Non è un aggiornamento. E' proprio un nuovo sistema operativo. Puoi tuttavia aggiornare a Tiger (MacOS X 10.4) dall'attuale Panther (MacOS X 10.3).... anche se IMHO è consigliabile fare una clean install (formatta e installa).

[Hal2001]

Originariamente inviato da Caesar_091
Solitamente quando annunciano la data di rilascio di un nuovo OS dicono anche chi rientra nel programma di aggiornamento gratuito dal vecchio al nuovo OS (magari pagando solo le psese di spedizione)

Ma essendo un OS che viene indicato come nuovo [anche se sembra un aggiornamento più che altro, ndr], di solito chi rientra in questa campagna? Chi ha acquistato in data molto vicina all'uscita oppure gli utenti di determinati modelli?
Visto che Tiger è ormai in dirittura d'arrivo, magari nei prossimi package di MiniMac vi sarà il nuovo Os in bundle.

[Hal2001]

Originariamente inviato da ioan
(in ogni caso rimane stabile e funzionante, non è mica winxp ;) )

Se utilizzi hardware certificato, e applicazioni ben testate non incorri in nessun problema di stabilità. Le schermate blu, da quando uso questa EPIA M (assemblata dal produttore) sono solo un ricordo. E tanto per parlare di WinXP che uso con profitto da dopo l'estate 2001, quando sono incorso in problemi si son trattati di problemi a controller dischi, e successivamente di software scritto con i piedi. StatBar mi segna in questo momento un uptime di un mese.
Vorrei vedere OSX su un parco macchine disparato quale è il mondo X86.
Queste considerazioni, di parte e molto scorrette sono la base di partenza per litigi. Se si vuole parlare con causa si evitano queste sparate.

[Ockley]

Solitamente quando annunciano la data di rilascio di un nuovo OS dicono anche chi rientra nel programma di aggiornamento gratuito dal vecchio al nuovo OS (magari pagando solo le psese di spedizione). Non è un aggiornamento. E' proprio un nuovo sistema operativo. Puoi tuttavia aggiornare a Tiger (MacOS X 10.4) dall'attuale Panther (MacOS X 10.3).... anche se IMHO è consigliabile fare una clean install (formatta e installa).

Al momento attuale non se ne sà niente vero?
Io dovrei prendere il minimac a febbraio marzo e anche se fosse, non penso rientrerei nella categoria degli utenti che possono aggiornare...troppo tempo...

Ma Core imagine e core video non si potranno avere per via della scheda grafica? O per altre caratteristiche del mini?

P.S.
In questo filmato http://www.apple.com/quicktime/qtv/mwsf05/ dove si trova la presentazione del mini?
:)

[Criceto]

Originariamente inviato da Hal2001
Ma essendo un OS che viene indicato come nuovo [anche se sembra un aggiornamento più che altro, ndr], di solito chi rientra in questa campagna? Chi ha acquistato in data molto vicina all'uscita oppure gli utenti di determinati modelli?
Visto che Tiger è ormai in dirittura d'arrivo, magari nei prossimi package di MiniMac vi sarà il nuovo Os in bundle.

Sì di solito danno dei coupon con i quali puoi ottenere l'aggiornamento con le sole spese di spedizione (una volta perfino gratis! Mi sembra con la 10.1). Però questo succede se acquisti abbastanza a ridosso dell'uscita e con una data di uscita annunciata (non è questo il caso).

[Caesar_091]

Originariamente inviato da Hal2001
Ma essendo un OS che viene indicato come nuovo [anche se sembra un aggiornamento più che altro, ndr]

Anche solo per il pieno supporto dei 64 bit dei G5 vale il ttolo di nuovo OS. Poi sono opinioni....

, di solito chi rientra in questa campagna? Chi ha acquistato in data molto vicina all'uscita oppure gli utenti di determinati modelli?

Tutit coloro che hanno acquistato in data vicina al rilascio ufficiale dle nuovo OS.


Visto che Tiger è ormai in dirittura d'arrivo, magari nei prossimi package di MiniMac vi sarà il nuovo Os in bundle.

Sarà in bundle al posto di Panther dal giorno in cui annunceranno ufficialmente l'uscita di Tiger....

EDIT: o meglio dal giorno in cui incominceranno a vendere Tiger.

[Caesar_091]

Originariamente inviato da Hal2001
Queste considerazioni, di parte e molto scorrette sono la base di partenza per litigi. Se si vuole parlare con causa si evitano queste sparate.

Io ho imparato che la cosa migliore è ignorare. E' troppo facile scatenare discussioni fastidiosamente scottanti.... il difficile è riuscire a raffreddarle ;)

CMQ ovviamente era stata scritta una cretinata... basta una frase di quel tipo per accendere la miccia.... :muro:

[thedoors]

[B]
Eventualmente vai a guardare l'ultimo keynote dal ventitreesimo minuto:
http://www.apple.com/quicktime/qtv/mwsf05/
(lo vedi o con QT o con VLC)





F A V O L O S O il keynote ( me lo sono visto tuttoooo)!!

Come posso scaricarlo su Hard disk???

[Caesar_091]

Originariamente inviato da thedoors
F A V O L O S O il keynote!! Come posso scaricarlo su Hard disk???

Ad oggi lo dovresti trovare sulle comuni reti di P2P...

[thedoors]

...nada, ne su dc++ ne su winmx!

[Caesar_091]

I torrenti sono in piena.... non trovi nulla neanche su BT?

[thedoors]

si, ma solo 1 utente,.. e il download nemmeno parte!! riprovo domani!!

Thanks!!!

[thedoors]

nada!!! Ora addirittura sono in ufficio e lo streaming qui non funzia!!! Sto cercando un qualche link http per scaricarlo ma nulla!!!!

[Caesar_091]

Ho provato dal torrent che ti ho passato via PM (http://www.newtomac.com/tracker/download.php?id=1&file=macworld_hi.torrent) e scarico a 80K fissi con una ADSL640... non è che sei dietro router/firewall e devi nattare le porte per BT?

[thedoors]

Siamo dietro a un proxy e amenità varie, non se puede!!! Lo scarico da casa stasera! Intanto cerco un link http in giro!

[cdimauro]

Originariamente inviato da Ockley
Ma Core imagine e core video non si potranno avere per via della scheda grafica? O per altre caratteristiche del mini?
Solo per la scheda grafica, che è di "classe DirectX 8".

[cdimauro]

Originariamente inviato da Caesar_091
Anche solo per il pieno supporto dei 64 bit dei G5 vale il ttolo di nuovo OS. Poi sono opinioni....
Tiger non avrà pieno supporto ai 64 bit del G5: ci sono delle limitazioni che questo s.o. si porterà comunque dietro.

Qui http://developer.apple.com/macosx/tiger/64bit.html ci sono un po' di informazioni in merito. La più importante è questa:

"It is important to note that in the Tiger release, the support for 64-bit programming does not extend throughout the entire set of APIs available on Mac OS X. Most notably, the Cocoa and Carbon GUI application frameworks are not ready for 64-bit programming. In practical terms, this means that the "heavy lifting" of an application that needs 64-bit support can be done by a background process which communicates with a front-end 32-bit GUI process via a variety of mechanisms including IPC and shared memory."

Un'altra cosa su cui ci si dovrà (ovviamente) scontrare è questa:

"pointers are 64-bit"

Questo comporterà un raddoppio della dimensione dei puntatori con tutte le conseguenze del caso.

[alb9k]

altri investimenti nel hw per sfruttare le nuove caratteristiche del tiger...

[Caesar_091]

Originariamente inviato da cdimauro
Tiger non avrà pieno supporto ai 64 bit del G5: ci sono delle limitazioni che questo s.o. si porterà comunque dietro.

Hai ragione ho scritto male. Avrei dovuto scrivere miglior supporto invece che pieno supporto. Le limitazioni sono un ragionevole compromesso se si vuole un sistema ibrido 32/64bit per non abbandonare la maggior parte degli utenti che usano ancora in massima parte processori a 32bit.

[Oblio]

Originariamente inviato da cdimauro


"pointers are 64-bit"

Questo comporterà un raddoppio della dimensione dei puntatori con tutte le conseguenze del caso.

lo spiegate in parole povere pure a me che sono ciuccio:p :p

[cdimauro]

Originariamente inviato da Caesar_091
Hai ragione ho scritto male. Avrei dovuto scrivere miglior supporto invece che pieno supporto. Le limitazioni sono un ragionevole compromesso se si vuole un sistema ibrido 32/64bit per non abbandonare la maggior parte degli utenti che usano ancora in massima parte processori a 32bit.
Si sarebbe potuto utilizzare un approccio simile a quello di Windows XP/64: un layer per interfacciare le vecchie applicazioni a 32 bit al nuovo s.o. a 64 bit.
Da una parte si sarebbe mantenuta la piena compatibilità col passato, dall'altra le applicazioni native a 64 bit non sarebbero state soggette ad alcun limite / complicazione.

[cdimauro]

Originariamente inviato da Oblio
lo spiegate in parole povere pure a me che sono ciuccio:p :p
In parole povere :) : i puntatori a 64 bit hanno bisogno del doppio di spazio rispetto a quelli a 32 bit (e questo mi sembra lapalissiano).

In parole molto povere :) :), questo vuol dire che buona parte delle strutture che conservano i dati subiranno un aumento delle loro dimensioni (o dei loro "riferimenti"; ma non voglio aggiungere altre informazioni di carattere tecnico :D).

In parole ancora più povere :) :) :), il maggior spazio di memoria occupato (che potrebbe essere trascurato vista la corsa ai GB degli ultimi tempi :D) comporterà una diminuzione delle prestazioni, causate dal maggior tempo necessario a leggere / scrivere questo tipo di dati (ti risparmio tutti i discorsi sul funzionamento delle cache L1, L2, ecc. ;)).

In conclusione: contrariamente a ciò che si pensa, mediamente si assisterà a un calo prestazionale per le applicazioni native a 64 bit, mentre saranno poche quelle potranno beneficiare dalla capacità di manipolare quantità a 64 bit anziché a 32 bit, e per la maggior quantità di memoria gestibile.

[Criceto]

Originariamente inviato da cdimauro
Si sarebbe potuto utilizzare un approccio simile a quello di Windows XP/64: un layer per interfacciare le vecchie applicazioni a 32 bit al nuovo s.o. a 64 bit.
Da una parte si sarebbe mantenuta la piena compatibilità col passato, dall'altra le applicazioni native a 64 bit non sarebbero state soggette ad alcun limite / complicazione.

No.
La situazione è differente. I PowerPC è un'architettura a 64 bit fin dalla nascita con il supporto per un subset a 32 bit. Fino al PowerPC 970 le implementazioni dei processori PowerPC erano solo il subset a 32 bit dell'ISA.

Questo comporta che far girare applicazioni 32 bit su un'implementazione PowerPC a 64 bit non introduce NESSUNA PENALITA'.
Mentre far girare un codice a 64 bit che non necessita di un'indirizzamento di RAM superiore a 4Gb o numeri interi superiori ai 32bit comporta un raddoppio della dimensione dei puntatori o (appunto) degli interi. Con la conseguenza di un aumento del codice e quindi un suo RALLENTAMENTO, poichè la velocità dell'accesso alla Ram di questi tempi è il collo di bottiglia.

Su Panther solo il sistema operativo può utilizzare i 64bit, fermo restando i 32 bit per ogni processo (insomma ci possono essere più processi che indirizzano fino a 4GB (32bit) contemporaneamente).
Su Tiger qualsiasi processo (anche all'interno della stessa applicazione) può essere a 32 o 64 bit, a seconda della convenienza (e la Apple sconsiglia l'uso a 64bit ove non necessario), senza particolari problemi. E questo dal punto di vista dell'efficienza e della velocità di esecuzione é il miglior approccio possibile.


Per gli x86 la situazione è diversa, perchè la sua ISA (le istruzioni del processore) non sono state pensate fin dall'inizio per essere upgradate a 64, e neanche a 32 bit se per questo, perchè l'8086 era un processore a 16 BIT.

Quindi, l'implementazione a 64 bit (come prima quella a 32) comporta tutto un set di istruzioni nuove non compatibili con quelle vecchie, un numero di registri maggiore, ecc. Insomma è proprio un altro processore che lavora in 3 modalità: 64 bit, 32 bit, 16 bit compleatamente DISGIUNTE. Un accrocco, insomma, come è tutta l'architettura x86 fin da quando è nata. Quindi se partono a 64 bit gli serve tutto il resto del supporto a 64bit e il tutto non è mischiabile molto facilmente e introduce penalità prestazionali facendolo.

[cdimauro]

Originariamente inviato da Criceto
Questo comporta che far girare applicazioni 32 bit su un'implementazione PowerPC a 64 bit non introduce NESSUNA PENALITA'.
Lo stesso avviene per le applicazioni a 32 bit eseguite in Windows XP/64. Anzi, mediamente traggono vantaggio dall'esecuzione nel nuovo ambiente.
Mentre far girare un codice a 64 bit che non necessita di un'indirizzamento di RAM superiore a 4Gb o numeri interi superiori ai 32bit comporta un raddoppio della dimensione dei puntatori o (appunto) degli interi. Con la conseguenza di un aumento del codice e quindi un suo RALLENTAMENTO, poichè la velocità dell'accesso alla Ram di questi tempi è il collo di bottiglia.
Questo si verifica anche con le applicazioni a 64 bit native per Windows XP/64.
Su Tiger qualsiasi processo (anche all'interno della stessa applicazione) può essere a 32 o 64 bit, a seconda della convenienza (e la Apple sconsiglia l'uso a 64bit ove non necessario), senza particolari problemi. E questo dal punto di vista dell'efficienza e della velocità di esecuzione é il miglior approccio possibile.
Per OS X e il G5, sicuramente sì. Ma complica la vita agli sviluppatori di applicazioni che fanno uso dei 64 bit (servono due applicazioni, una a 32 bit con la GUI e un'altra nativa a 64 bit, che devono comunicare).
Per gli x86 la situazione è diversa, perchè la sua ISA (le istruzioni del processore) non sono state pensate fin dall'inizio per essere upgradate a 64, e neanche a 32 bit se per questo, perchè l'8086 era un processore a 16 BIT.

Quindi, l'implementazione a 64 bit (come prima quella a 32) comporta tutto un set di istruzioni nuove non compatibili con quelle vecchie, un numero di registri maggiore, ecc. Insomma è proprio un altro processore che lavora in 3 modalità: 64 bit, 32 bit, 16 bit compleatamente DISGIUNTE.
Sì, ma non vedo cosa c'entri questo con quello di cui si sta discutendo: un'applicazione nativa a 64 bit per G5 sfrutta comunque delle caratteristiche NON PRESENTI nei precedenti processori. Esattamente ciò che avviene con x86-64 vs x86 (-32). In soldoni: entrambi i processori (G5 fatto funzionare a 64 bit e x86-64) hanno bisogno di applicazioni native / specifiche per sfruttare le loro caratteristiche peculiari.
Un accrocco, insomma, come è tutta l'architettura x86 fin da quando è nata.
Sempre con gli stessi discorsi, eh? Intanto l'accrocco è sopravvissuto, con tutti i benefici in termini economici e prestazionali che ben conosci...
Quindi se partono a 64 bit gli serve tutto il resto del supporto a 64bit e il tutto non è mischiabile molto facilmente e introduce penalità prestazionali facendolo.
Non è così. Ogni nuovo ambiente richiede un supporto specifico, come ho già detto. Poi tanto i G5 quanto gli x86-64 possono benissimo far girare applicazioni a 32 bit all'interno di s.o. interamente a 64 bit, senza perdita di prestazione (mediamente) per esse.
Qui c'è semplicemente da rilevare che Tiger utilizzerà una soluzione di compromesso, anziché offrire quanto ho scritto qui sopra...

[Criceto]

Originariamente inviato da cdimauro
Lo stesso avviene per le applicazioni a 32 bit eseguite in Windows XP/64. Anzi, mediamente traggono vantaggio dall'esecuzione nel nuovo ambiente.

Non credo proprio. Anzi penso che alla fine Windows/64 sarà anche più lento di Win/32, per i motivi detti sopra (codice più pesante). C'era un articolo del capo del team di sviluppo dei compilatori Microsoft che diceva appunto che i benefici prestazionali dell'ambiente a 64 bit dei loro compilatori alla fine venivano annullati, appunto, dalla maggior pesantezza del codice oggetto. Quindi o si inventano Ram e bus più veloci o non ci sono particolari vantaggi nella piattaforma x86 a passare a 64 bit (e forse è per questo che Intel voleva evitarlo, ma è stata tirata dentro a forza da AMD).


Per OS X e il G5, sicuramente sì. Ma complica la vita agli sviluppatori di applicazioni che fanno uso dei 64 bit (servono due applicazioni, una a 32 bit con la GUI e un'altra nativa a 64 bit, che devono comunicare).

Le applicazioni che necessiteranno dei 64 bit si conteranno nelle dita di una mano per un bel po' di anni. Qualche server SQL, una versione di Photoshop o Final Cut EXTREME e poco altro... quindi non vedo la necessità appesantire (e rallentare) tutte le altre.


Sì, ma non vedo cosa c'entri questo con quello di cui si sta discutendo: un'applicazione nativa a 64 bit per G5 sfrutta comunque delle caratteristiche NON PRESENTI nei precedenti processori.
Esattamente ciò che avviene con x86-64 vs x86 (-32). In soldoni: entrambi i processori (G5 fatto funzionare a 64 bit e x86-64) hanno bisogno di applicazioni native / specifiche per sfruttare le loro caratteristiche peculiari.

L'unica caratteristica a 64 bit non presente nei PowerPC 32 bit, sono i puntatori.
E poi già esistono e convivono felicemente programmi che utilizzano o no AltiVec, a seconda che sia presente o no... Non serviranno neanche 2 applicazioni separate, ma un "fat binary" per la parte di codice specifico a 64 bit (presumibilmente ridotto).


Non è così. Ogni nuovo ambiente richiede un supporto specifico, come ho già detto. Poi tanto i G5 quanto gli x86-64 possono benissimo far girare applicazioni a 32 bit all'interno di s.o. interamente a 64 bit, senza perdita di prestazione (mediamente) per esse.
Qui c'è semplicemente da rilevare che Tiger utilizzerà una soluzione di compromesso, anziché offrire quanto ho scritto qui sopra...

Così ci sarà Windows/64 con dentro un emulatore Win/32 che a sua volta ha un emulatore DOS/Win16... BELLO!
Immagino anche l'efficienza del sistema multitasking e di memoria virtuale nel passare in tutti questi ambienti differenti...

[cdimauro]

Originariamente inviato da Criceto
Non credo proprio. Anzi penso che alla fine Windows/64 sarà anche più lento di Win/32, per i motivi detti sopra (codice più pesante). C'era un articolo del capo del team di sviluppo dei compilatori Microsoft che diceva appunto che i benefici prestazionali dell'ambiente a 64 bit dei loro compilatori alla fine venivano annullati, appunto, dalla maggior pesantezza del codice oggetto. Quindi o si inventano Ram e bus più veloci o non ci sono particolari vantaggi nella piattaforma x86 a passare a 64 bit (e forse è per questo che Intel voleva evitarlo, ma è stata tirata dentro a forza da AMD).
Non è così. Infatti l'architettura x86-64 porta con sé non solo l'estensione a 64 bit dei registri (per i dati e i puntatori), ma anche il raddoppio dei registri general purpose e SSE, una nuova modalità d'indirizzamento (relativo al PC), un set d'instruzioni più ortogonale, un modello d'indirizzamento della memoria esclusivamente paginato (non c'è più la segmentazione), ecc.
Sono tutte cose che aiutano a migliorare le prestazioni, e a compensare il raddoppio della dimensione dei puntatori. Infatti, nonostante il deficit dovuto a ciò, mediamente si assisterà ad un aumento del 15-20% per le applicazioni x86-64 native (fonte: AMD).

Di questo te ne puoi accorgere andando a vedere le prove effettuate con la beta di Windows XP/64, ma soprattutto con quelle di Linux per x86-64 (ad esempio POVRay e MySQL ottengono un NOTEVOLE aumento di velocità rispetto alle stesse versioni a 32 bit fatte girare sulla stessa macchina).
Le applicazioni che necessiteranno dei 64 bit si conteranno nelle dita di una mano per un bel po' di anni. Qualche server SQL, una versione di Photoshop o Final Cut EXTREME e poco altro...
Indubbiamente. Per il G5/Tiger è esattamente ciò che avverrà, perché l'unica novità che porta il G5 è l'estensione a 64 bit dei registri.
quindi non vedo la necessità appesantire (e rallentare) tutte le altre.
Non è quello che pensavo io, infatti. Tutte le altre avrebbero girato come adesso, con le API a 32 bit e in un "ambiente" a 32 bit.
L'unica caratteristica a 64 bit non presente nei PowerPC 32 bit, sono i puntatori.
Anche i dati a 64 bit: i registri sono comunque a 32 bit, tanto per i puntatori quanto per i dati.
E poi già esistono e convivono felicemente programmi che utilizzano o no AltiVec, a seconda che sia presente o no...
Lo so: succede anche con le applicazioni Windows o Linux con le varie SIMD (MMX, 3DNow!, SSE/2/3).
Non serviranno neanche 2 applicazioni separate, ma un "fat binary" per la parte di codice specifico a 64 bit (presumibilmente ridotto).
Non è certamente questo il problema, anzi. Il maggior onere sarà scaricato sugli sviluppatori, che dovranno pensare a quali parti implementare nell'applicazione a 32 bit, e quali in quella a 64 bit, e farle comunicare correttamente. Che poi tutto stia nello stesso binario è un dettaglio di nessun conto.
Così ci sarà Windows/64 con dentro un emulatore Win/32 che a sua volta ha un emulatore DOS/Win16... BELLO!
Immagino anche l'efficienza del sistema multitasking e di memoria virtuale nel passare in tutti questi ambienti differenti...
E invece è un sistema molto efficiente, se realizzato bene. ;) Come spieghi il fatto che comprimendo un filmato con XviD a 32 bit su XP/64, c'è un miglioramento del 15% del tempo di compressione? Stiamo parlando di un'applicazione (e codec) a 32 bit che gira su un s.o. a 64 bit, e che fa uso del layer di "conversione" WOW64 (API a 32 bit "traslate" a 64 bit, e che ritornanto risultati all'applicazione a 32 bit nel suo "ambiente").
Notevole, no?

Nel caso di Tiger si sarebbe potuto fare la stessa cosa: API a 32 bit per le applicazioni che sono tali, e a 64 bit per le quelle native. Il tutto senza l'"obbligo" di avere esclusivamente applicazioni native: tutto il software, anche nuovo, che non ha bisogno di usare i 64 bit, sarebbe potuto rimanere comunque a 32 bit. IMHO, chiaramente.