Apple e Intel, ancora indiscrezioni

[cdimauro]

Originariamente inviato da jo.li.

Ma come ho già scritto se la Apple non ha ritenuto opportuno riscrivere l'OS a 64bit è perché non ha ritenuto opportuno farlo, almeno questo sui G5, perche negli intel la cosa sarà sicuramente diversa.

Non sui P4: le prestazioni passando ai 64 bit sono abbastanza altalenanti a causa di alcuni compromessi che sono stati necessari per l'implementazione dell'architettura x86-64.

Coi Merom (derivati dai Pentium-M), almeno sulla carta, non dovrebbe esser così. Vedremo.

Infatti come ho detto la differenza prestazionale nei G5 è limitata e come "naturalmente" chissà perché??? tu mi hai fatto notare in determinate situazione usare codice a 64bit potrebbe essere controproducente, ma se la differenza fosse soltanto il 2-3% o meno credi che la cosa sia così importante??

Non credo che si tratti del 2-3%, ma ben di più. Se la percentuale fosse così irrelevante, ad Apple sarebbe convenuto presentare un s.o. con pieno supporto a 64 bit.

Considerando che il kernel supporta già il context switch dei processi a 64 bit e che sono ben poche le parti che richiedono la riscrittura in assembly per G5/64 bit, l'unico intoppo sarebbe stato rappresentato dai driver (che avrebbero richiesto una riscrittura), ma sarebbe stato per lo più a carico dei produttori di hardware.

Per il resto il s.o. è scritto quasi interamente con linguaggi ad alto livello (C, Objective-C, se non ricordo male), come pure le applicazioni, per cui per ottenere eseguibili "64 bit ready" sarebbe stato sufficiente una banale ricompilazione, per lo più.

E' una situazione che, comunque, si ripresenterà quando si effettuerà la transizione da x86 a x86-64, visto che i primi Mactel dovrebbero adottare Yonah, che rimane un processore a 64 bit (Merom arriverà dopo).

[quartz]

cdimauro, scusa l'ignoranza, ma che cosa è il context switching?

Originariamente inviato da cdimauro

Per il resto il s.o. è scritto quasi interamente con linguaggi ad alto livello (C, Objective-C, se non ricordo male)

Sì, quasi tutte le apps sono scritte in Ojective-C. Il SO credo proprio in C.

E' una situazione che, comunque, si ripresenterà quando si effettuerà la transizione da x86 a x86-64, visto che i primi Mactel dovrebbero adottare Yonah, che rimane un processore a 64 bit (Merom arriverà dopo).

Credo sia un errore di distrazione, ma gli Yonah sono a 32 bit!

[cdimauro]

Originariamente inviato da quartz

cdimauro, scusa l'ignoranza, ma che cosa è il context switching?

Il passaggio dell'esecuzione da un task a un altro.

Credo sia un errore di distrazione, ma gli Yonah sono a 32 bit!

La gatta frettolosa fa i gattini ciechi.

Scusate per l'errore di distrazione e grazie per la correzione.

[jo.li.]

Originariamente inviato da cdimauro

A te no, a tanti altri sì. Incluso un certo Steve Jobs...

Indubbiamente, ma stai considerando un caso estremo. Il bisogno di performance non se lo sono inventati i produttori di CPU & affini.

Più esattamente, a cosa ti riferisci?

Sono dei buoni processori e questo nessuno l'ha mai negato, ma torno a ripetere: non sul piano delle prestazioni.

Interessano anche a me le prestazioni dei proc. ma quando queste siano apprezzabili.

Il discorso delle ottimizzazioni del codice è complesso, in questi 5 anni a causa dell'incapacità della motorola nello sviluppare il G4 la Apple ha ottimizzato il S.O. e le sue applicazioni in modo da sfruttare pesantemente le unità altivec, cosi come l'architettura x86 grazie alla sua enorme diffusione e supporto ha avuto la possibilità di disporre di codice molto ottimizzato anche nell'opensource....

E' soltanto da quando la intel ha introdotto i Pentium-M che gli x86 hanno un rapporto prestazioni/consumo vicino ai G4, forse hai dimenticato i portatili con i pentium4 che scaldavano come stufette e avevano una autonomia ridicola.
E i pentium-M sono sicuramente i migliori processori che la intel ha prodotto negli ultimi anni, forse i migliori di sempre, specialmente con i futuri Yonah, Merom, etc...
Poi i G5 dual-core sono al top delle prestazioni, specialmente nei calcoli in virgola mobile e vettoriali.

[jo.li.]

Originariamente inviato da cdimauro

Non credo che si tratti del 2-3%, ma ben di più. Se la percentuale fosse così irrelevante, ad Apple sarebbe convenuto presentare un s.o. con pieno supporto a 64 bit.

Considerando che il kernel supporta già il context switch dei processi a 64 bit e che sono ben poche le parti che richiedono la riscrittura in assembly per G5/64 bit, l'unico intoppo sarebbe stato rappresentato dai driver (che avrebbero richiesto una riscrittura), ma sarebbe stato per lo più a carico dei produttori di hardware.

Per il resto il s.o. è scritto quasi interamente con linguaggi ad alto livello (C, Objective-C, se non ricordo male), come pure le applicazioni, per cui per ottenere eseguibili "64 bit ready" sarebbe stato sufficiente una banale ricompilazione, per lo più.

E' una situazione che, comunque, si ripresenterà quando si effettuerà la transizione da x86 a x86-64, visto che i primi Mactel dovrebbero adottare Yonah, che rimane un processore a 64 bit (Merom arriverà dopo).

Ma è proprio perché la differenza è così bassa e che i vantaggi a ricompilare tutto a 64bit sarebbero stati marginali o nulli o addirittura negativi che non è stato fatto e anche se la cosa fosse così banale come dici tu e non lo è,
perché sprecare le risorse in questo modo?

Forse già sapevano che avrebbero fatto il passaggio ad intel e quindi a maggior ragione hanno ritenuto superfluo il farlo, ed infatti adesso stanno lavorando come muli per finire di ricompilare il S.O. e le vari applicazioni per gli intel, anche se il MacOSX derivando dal NextStep in realtà sono almeno 13 anni che viene ottimizzato sugli x86.

[MenageZero]

mi è rimasto oscuro un punto (dipende sicuramente da me, anche perché non ho mai avuto mac ed è "un pò" che non leggo datasheets e articoli tecnici su osx) nella discussione tra cdimauro e jo.li sull'uso della ram in osx:

con le app "normali" (ovvero a 32bit che di loro non possono indirizzare più di 4GB) se ce ne sono in esecuzione diverse ed il totale di mem. richiesto eccede i 4GB, questa viene loro allocata, tutta come mem fisica intendo, (se fisicamente ce n'è abbastanza ovvio) da osx o esso oltre i 4GB se la tiene comunque per la cache di sistema ?
(se dovessi rispondere a "tu cosa credi di avrer capito ?" o "cosa pensi ?" direi la prima alternativa dato che mi sembra la cosa più logica ed efficente)

[jo.li.]

Originariamente inviato da MenageZero

mi è rimasto oscuro un punto (dipende sicuramente da me, anche perché non ho mai avuto mac ed è "un pò" che non leggo datasheets e articoli tecnici su osx) nella discussione tra cdimauro e jo.li sull'uso della ram in osx:

con le app "normali" (ovvero a 32bit che di loro non possono indirizzare più di 4GB) se ce ne sono in esecuzione diverse ed il totale di mem. richiesto eccede i 4GB, questa viene loro allocata, tutta come mem fisica intendo, (se fisicamente ce n'è abbastanza ovvio) da osx o esso oltre i 4GB se la tiene comunque per la cache di sistema ?
(se dovessi rispondere a "tu cosa credi di avrer capito ?" o "cosa pensi ?" direi la prima alternativa dato che mi sembra la cosa più logica ed efficente)

Esattamente i PoweMac con Tiger ti permetteno di adoperare tutta la memoria fisica per i tuoi programmi, anche quella eccedente i 4GB tanto che i PW hanno otto slot di memoria e arrivano a 16 GB di memoria.

[MenageZero]

Originariamente inviato da jo.li.

Esattamente i PoweMac con Tiger ti permetteno di adoperare tutta la memoria fisica per i tuoi programmi, anche quella eccedente i 4GB tanto che i PW hanno otto slot di memoria e arrivano a 16 GB di memoria.

grazie per la risposta

"...con Tiger..." quindi prima di Tiger oltre i 4GB solo system cache ? Se così, non era una cosa molto "carina" verso gli acquirenti PwMac...
(tanto più se, come spesso leggo, molti lavorano/si dilettano con grafica e video editing/encoding...
oppure nei PwMac precedenti Tiger c'era limitazione hw a 4GB (quindi la cosa di cui sopra era irrilevante)?

[jo.li.]

Originariamente inviato da MenageZero

grazie per la risposta

"...con Tiger..." quindi prima di Tiger oltre i 4GB solo system cache ? Se così, non era una cosa molto "carina" verso gli acquirenti PwMac...
(tanto più se, come spesso leggo, molti lavorano/si dilettano con grafica e video editing/encoding...
oppure nei PwMac precedenti Tiger c'era limitazione hw a 4GB (quindi la cosa di cui sopra era irrilevante)?

Ma no, anche con panther era possibile, soltanto che con tiger sono state introdotte delle ottimizzazioni ulteriori.

[cdimauro]

Originariamente inviato da jo.li.

Interessano anche a me le prestazioni dei proc. ma quando queste siano apprezzabili.

Dipende sempre dall'uso che se ne fa del computer. Io, ad esempio, sono un affamato di prestazioni principalmente a causa della mia passione per gli emulatori...

E' soltanto da quando la intel ha introdotto i Pentium-M che gli x86 hanno un rapporto prestazioni/consumo vicino ai G4, forse hai dimenticato i portatili con i pentium4 che scaldavano come stufette e avevano una autonomia ridicola.

Certo che me li ricordo. Il problema dell'autonomia dei portatili e del consumo delle CPU è stato sempre messo in secondo piano nel mondo x86, dove interessavano principalmente le prestazioni.

Soltanto da qualche anno a questa parte effettivamente s'è sentita l'esigenza di porre attenzione anche a questo punto, e infatti sono soltanti fuori il Pentium-M per Intel e i Turion per AMD (ci sarebbe anche Transmeta, che ne ha fatto invece il proprio cavallo di battaglia fin dall'inizio, ma a ha avuto quote di mercato irrisorie).

Poi i G5 dual-core sono al top delle prestazioni, specialmente nei calcoli in virgola mobile e vettoriali.

Dipende dal tipo di applicazione. Ad esempio nel 3D si fa parecchio uso di calcoli in virgola mobile, ma spesso gli x86 risultano sopra i G5.

[cdimauro]

Originariamente inviato da jo.li.

Ma è proprio perché la differenza è così bassa e che i vantaggi a ricompilare tutto a 64bit sarebbero stati marginali o nulli o addirittura negativi che non è stato fatto e anche se la cosa fosse così banale come dici tu e non lo è,
perché sprecare le risorse in questo modo?

Non ci siamo capiti. Se l'impatto prestazionale derivante dall'aumento della dimensione dei puntatori fosse stato così basso, ad Apple sarebbe convenuto il passaggio a un s.o. interamente a 64 bit perché le applicazioni avrebbero tratto giovamento dall'uso di quantità a 64 bit (pochi i casi; ad esempio la conversione da RGB a YUV e viceversa, molto usata nel campo del video) ma soprattutto dalla possibilità di poter indirizzare direttamente più di 4GB di memoria.

Considerato il target professionale a cui si è sempre rivolta, direi che sarebbe stato molto interessante, non trovi?

Forse già sapevano che avrebbero fatto il passaggio ad intel e quindi a maggior ragione hanno ritenuto superfluo il farlo

Mi sembra strano. Perché a questo punto avrebbero puntato direttamente a un s.o. full 64 bit, che gli avrebbe consentito di ridurre il carico di lavoro per la transizione a x86-64.
Questo perché penso che fossero gli x86 a 64 bit l'obiettivo di Apple: non a caso ha fatto pressioni a Intel per anticipare l'arrivo di Merom e poterlo utilizzare nei primi portatili x86.

Qui, comunque, ricadiamo sul campo delle speculazioni...

[cdimauro]

Originariamente inviato da jo.li.

Esattamente i PoweMac con Tiger ti permetteno di adoperare tutta la memoria fisica per i tuoi programmi, anche quella eccedente i 4GB tanto che i PW hanno otto slot di memoria e arrivano a 16 GB di memoria.

Sì, ma soltanto come cache. Non è certo la stessa cosa di poter indirizzare direttamente tutta la memoria anche oltre i 4GB, cosa che richiede, appunto, la scrittura di apposite applicazioni a 64 bit.

Per il kernel, i driver, e le applicazioni a 32 bit, lo spazio d'indirizzamento rimane sempre a 32 bit, con tutte le conseguenze del caso.

Che poi la memoria oltre i 4GB possa migliorare le prestazioni del sistema grazie al fatto che venga usata come cache, facendo diminuire gli accessi al disco, è sicuramente una cosa buona, ma sembra più che altro una soluzione di ripiego.

[jo.li.]

Originariamente inviato da cdimauro

Dipende dal tipo di applicazione. Ad esempio nel 3D si fa parecchio uso di calcoli in virgola mobile, ma spesso gli x86 risultano sopra i G5.

Non direi proprio guarda questo link:

http://www.barefeats.com/dualcore.html

E qui venivano provati i vecchi Powermac, l'attuale top di gamma il quadricore è il doppio più veloce:

http://www.barefeats.com/quad02.html

[jo.li.]

Originariamente inviato da cdimauro

Mi sembra strano. Perché a questo punto avrebbero puntato direttamente a un s.o. full 64 bit, che gli avrebbe consentito di ridurre il carico di lavoro per la transizione a x86-64.

Non credo che avere il S.O. compilato a 64bit per i PowePc avrebbe potuto rendere più facile la transizione ai x86-64.

[jo.li.]

Originariamente inviato da cdimauro

Sì, ma soltanto come cache. Non è certo la stessa cosa di poter indirizzare direttamente tutta la memoria anche oltre i 4GB, cosa che richiede, appunto, la scrittura di apposite applicazioni a 64 bit.

Per il kernel, i driver, e le applicazioni a 32 bit, lo spazio d'indirizzamento rimane sempre a 32 bit, con tutte le conseguenze del caso.

Che poi la memoria oltre i 4GB possa migliorare le prestazioni del sistema grazie al fatto che venga usata come cache, facendo diminuire gli accessi al disco, è sicuramente una cosa buona, ma sembra più che altro una soluzione di ripiego.

Non è come dici tu, io posso lanciare diverse applicazioni a 32bit oltre il limite dei 4GB:

http://www.apple.com/it/macosx/features/64bit/

[jo.li.]

Originariamente inviato da cdimauro

Dipende dal tipo di applicazione. Ad esempio nel 3D si fa parecchio uso di calcoli in virgola mobile, ma spesso gli x86 risultano sopra i G5.

Guarda anche qua:

http://www.barefeats.com/quad01.html

[cdimauro]

Originariamente inviato da jo.li.

Non direi proprio guarda questo link:

http://www.barefeats.com/dualcore.html

Hai riporto i soliti test del solito sito di fanatici Apple, che in passato è stato sempre sputtanato qui su hwupgrade (prova a fare qualche ricerca e vedrai. ).

Ne riporto uno stralcio, per farti capire la loro bassezza nell'effettuare questi "confronti".

"I was given an opportunity to play with a Dual Core Pentium-D system. It wasn't the fastest dual core available at 2.8GHz, but I thought it would be interesting to compare it to some high end dual cpu G5 Power Macs running at nearly the same clock speed (2.7GHz and 2.5GHz)."

Dice chiaramente che non è il più veloce: infatti è il modello ENTRY LEVEL, che viene confrontato coi G5 TOP DI GAMMA.

L'apoteosi si raggiunge nella frase che ho evidenziato: semplicemente ridicola. Il P4 ha un'architettura nata per scalare in frequenza: non ha senso effettuare dei confronti "clock for clock".

Andavano confrontati i modelli di punta di entrambe le architetture. Punto.

Per confronti "clock for clock" l'unica architettura x86 per cui avrebbe senso farli è quella degli Athlon64, che raggiungono frequenze simili. Ovviamente mancano del tutto all'appello: chissà perché.

Altra chicca:

"I was hoping to include a Dual Core AMD system in this article, but XiComputer, who provided the AMD test units in our previous article, turned me down this time. But hope is not lost. Whisper PC has informed me they will have a dual core AMD for me to test soon with dual GeForce 7800s. Oh yeah."

Questa per loro è una frase di rito: "sappiamo che c'è di meglio e sicuramente aggiorneremo i test". Soltanto che dal 5 agosto a oggi sono passati 3 mesi e mezzo e ovviamente di test aggiornati non se ne vede nemmeno l'ombra...

Ma ormai li conosciamo bene, per cui i loro confronti strampalati lasciano il tempo che trovano.

E qui venivano provati i vecchi Powermac, l'attuale top di gamma il quadricore è il doppio più veloce:

http://www.barefeats.com/quad02.html
Guarda anche qua:

http://www.barefeats.com/quad01.html

Certamente, ma servono soltanto per confrontare i Mac coi Mac, non i Mac coi PC. Servirebbe dei test fra macchine "simili" (dual core SMP anche per i PC).

Non credo che avere il S.O. compilato a 64bit per i PowePc avrebbe potuto rendere più facile la transizione ai x86-64.

Perché no? Effettuare un porting completo a 64 bit di un s.o. non vuol dire soltanto scrivere qualche parte del kernel in assembly per il processore a 64 bit. Ci sono da aggiornare anche le API, il modello dei driver, scrivere un wrapper per le applicazioni a 32 bit.

Non è come dici tu, io posso lanciare diverse applicazioni a 32bit oltre il limite dei 4GB:

http://www.apple.com/it/macosx/features/64bit/

Mi fai vedere cos'è che in questa pagina conferma quanto hai scritto?

Io trovato soltanto questo:

"Anche le applicazioni a 32 bit traggono beneficio dalla possibilità di accedere a grandi quantità di memoria: il sistema può infatti manipolare i dati in diverse applicazioni interamente nella RAM, massimizzando le prestazioni."

Che però conferma (il grassetto è il mio) quello che avevo detto io...

[jo.li.]

Originariamente inviato da cdimauro

Dice chiaramente che non è il più veloce: infatti è il modello ENTRY LEVEL, che viene confrontato coi G5 TOP DI GAMMA.

Andavano confrontati i modelli di punta di entrambe le architetture. Punto.

Per confronti "clock for clock" l'unica architettura x86 per cui avrebbe senso farli è quella degli Athlon64, che raggiungono frequenze simili. Ovviamente mancano del tutto all'appello: chissà perché.

Altra chicca:

"I was hoping to include a Dual Core AMD system in this article, but XiComputer, who provided the AMD test units in our previous article, turned me down this time. But hope is not lost. Whisper PC has informed me they will have a dual core AMD for me to test soon with dual GeForce 7800s. Oh yeah."

Questa per loro è una frase di rito: "sappiamo che c'è di meglio e sicuramente aggiorneremo i test". Soltanto che dal 5 agosto a oggi sono passati 3 mesi e mezzo e ovviamente di test aggiornati non se ne vede nemmeno l'ombra...

Ma ormai li conosciamo bene, per cui i loro confronti strampalati lasciano il tempo che trovano.


Perché no? Effettuare un porting completo a 64 bit di un s.o. non vuol dire soltanto scrivere qualche parte del kernel in assembly per il processore a 64 bit. Ci sono da aggiornare anche le API, il modello dei driver, scrivere un wrapper per le applicazioni a 32 bit.

Mi fai vedere cos'è che in questa pagina conferma quanto hai scritto?

Io trovato soltanto questo:

"Anche le applicazioni a 32 bit traggono beneficio dalla possibilità di accedere a grandi quantità di memoria: il sistema può infatti manipolare i dati in diverse applicazioni interamente nella RAM, massimizzando le prestazioni."

Che però conferma (il grassetto è il mio) quello che avevo detto io...

Nel test che ti ho postato, effettuato ad agosto come confronto c'è un dual processor Xeon a 3,4 GHz con alcuni test effettuati su windows 64 con applicazioni scritte a 64bit, non direi proprio che sia un entry-level.

Continuo a non capire perché riscrivere un Os a 64bit per una architettura completamente diversa avrebbe potuto favorire il passaggio agli x86 a 64bit??

Forse il fatto che ci sia scritto che le applicazioni a 32 bit possono accedere a tutta la ram fisica ma non possono allocare più di 4Gygabyte di memoria non ti è chiaro??

[cdimauro]

Originariamente inviato da jo.li.

Nel test che ti ho postato, effettuato ad agosto come confronto c'è un dual processor Xeon a 3,4 GHz con alcuni test effettuati su windows 64 con applicazioni scritte a 64bit, non direi proprio che sia un entry-level.

Non è così. Leggi bene:

"TEST CONFIGURATIONS
Dual Core Pentium-D 2.8GHz
The motherboard is the D945GCZLR. The CPU is the Intel Pentium-D 820 (2.8GHz dual-core with EMT-64, 1MB L2 cache per CPU and 800MHz FSB). Memory runs at 533Mhz."

Continuo a non capire perché riscrivere un Os a 64bit per una architettura completamente diversa avrebbe potuto favorire il passaggio agli x86 a 64bit??

Guarda che i s.o. non sono scritti interamente in assembly. La dipendenza dalla specifica architettura riguarda una piccola parte di un s.o., che per il resto sono scritti quasi interamente in linguaggi ad alto livello.

Il punto è che, ad esempio, quando un s.o. devo ritornare un handle (che sotto sotto può essere un puntatore a una struttura, sia essa del kernel o no), attualmente lo fa usando un intero a 32 bit, ma per un'architettura a 64 bit è chiaro che non va più bene. Quindi il codice va rivisto, usando degli appositi tipi.

Non so se hai esperienza di programmazione usando le API di un s.o.: l'esempio dovrebbe essere chiaro in questo caso.

Forse il fatto che ci sia scritto che le applicazioni a 32 bit possono accedere a tutta la ram fisica ma non possono allocare più di 4Gygabyte di memoria non ti è chiaro??

E' chiarissimo, infatti: NON C'E' SCRITTO DA NESSUNA PARTE CHE POSSANO ACCEDERVI. Infatti è il SISTEMA che lo fa (per loro: usando la memoria oltre i 4GB come cache). Ergo: vale esattamente ciò che avevo già scritto.

[bjt2]

Scusa, ma il G5 non ha la paginazione come gli x86? Sugli x86 è TEORICAMENTE possibile sfruttare la ram oltre i 4GB (con Linux appositamente compilato e Windows server) usando le PAE, che aumentano i bit nella tabella delle pagine. Ogni processo potrà usare solo 4GB alla volta, ma l'intero sistema può usare fino a 64GB (Windows XP supporta solo 4GB, quindi non supporta le PAE, ma la versione server si).

Per i G5 non c'è una cosa simile?

Questo è il punto. Mi pare di aver capito, da quello che dici, che non è possibile, per i processi a 32 bit, allocare la propria RAM oltre i 4GB fisici. Se fosse così, allora i G5 sarebbero indietro agli x86!!!

In definitiva: i G5 non hanno qualcosa di simile alla PAE? Le pagine di un processo sono limitate a stare nei primi 4GB di memoria? Se è così, allora ha ragione CDmauro. QUalcuno lo sa?