Link alla notizia: http://www.hwupgrade.it/news/apple/15250.html

La compagnia di Cupertino stringe accordi con Freescale per la fornitura di processori PowerPC G4 fino alla fine del 2008

Click sul link per visualizzare la notizia.

la verità è che vogliono battere il record: 10 anni con uno stesso processore desktop di sicuro lo è :D

tanto tra un mese ci diranno qualcosa di diverso....

Ma non capisco, i G5 fanno cosi' schifo????

E, scusate l'ignoranza, ma dopo quale processore useranno?

Ma non capisco, i G5 fanno cosi' schifo????
Non è che prestazionalmente fanno schifo, è che sono dei piccoli prescottini, scladano e consumano che è un piacere , il powermac sono anni che ha un alimentatore da 600watt di serie.. se solo l'ibm avesse fatto uscire qualche revisone più raffinata e magari con processo produttivo a 90nm sarebbe stato meglio.


E, scusate l'ignoranza, ma dopo quale processore useranno?

Processori Intel X86 :stordita:

fino al 2008 con i g4? vabbè che i G5 costano di +, ma vanno anche decisamente meglio!

questo significa che il G5-Mobily (o meglio G5 a basso consumo) che IBM aveva annunciato non ci sarà mai oppure arriverà molto in ritardo :( ...
quindi i portatili Apple avranno processori dell'ormai obsoleta famiglia G4 fino all'arrivo dei processori Intel (presumibilmente core Merom) :(

fino al 2008 con i g4? vabbè che i G5 costano di +, ma vanno anche decisamente meglio!

piccolo problema consumano uno sproposito e scaldano di più...i consumi sono come quelli dei prescott single core ossia superano i 100W e su un portatile significa avere delle dimensioni dello chasiss troppo grandi, un peso abnorme ed un'autonomia ridicola...
scegli tu...il gioco vale la candela? :stordita:

nell' articolo nn c'è scritto che i g5 saranno abbandonati ... nn ce ne sarebbe motivo ... io la penso come nell'articolo e cioè ... scorte x l'assistenza

Non è che prestazionalmente fanno schifo, è che sono dei piccoli prescottini, scladano e consumano che è un piacere , il powermac sono anni che ha un alimentatore da 600watt di serie.. se solo l'ibm avesse fatto uscire qualche revisone più raffinata e magari con processo produttivo a 90nm sarebbe stato meglio.

600W ma hanno (quasi tutti) un dual.
Inoltre SONO a 90nm da un annetto a questa parte, ma il passaggio 130->90nm è stato decisamente deludente migliorando la frequenza di solo 500mhz (contro i previsti 1000) e a costo di consumi esagerati, da cui il raffreddamento a liquido e gli alimentatori esagerati...

Il 2007 è lontano e la migrazione completa dovrebbe durare almeno due anni. Il fatto che si siano impegnati fino al 2008 credo sia normale anche solo per coprire le scorte dei resi/garanzie dei prodotti commercializzati da qui a fine 2006 (data in cui verosimilmente venderanno più x86 che g4).

Non è che prestazionalmente fanno schifo, è che sono dei piccoli prescottini, scladano e consumano che è un piacere , il powermac sono anni che ha un alimentatore da 600watt di serie.. se solo l'ibm avesse fatto uscire qualche revisone più raffinata e magari con processo produttivo a 90nm sarebbe stato meglio.

E allora perchè non scegliere di integrare i prescott direttamente??? :muro:

Su un portatile è molto meglio il G4 :O
Altrimenti un 15 che pesi 2,5 kg la vedo dura.

mettere i G5 attuali nei notebook è inutile...
la priorità in un prodotto mobile è la mobilità...

se devono essere pesanti e limitati come dei normali notebook windows non ne vale la pena...
al momento con un Pb12" di 6 mesi (1.33Ghz) riesco agilmente a codificare un dvd di immagini con iDVD...più che decoroso per le dimensioni e i consumi molto ridotti rispetto ad una controparte windows dello stesso prezzo (lasciando stare le dimensioni visto che non ci sono confronti...)

cmq essendo utente mac da poco non sento tanto la guerra di religione...
spero solo che la Apple riesca a produrre portatili come questi con processori Intel....speriamo che aggirino i vincoli di consumo, calore e dimensioni per mantenere lo standard attuale...

Ciao!

quindi i portatili Apple avranno processori dell'ormai obsoleta famiglia G4 fino all'arrivo dei processori Intel (presumibilmente core Merom) :(

a naso direi fino agli yonah, più che merom...

600W ma hanno (quasi tutti) un dual.

sono comunque tanti

ti sbagli Fx, il primo Pentium M che verrà montato sui notebook Apple sarà un Dual core 64bit :O ossia un Merom!!! e se guardi il periodo di uscita di questo core tutto combacia con le date di Apple ;)

Ma i powerbook G5 quando???
E' uscito poco tempo fa un articolo che parlava di G5 con TDP grosso modo uguale a quello dei centrino...

E allora perchè non scegliere di integrare i prescott direttamente??? :muro:
Per farla semplice :
Apple passerà ad Intel non tanto per i prescott , semplicemente ha visto che l'ibm non si dava una mossa con lo sviluppo sui ppc ha preferito cambiare con Intel perchè almeno lei aveva una roadmap interessante ed un continuo ricambio di idee e tecnologie, certo allo stato attuale non ha da offire chissà che cosa, ma le aziende guardano a lungo termine, se l'Intel realizza almeno la metà di quello che ha mostrato all' IDF , la scelta di Jobs non è poi tanto azzardata .Invece guardando L'ibm cos'ha al momento? questo cell, ok è puutente, ma nel general purpose zoppica,e lasciamo stare i problemi di produzione che sta incontrand, i sw devono cmq essere convertiti , ma dopo 3-4 anni di vita dell architettura del cell cosa farebbe IBM? un cell 2 "la vendetta" (:asd:) solo per la apple ? non credo ; ha anche presentato dei fantomatici g5 a 65nm e i freescale...ma sono solo parole.

ti sbagli Fx, il primo Pentium M che verrà montato sui notebook Apple sarà un Dual core 64bit :O ossia un Merom!!! e se guardi il periodo di uscita di questo core tutto combacia con le date di Apple ;)

Sono convinto anch'io. Inoltre ci sarebbe l'innegabile vantaggio di poter essere fin dall'inizio a 64bit, senza difficoltose ulteriori transizioni successive....

I g4 fino al 2008 sono soltanto per le scorte, entro metà 2007 tutta la gamma sarà passata ad Intel (parole di Steve). Riguardo i Pentium-M i primi ad andare sui mac non saranno i merom ma gli yonah, presumibilmente dual core sui powerbook e single core su mini/ibook/emac, verso metà 2006 quando saranno pronti, ed i primi a beneficiarne saranno proprio i mac che ora montano un g4.

Sono convinto anch'io. Inoltre ci sarebbe l'innegabile vantaggio di poter essere fin dall'inizio a 64bit, senza difficoltose ulteriori transizioni successive....

parlare di difficoltose transizioni tra x86 a 32 bit e a 64 bit con i 64 bit in grado di far girare senza nessun problema il codice a 32 mi fa sorridere, considerato che stiamo parlando di quell'apple che sta passando alla terza famiglia di processori da quando produce i mac =)

la questione va posta se caso più in termini di opportunità che di difficoltà, avere tutta la base x86 a 64 bit è una buona opportunità: anche se all'inizio mac os x per x86 fosse ancora a 32 bit comunque sarebbe possibile poi realizzare una versione integralmente a 64 bit senza il bisogno di doverne fare anche una a 32. sarà interessante vedere se mac os x sarà fin da subito a 64 bit o meno, per quanto riguarda la versione PowerPC pur avendo una cpu a 64 bit a disposizione da oltre 2 anni più che qualche ottimizzazione qua e là non è stato fatto: imho apple potrebbe esser di fronte alla stessa noia che ha incontrato microsoft con win xp x64, ovvero convertire aggiustare testare tutti i driver. per di più non è detto che con tutti le cose a cui pensare per la migrazione i 64 bit siano un obiettivo prioritario di apple, anche perchè io ho la stessa roadmap citata da ShinjiIkari, che vede per l'uscita dei laptop x86 di apple pronto e disponibile in volume lo yonah, non il merom.

tra l'altro dai, già con lo yonah chi passerà da un ibook / powerbook g4 ad un ibook / powerbook intel avrà l'impressione che apple gli abbia infilato un powermac di quelli pompati dentro il portatile, se poi mettono direttamente il merom ciao, viene loro direttamente un coccolone :D

azz... mi sembra un'eternita' :what: :coffee: :tapiro:

parlare di difficoltose transizioni tra x86 a 32 bit e a 64 bit con i 64 bit in grado di far girare senza nessun problema il codice a 32 mi fa sorridere, considerato che stiamo parlando di quell'apple che sta passando alla terza famiglia di processori da quando produce i mac =)
...

Un passaggio 32 bit -> 64 bit non è meno traumatico di uno PowerPC -> Intel o del precedente 68K->PowerPC, avendo un emulatore della vecchia architettura veloce e trasparente (quello 68K lo era, e anche Rosetta promette bene).

Vanno riscritti i drivers, le applicazioni devono avere 2 binari differenti, ecc. Una palla. Per questo XP/64 non decolla.
Inoltre gli x86 non sono stati pensati fin dall'inizio per essere a 64bit come i PowerPC, quindi un approccio misto 32/64 bit come quello odierno di Tiger (a quanto ho capito) non è tecnicamente possibile su Intel: o tutto a 32 o tutto a 64 bit.

Infine, visto che con il passaggio a 64bit Intel e AMD hanno sistemato alcuni difetti cronici dell'archiettura x86, come il numero di registri, ad andare a 64bit nel caso Intel si avrebbero dei vantaggi prestazionali (con il PowerPC è controproducente).

Quindi una buona opportunità indubbiamente. Sarebbe stupido perderla per uscire solo 1-6 mesi prima del necessario (i primi MacTel sono stati annunciati per Giugno 2006, il Merom per la seconda metà del 2006).

Un passaggio 32 bit -> 64 bit non è meno traumatico di uno PowerPC -> Intel o del precedente 68K->PowerPC, avendo un emulatore della vecchia architettura veloce e trasparente (quello 68K lo era, e anche Rosetta promette bene).

dire che il passaggio da 32 a 64 bit su una stessa famiglia di processori non è meno traumatico di un passaggio da una famiglia all'altra è una forzatura... spero che questa sia solo una provocazione. anche perchè forse ti dimentichi che mac os x per x86-32 esiste da anni: sviluppare ora un mac os x a 64 bit per gli x86 sarebbe un buon sistema di rimandare alla prossima decade lo switch agli x86 =)

Vanno riscritti i drivers, le applicazioni devono avere 2 binari differenti, ecc. Una palla. Per questo XP/64 non decolla.

calma.

1) i driver vanno si riscritti, ma il grosso del lavoro è fatto e l'ha fatto microsoft. se hai un pc che non ha hardware esotico sei a posto.
2) ma chi t'ha detto che un'applicazione a 32 bit non funziona sotto windows xp x64? sotto win xp x64 funzionano le applicazioni a 64 bit E a 32 bit (quelle a 16 bit, pur essendo l'hardware in grado, non sono supportate dal sistema operativo). xp x64 non decolla semplicemente perchè i 64 bit devono ancora diffondersi tra le masse, e perchè comunque non è che attualmente comporti questi grandi vantaggi... solo quando per l'appunto sarà lo standard le ottimizzazioni per le nuove feature dei processori x86 a 64 bit (e non per i 64 bit in sè, che portano pochi vantaggi a livello prestazionale a meno di non usare tonnellate di ram) si sentiranno

Inoltre gli x86 non sono stati pensati fin dall'inizio per essere a 64bit come i PowerPC, quindi un approccio misto 32/64 bit come quello odierno di Tiger (a quanto ho capito) non è tecnicamente possibile su Intel: o tutto a 32 o tutto a 64 bit.

senti, l'approccio misto di tiger non esiste, è solo una trovata commerciale: un os o è a 32 bit o è a 64 bit, e mac os x è a 32 bit... le "ottimizzazioni" per i 64 bit son poco più che una trovata per giustificare il fatto di avere da 2 anni dei processori a 64 bit e non avere un sistema operativo a 64 bit. è a 64 bit come era a 32 bit windows 95.

per quanto riguarda gli x86, nemmeno l'8086 a 16 bit che intel partorì nel 1978 era pensato per diventare un giorno a 32, eppure di problemi a far funzionare applicazioni a 16 bit non ce ne sono stati. allo stesso modo gli x86 a 64 bit: come ti dicevo prima, se non ricompili l'applicazione ti perdi solamente le nuove feature introdotte con gli x86-64, ma per il resto tutto funziona.

Infine, visto che con il passaggio a 64bit Intel e AMD hanno sistemato alcuni difetti cronici dell'archiettura x86, come il numero di registri, ad andare a 64bit nel caso Intel si avrebbero dei vantaggi prestazionali (con il PowerPC è controproducente).

non sono difetti, sono scelte architetturali che approfittando del passaggio ai 64 bit vengono riviste perchè per l'appunto rappresentano oggi un collo di bottiglia (niente di drammatico, però qualche punto percentuale in più lo si guadagna).

il fatto che un'applicazione x86 ricompilata a 64 bit possa avere in media un incremento prestazionale su un processore Intel di oggi dipende dal tipo di applicazione ma nel complesso è falso, in quanto l'implementazione dei 64 bit di Intel, esattamente come la sua interpretazione del concetto di "dual core", è fatta col culo =) se AMD ha ottimizzato diversi aspetti, proprio perchè gli AMD64 come dice il nome stesso nascono a 64 bit, i 64 bit di Intel si appoggiano su un'architettura che è ancora a 32 bit. per quanto riguarda gli AMD64, si, l'incremento prestazionale c'è.

c'è ovviamente da sperare che merom, come d'altro canto le nuove generazioni di processori intel, abbia un'implementazione dei 64 bit e del dual core fatta come si deve.

Quindi una buona opportunità indubbiamente. Sarebbe stupido perderla per uscire solo 1-6 mesi prima del necessario (i primi MacTel sono stati annunciati per Giugno 2006, il Merom per la seconda metà del 2006).

il problema è che se alla seconda metà aggiungi la disponibilità in grossi volumi andiamo nella migliore delle ipotesi a cavallo con il 2007: per giugno 2006 ci si starà al pelo con lo yonah, che comunque al di là di tutto è un signor processore e ti garantisco che sarà in grado di fornire prestazioni da urlo.

il problema comunque non è un problema a livello di cpu, è - come dicevo all'inizio - che mac os x per x86-32 è pronto da anni, e in questa fase delicata sarebbe azzardato - e imho anche oltre le possibilità - puntare ai 64 bit.

Mah, saranno principalmente per Powerbook.

questo evidenzia come sia difficile fare un processore G5 per portatile.

Ricordo i primi prototipi: 20 minuti di autonomia e la batteria ti salutava.....

>un os o è a 32 bit o è a 64 bit, e mac os x è a 32 bit...

Le API Cocoa sono a 32 il libsystem (the system library implementing most of the fundamental UNIX APIs) a 64. Puoi sviluppare tools (appplicazioni senza GUI) a 64. Le applicazioni (GUI) a 32. Ora: i 64 servono per Word o iCal? No. Per Mathematica? Si. Infatti Mathematica, anche per G5, e' a 64bit quindi la GUI e' separata dal kernel. Ottima scelta. Il fatto che Maxxon invece abbia detto che non ci sara' una versione a 64bit per G5 ->QUESTA e' una scusa commerciale<-, perche' a meno che non sappiano programmare (e invece la sanno) avrebbero potuto tenere la GUI cosi' come e' e rimodellare gli algoritmi.

Un bravo a Criceto.

x FX: non hai risposto alla mail. Mi piacerebbe sapere cosa ne pensi dell'altro punto di vista...

Per togliere qualche dubbio e chiarificare:

http://developer.apple.com/macosx/64bit.html

dire che il passaggio da 32 a 64 bit su una stessa famiglia di processori non è meno traumatico di un passaggio da una famiglia all'altra è una forzatura... spero che questa sia solo una provocazione. anche perchè forse ti dimentichi che mac os x per x86-32 esiste da anni: sviluppare ora un mac os x a 64 bit per gli x86 sarebbe un buon sistema di rimandare alla prossima decade lo switch agli x86 =)

Magari è un po' una forzatura, ma per gli utenti è lo stesso: devono comunque ricomprare il software anche a 64 bit per avere migliori prestazioni ed aggiornare i driver delle periferiche (se il produttore li fà, altrimenti niente periferica). Certo si possono tenere il software a 32bit ma con una leggera penalizzazione delle prestazioni, così come ora con programmi PowerPC passando ad Intel (grazie a Rosetta) o prima i programmi 68K (alcuni andavano più veloci emulati sul nuovo hardware!).

Per gli sviluppatori ad alto livello, anche è lo stesso. Se hanno scritto bene il software gli basta una ricompilata. Al massimo qualche ottimizzazione quà e là. Però devono distribuire il loro software per un po' di anni in 2 versioni differenti (32bit e 64bit). Mentre i produttori di driver credo sia un po' più complesso.

Per il fatto di Tiger a 64 bit ti ha risposto Samslaves.

E' vero però che l'ostacolo principale nel partire direttamente a 64 bit su Intel è dovuto al fatto se hanno già pronto l'OS oppure no. Al momento pare di no (le macchine per gli sviluppatori sono a 32 bit). Però si sono dati (almeno) un anno di tempo per farlo uscire, magari fanno in tempo a fare il passaggio.

è a 64 bit come era a 32 bit windows 95.
COUGH. COUGH. E' a 32 bit... ;)
il fatto che un'applicazione x86 ricompilata a 64 bit possa avere in media un incremento prestazionale su un processore Intel di oggi dipende dal tipo di applicazione ma nel complesso è falso, in quanto l'implementazione dei 64 bit di Intel, esattamente come la sua interpretazione del concetto di "dual core", è fatta col culo =) se AMD ha ottimizzato diversi aspetti, proprio perchè gli AMD64 come dice il nome stesso nascono a 64 bit, i 64 bit di Intel si appoggiano su un'architettura che è ancora a 32 bit. per quanto riguarda gli AMD64, si, l'incremento prestazionale c'è.
Occhio che l'implementazione attuale dei 64 bit da parte di Intel è per l'architettura NetBurst: penso che quella per i Pentium-M sarà alquanto diversa... ;)
il problema comunque non è un problema a livello di cpu, è - come dicevo all'inizio - che mac os x per x86-32 è pronto da anni, e in questa fase delicata sarebbe azzardato - e imho anche oltre le possibilità - puntare ai 64 bit.
La penso come te: se Apple deve fare lo switch sugli x86, tanto vale partire subito con un'architettura a 64 bit, altrimenti si ritroverebbe come MS con XP e XP x64...

Le API Cocoa sono a 32 il libsystem (the system library implementing most of the fundamental UNIX APIs) a 64. Puoi sviluppare tools (appplicazioni senza GUI) a 64. Le applicazioni (GUI) a 32. Ora: i 64 servono per Word o iCal? No. Per Mathematica? Si.
A parte la difficoltà dell'approccio ai 64 bit di Tiger, con x86 il discorso è molto diverso: i 64 bit non portano soltanto un "allargamento" dei registri, ma altri miglioramenti architetturali. Quindi Word e iCalc x86-64 hanno, eccome, un senso.
Infatti Mathematica, anche per G5, e' a 64bit quindi la GUI e' separata dal kernel.
Ottimo. E le motivazioni quali sono? Indirizzare più di 4GB di memoria? Non credo, anzi...
Ottima scelta. Il fatto che Maxxon invece abbia detto che non ci sara' una versione a 64bit per G5 ->QUESTA e' una scusa commerciale<-, perche' a meno che non sappiano programmare (e invece la sanno) avrebbero potuto tenere la GUI cosi' come e' e rimodellare gli algoritmi.
Non è una scusa commerciale e le motivazioni le hanno spiegate MOLTO chiaramente: basta leggerle e cercare di capire.

Avevano esigenze MOLTO diverse da quelle di Mathematica.

Mica tutti i software sono uguali...

E' vero però che l'ostacolo principale nel partire direttamente a 64 bit su Intel è dovuto al fatto se hanno già pronto l'OS oppure no. Al momento pare di no (le macchine per gli sviluppatori sono a 32 bit). Però si sono dati (almeno) un anno di tempo per farlo uscire, magari fanno in tempo a fare il passaggio.
Non credo che ci voglia molto a riscrivere quelle poche porzioni di codice assembly per far girare Tiger (o Leopard) su x86-64.

Per riscrivere Mac OS X per x86-64 non credo ci voglia di più del tempo che c'è voluto con Linux.

Per la questione compatibilità: ATTENZIONE. Gli x86-64 sono compatibili con software a 16 bit (compresi gli 8086 virtuali) SOLO in modalità 32-bit. In "long mode" il supporto ai 16 bit scompare completamente: niente virtual-8086, nessun supporto alle macchine DOS virtuali, i programmi windows a 16 bit, compresi purtroppo alcuni installer ( :( ), NON FUNZIONANO!. E' questo, secondo me, un altro motivo che ritarda l'uscita di windows x86.64.

la verità è che vogliono battere il record: 10 anni con uno stesso processore desktop di sicuro lo è :D

:asd: :asd:

nell' articolo nn c'è scritto che i g5 saranno abbandonati ... nn ce ne sarebbe motivo ... io la penso come nell'articolo e cioè ... scorte x l'assistenza

Credo anche io, altrimenti che senso avrebbe...

samslaves: il problema è che per essere a 64 bit non basta il libsystem. un os a 32 bit con qualcosa a 64 bit (tra l'altro proprio ciò che si trovava "già pronto" a 64 bit, dato che le api di unix non le sviluppa apple) non è un os a 64 bit. è un os a 32 bit con qualche api a 64.

per l'email: scusa ma mi sono perso. ti rispondo subito.


criceto: non è "un po'" una forzatura, è una forzatura bella e buona. metti nel calderone il tempo e le energie impiegati da apple per lo switch... mac os x per x86 non arriva mica gratis. rosetta tanto meno. se l'utente sarà quello che se ne accorgerà di meno, per gli sviluppatori è stato e sarà un lavoraccio.

quando dici poi "se hanno scritto bene il software gli basta una ricompilata" mi sembri una faccia di palta quanto jobs... non dire "se l'hanno scritto bene", dì piuttosto "se l'hanno scritto con xcode", dato che chi ha creato applicazioni con altri strumenti di sviluppo s'attacca al cazzo... il tuo ragionamento è fuorviante, il fatto che nella migliore delle ipotesi il cambio di architettura sia impattante quanto il passaggio dai 32 ai 64 bit per gli x86 non vuol dire che MEDIAMENTE sia così. è solo la migliore delle ipotesi, che se hai vissuto nello stesso mondo in cui ho vissuto io raramente si verifica.

cidimauro: si, è a 32 bit ma in modalità non protetta, quindi per me è a 16 bit :D scherzi a parte, si, mi son sbagliato

per quanto riguarda l'implementazione attuale dei 64 bit di intel, beh, me lo auguro davvero che un domani possa esser diversa, quella attuale è paradossale

per quanto riguarda il passaggio ai 64 bit, secondo me essendo che mac os x per x86 c'è già ed è a 32 bit ho dubbi che lo vedremo a 64 bit tra 1 anno.

bjt2: per fare il porting da 32 a 64 bit di mac os x, mi permetto di dubitare che non ci voglia molto altrimenti a quest'ora ci sarebbe già stato un mac os x a 64 bit per powerpc. il problema potrebbe essere anche a livello di driver, a quant'ho capito il casino maggiore è sistemare questo aspetto (dato che quelli inclusi in un os moderno sono migliaia)

per quanto riguarda gli x86-64, possono funzionare in due modalità, di cui una è chiamata "compatibility mode": in questa modalità la cpu è in grado di digerire anche il codice a 16 bit.

Per quanto riguarda il passaggio a 64 bit di Mac OS X, è possibile che non ci voglia poco, primo, perchè è possibile che non basti una ricompilata, se il programma non è stato scritto bene (Mathematica ha richiesto la modifica di poche linee di codice ed una ricompilata, ma non è sempre così semplice: ho scritto un programma in ANSI C/POSIX ed ho dovuto fare una patch quando l'ho compilato su un Alpha della digital, a 64 bit, per inciso questo programma compila sotto Linux, windows, Mac OS X, Solaris, Digital e VMS ed è endianess aware), secondo, perchè alcuni drivers non li fa apple (per esempio delle schede video) e si deve aspettare il produttore.

Per quanto riguarda la compatibilità a 16 bit: anche io ho detto che la compatibilità ai 16 bit si ha in modo a 32 bit, ho solo omesso di chiamarlo compatibility mode... ;)

criceto: non è "un po'" una forzatura, è una forzatura bella e buona. metti nel calderone il tempo e le energie impiegati da apple per lo switch... mac os x per x86 non arriva mica gratis. rosetta tanto meno. se l'utente sarà quello che se ne accorgerà di meno, per gli sviluppatori è stato e sarà un lavoraccio.
Ma lascia perdere dai: son convinti delle loro opinioni...
Magari Leopard seguirà un approccio alla Tiger per i 64 bit, mantenendo i driver a 32 bit per far felice chi invoca la compatibilità...
Male che va, ci sono sempre i FAT-binary, no? Dentro gli infiliamo codice per 68000, PowerPC, x86 e x86-64: e vissero tutti felici e contenti... :p
cidimauro: si, è a 32 bit ma in modalità non protetta, quindi per me è a 16 bit :D scherzi a parte, si, mi son sbagliato
COUGH COUGH :p :)
per quanto riguarda l'implementazione attuale dei 64 bit di intel, beh, me lo auguro davvero che un domani possa esser diversa, quella attuale è paradossale
Non può essere uguale già per il solo fatto che NetBurst e Pentium-M sono implementazioni estremamente diverse. Non credo che per i futuri Pentium-M introdurrano le ALU double-pumped a 16 bit, principale causa del decadimento prestazionale dei P4 a 64 bit...
per quanto riguarda il passaggio ai 64 bit, secondo me essendo che mac os x per x86 c'è già ed è a 32 bit ho dubbi che lo vedremo a 64 bit tra 1 anno.
Darwin dovrebbe girare già su sistemi a 64 bit, quindi non credo che ci siano particolari problemi...
bjt2: per fare il porting da 32 a 64 bit di mac os x, mi permetto di dubitare che non ci voglia molto altrimenti a quest'ora ci sarebbe già stato un mac os x a 64 bit per powerpc.
Non ci vuole molto, tant'è che il supporto ad applicazioni a 64 bit, per quanto limitato, c'è già. Con Tiger hanno semplicemente una soluzione di compromesso: comoda e veloce da implementare, e soprattutto senza spargimenti di sangue dovuti alla riscrittura dei driver per un nuovo driver model.
il problema potrebbe essere anche a livello di driver, a quant'ho capito il casino maggiore è sistemare questo aspetto (dato che quelli inclusi in un os moderno sono migliaia)
Esatto, è proprio questo il problema: la quantità di driver da riscrivere...

samslaves: il problema è che per essere a 64 bit non basta il libsystem. un os a 32 bit con qualcosa a 64 bit (tra l'altro proprio ciò che si trovava "già pronto" a 64 bit, dato che le api di unix non le sviluppa apple) non è un os a 64 bit. è un os a 32 bit con qualche api a 64.

Contrariamente agli x86 i PowerPC possono usare un indirizzamento a 32 bit e a 64 bit contemporaneamente su processi differenti. Quindi anche se Tiger è sostanzialmente a 32bit alcune parti sono ANCHE a 64bit per i G5.
In particolare tutte le API POSIX. Come dire UNIX. Non una parte piccolissima... e probabilmente qualcos'altro (sicuramente qualche routine per la gestione memoria).

Come dire che su OS X hai un Unix BSD a 64bit e un NeXT e Mac Classic a 32 bit. Il tutto CONTEMPORANEAMENTE.
Tutte le applicazioni Posix, quindi backend di database o di programmi complessi che macinano numeri tipo Mathematica, possono essere a 64bit e comunicare con un'interfaccia Cocoa o Carbon a 32 bit.

Rassegnati e chiudiamo qui questa discussione.

Putroppo su x86 questo approccio non è possibile, quindi se Apple non parte direttamente a 64bit con Tiger/86 avrà i problemi che incontra ora M$ quando si deciderà di fare il passaggio.

bjt2: è quello che dicevo quando dicevo questo:

quando dici poi "se hanno scritto bene il software gli basta una ricompilata" mi sembri una faccia di palta quanto jobs... non dire "se l'hanno scritto bene", dì piuttosto "se l'hanno scritto con xcode", dato che chi ha creato applicazioni con altri strumenti di sviluppo s'attacca al cazzo... il tuo ragionamento è fuorviante, il fatto che nella migliore delle ipotesi il cambio di architettura sia impattante quanto il passaggio dai 32 ai 64 bit per gli x86 non vuol dire che MEDIAMENTE sia così. è solo la migliore delle ipotesi, che se hai vissuto nello stesso mondo in cui ho vissuto io raramente si verifica.

per quanto riguarda i 16 bit, la compatibility mode dei 64 bit intendevo, non a 32... a 64 bit si può infatti lavorare in due modalità, di cui una "compatibility"... ma sei sempre a 64 bit!

cdimauro: per quanto riguarda win 95, stavolta confermo, è in modalità non protetta, più precisamente in modalità flat (ovvero con puntatori a 32 bit sulla ram), per questo motivo se un'applicazione crashava in malo modo si trascinava con sè tutto l'os

criceto: eddaje :muro: gli x86 a 64 bit in modalità 64 bit "compatibility" possono usare contemporaneamente l'indirizzamento a 64, 32 e 16 bit... fai poi te.

non mi rassegno per il semplice fatto che ti sbagli =)

apple partirà sugli x86 con un os a 32 bit con al max quattro cose a 64, com'è adesso tiger, per lo meno con ciò che ci è dato sapere ad oggi scommetterei senza dubbio su questa possibilità

criceto: eddaje :muro: gli x86 a 64 bit in modalità 64 bit "compatibility" possono usare contemporaneamente l'indirizzamento a 64, 32 e 16 bit... fai poi te.

Prova con Win32 a scrivere un programma a 64bit. poi vedi se ti gira...
A far girare i 32bit avendone 64 sono buoni tutti...

Ho capito quello che dice Criceto: se ho un power PC G5, anche se uso un SO a 32 bit, posso usare i registri a 64 bit per i calcoli matematici, perchè i 64 bit sono una caratteristica del processore. Questo è vero, ma il SO è comunque a 32 bit e vedi solo 4 GB di RAM. Così perdi il vantaggio maggiormente pubblicizzato dei 64 bit: oltre i 4 GB di RAM. I 64 bit sono una caratteristica del processore e non del SO. Con gli A64 puoi usare i calcoli a 64 bit SOLO SE USI UN SO a 64 BIT. Ma puoi usare anche più di 4GB alla volta... Questo è un merito del POWER PC E NON DI MAC OS X.

al di là che l'impatto sulle performance derivanti dalle operazioni a 64 bit è marginale e interessa solo ristretti ambiti d'impiego, non ci giurerei che non sia possibile... col dos a 16 bit io usavo i registri a 32, non escludo che fino ad usare i registri a 64 bit con un os a 32 si possa anche fare, comunque è lana caprina perchè non è di certo questo ciò che interessa dei 64 bit... ciò che interessa dei 64 bit è:
a) l'indirizzamento comodo della ram oltre i 4 gb (ricordo che gli x86 a 32 bit sono in grado di indirizzare più di 4 gb di ram, solo che devi fare un po' di menate per lavorarci a livello di software)
b) l'incremento di performance derivante dai miglioramenti strutturali dell'ISA e di altre cosette (valido però solo per le cpu AMD, per lo meno per il momento)

Ho capito quello che dice Criceto: se ho un power PC G5, anche se uso un SO a 32 bit, posso usare i registri a 64 bit per i calcoli matematici, perchè i 64 bit sono una caratteristica del processore. Questo è vero, ma il SO è comunque a 32 bit e vedi solo 4 GB di RAM. Così perdi il vantaggio maggiormente pubblicizzato dei 64 bit: oltre i 4 GB di RAM. I 64 bit sono una caratteristica del processore e non del SO. Con gli A64 puoi usare i calcoli a 64 bit SOLO SE USI UN SO a 64 BIT. Ma puoi usare anche più di 4GB alla volta... Questo è un merito del POWER PC E NON DI MAC OS X.

I processi a 64Bit vedono tutti i 64bit di indirizzamento, quindi tutti i Giga che riesci ad installare da qui ai prossimi 100 anni.

Il kernel, non so come funziona nei dettagli, pur essendo a 32 bit può lanciare contemporaneamente processi a 32bit con limite di 4GB di Ram per processo, e processi a 64 bit senza restrizioni di memoria (2^64 bytes).

Panther (il 10.3) poteva solo lanciare più processi (applicazioni) a 32 bit, quindi grandi fino a 4 GB ciascuno, mentre Tiger, come detto, permette anche di eseguire processi con API Posix a 64 bit. Senza limiti di Ram.

Si, ma tu stai parlando di un SO a 32 bit, ma "64 bit aware", nel senso che Tiger sfrutta alcune caratteristiche dei G5. Io parlavo di un SO VERAMENTE a 32 bit. Credo, ma non ne sono sicuro (qualcuno mi illumini), che una applicazione OS Classic (sia nativa che emulata su OS X), che è un SO, credo, a 32 bit, se si accorge di avere sotto un G5, può usare matematica e registri a 64 bit, che sono caratteristiche aggiuntive del G5 presenti sempre e non da abilitare, ma ovviamente non potrà mai usare più di 4 GB di RAM. Questo con un A64 te lo scordi: niente SO a 64 bit, niente RAM oltre i 4 GB (come è logico), ma anche NIENTE REGISTRI ED OPERAZIONI A 64 bit. Con il G5 mi pare di capire che le operazioni e i registri a 64 bit sono sempre accessibili.

Si, ma tu stai parlando di un SO a 32 bit, ma "64 bit aware", nel senso che Tiger sfrutta alcune caratteristiche dei G5. Io parlavo di un SO VERAMENTE a 32 bit.

Stavamo parlando di SO MISTI. O meglio, SO sotto ai quali possono essere sviluppate anche applicazioni a 64bit, volendo. E con dei limiti.

I 64 bit sono 2 cose: i registri (interi) a 64 e l'indirizzamento a 64 bit.
La prima è una feature in più del processore, come fosse Altivec. Certo se non ce l'hai Altivec un codice che lo richiede si incacchia. Però all'interno del codice (processo) puoi fare un test per vedere se c'è questa caratteristica e mandare in esecuzione una routine che lo supporta o meno. Per il resto non cambia niente.

L'indirizzamento a 64 bit invece è diverso, perchè gli indirizzi della memoria sono tutti grandi il doppio e non puoi dare in pasto un indirizzo a 64 bit ad una routine che se ne aspetta 32. Quindi tutto il programma (PROCESSO) deve essere a 64 bit.

Fx contiene a sostenere che Tiger è a 32 bit perchè il KERNEL è 32 bit. Ok, il kernel è a 32 bit. I drivers rimangono a 32 bit. Ma a te che ti importa? A loro 4GB di indirizzamento bastano.
Però il kernel può lanciare processi a 64bit dove i programmi possono indirizzare 64 di memoria. Come fà? Non lo, ma su Tiger lo può fare mentre su Panther (10.3) poteva solo lanciare più processi da 32bit, superando in questo modo il limite dei 4GB di memoria, ma con processi differenti.
E' merito di Apple o merito del PowerPC? Non so, ma credo sia più che altro merito del PowerPC perchè è stato progettato per questo passaggio (a 64 bit) fin dall'inizio. A quanto ho letto una cosa simile su x86 non può essere fatta perchè su quei processori la modalità a 32bit è subordinata a quella a 64bit e non possono coesistere contemporaneamente. Attendo evenutali smentite in merito.

Ora, questi processi a 64 bit, come detto, se iniziano ad indirizzare la memoria a 64 bit devono continuare a farlo per tutto il processo, quindi se devono chiamare una routine di sistema questa deve essere compilata a 64 bit.
Su Tiger solo le API Posix sono compilate (anche) a 64 bit. Quindi i programmi di derivazione UNIX possono girare a 64 bit. PIENI, senza limitazioni. Programmi a 64 bit.

E se un'applicazione vuole chiamare anche la routine (Cocoa o Carbon) che le permette di disegnare una finestra o un menu a tendina?
La soluzione apple è di creare due processi differenti: uno per il backend Posix a 64 bit e uno per il front end Cocoa o Carbon a 32 bit e farli comunicare tramite vari tipi di meccanismi.
E' macchinoso? Sicuramente.

Ma in pratica quando servono questi 64 bit di INDIRIZZAMENTO (come detto per gli interi a 64 non ci dovrebbero essere problemi)? Quando ti servono + di 4GB per un SINGOLO PROGRAMMA?

In pratica, OGGI, programmi che richiedo così tanta memoria sono programmi che lavorano su set enormi di dati, come programmi scientifici e database. Questi ultimi sono già spesso implementati come server, quindi con meccanismi di comunicazione indiretto con altri processi che possono essere a 32 bit e in genere sono applicazioni di derivazione Unix, non certo programmi di grafica e Office che sono quelle tipiche per Mac. Quindi alla fine per il mercato Apple questa è una soluzione più che accettabile.

Al momento, che io sappia, Mathematica è un programma con backend a 64bit su Tiger. Mentre ci sono state famose storie riguardo Cinema 4D i cui sviluppatori non hanno ritenuto fattibile l'implementazione a 64 bit su Tiger (ma io penso più che altro perchè le modifiche per farlo sarebbero state significative e non ne valeva la pena visto anche che il programma è multipiattaforma).

Fx contiene a sostenere che Tiger è a 32 bit perchè il KERNEL è 32 bit. Ok, il kernel è a 32 bit. I drivers rimangono a 32 bit. Ma a te che ti importa? A loro 4GB di indirizzamento bastano.
Però il kernel può lanciare processi a 64bit dove i programmi possono indirizzare 64 di memoria. Come fà? Non lo, ma su Tiger lo può fare mentre su Panther (10.3) poteva solo lanciare più processi da 32bit, superando in questo modo il limite dei 4GB di memoria, ma con processi differenti.

ahhhh... e io che ero rimasto che la richiesta di allocazione della ram da parte di un'applicazione fosse gestita dal kernel...

comunque il punto non è questo. un os a 32 bit con qualche workaround per permettere alle applicazioni di indirizzare la ram a 64 bit rimane comunque un os a 32 bit. quel che ti sto dicendo è che dei workaround simili sarebbero possibili anche su x86 (e potrebbe essere che mac os x li avrà, eh).

poi ci si potrebbe aggiungere che nè linux nè windows ne hanno mai avuto bisogno perchè:
- gli x86 a 32 bit sono in grado di allocare più di 4 gb di ram pur essendo a 32 bit
- sia linux (prima) che windows (più recentemente) esistono a 64 bit

C'è un po' di confusione: le CPU x86 hanno bus indirizzi a 36 bit (40 gli A64), in modo da indirizzare più di 4 GB. Ma un singolo processo può indirizzare solo 4GB alla volta (in versione a 32 bit). Con dei trucchi (bank swapping, come con il commodore 64!) si può avere più di 4 GB, ma non contemporaneamente. Addirittura per OS X e processi a 32 bit consigliano di usare i mapped files per sfruttare il caching di OS X Tiger (Che a quanto ho capito non soffre del limite dei 4 GB, posto che ci sia RAM sufficiente) e superare i limiti dei 4 GB, ma sempre mai più di 4 GB alla volta. Questi (bank swapping e memory mapped files) sono gli unici "workaround" che si possono utilizzare su processori x86: non si può usare un indirizzo a 64 bit in modalità compatibile in nessun modo.

comunque il punto non è questo. un os a 32 bit con qualche workaround per permettere alle applicazioni di indirizzare la ram a 64 bit rimane comunque un os a 32 bit. quel che ti sto dicendo è che dei workaround simili sarebbero possibili anche su x86 (e potrebbe essere che mac os x li avrà, eh).

Non è un workaround. E una feature dei PowerPC, che gli x86 non hanno.

Non vedo perchè Apple non possa espandere questa cosa anche alle API Carbon e Cocoa. Probabilmente non l'ha fatto perchè convertirle tutte è un lavorone (alcune sono di basso livello e sicuramente non è facile farlo) e tutto sommato per ora non era così urgente.
Ma se il sistema ti permette di utilizzare applicazioni a 64bit, tanto basta. Che il kernel sia a 32 bit è irrilevante...

ahhhh... e io che ero rimasto che la richiesta di allocazione della ram da parte di un'applicazione fosse gestita dal kernel...

comunque il punto non è questo. un os a 32 bit con qualche workaround per permettere alle applicazioni di indirizzare la ram a 64 bit rimane comunque un os a 32 bit. quel che ti sto dicendo è che dei workaround simili sarebbero possibili anche su x86 (e potrebbe essere che mac os x li avrà, eh).

poi ci si potrebbe aggiungere che nè linux nè windows ne hanno mai avuto bisogno perchè:
- gli x86 a 32 bit sono in grado di allocare più di 4 gb di ram pur essendo a 32 bit
- sia linux (prima) che windows (più recentemente) esistono a 64 bit

Anch'io ero rimasto al kernel che gestisce lo spazio di indirizzamento dell'applicazione. Se non hanno cambiato l'informatica negl'ultimi due anni, dovrebbe essere ancora cosi'.

Mi sa che qui ci troviamo di nuovo di fronte ad un oscuro caso tipi i driver che girano in user mode...

Interessante notazione, anche il kernel di WinNT ha delle estensioni alle API che permettono di allocare memoria fisica oltre ai 4GB per processi che ne hanno bisogno, tipo i server. Merito anche qui del PowerPC? Oppure avranno copiato anche questa volta? Oppure e' solo una soluzione logica ad un problema diffuso... :)

Mi sa che qui ci troviamo di nuovo di fronte ad un oscuro caso tipi i driver che girano in user mode...

Eppure di kernel ce n'è solo 1 ed è sostanzialmente a 32 bit (come i drivers). Come faccia a lanciare processi a 64 bit non lo so, ma lo fà :)

Dico, scherziamo vero? :mbe:
Il kernel (la parte che gestisce la memoria, per essere precisi) è l'unico che può assegnare memoria ai processi. E basta. Nessun altro. Lo sa anche uno studente dell'itis che studia so per sei mesi scarsi. Se accetta indirizzi maggiori di 32 bit, vuol dire che quella parte del kernel li supporta, in un modo o nell'altro, che sia compilata a 64 bit o no. La FORK (direttiva unix per creare processi, da quel pò di studi unix che ricordo) è compito esclusivo del kernel, anche perchè richiede accesso a risorse ultrachiuse fuori dal ring 0.

Qui dice che può fare questa cosa, ma non spiega in dettaglio come.
http://developer.apple.com/macosx/64bit.html

Dice che parte del sistema è implementata sia a 32 che 64 bit. Quindi la parte a 32 manda le app 32, la parte a 64 manda quelle a 64. In maniera simile a WoW64, porbabilmente.

Non è un workaround. E una feature dei PowerPC, che gli x86 non hanno.

senti, mi porti un po' di doc? se continui ad andare a spanne con mac os x che fa girare i 64 bit che nemmeno io so come non ci intenderemo mai

per quanto riguarda win 95, stavolta confermo, è in modalità non protetta, più precisamente in modalità flat (ovvero con puntatori a 32 bit sulla ram), per questo motivo se un'applicazione crashava in malo modo si trascinava con sè tutto l'os
Ne abbiamo già parlato altre volte in passato: non è così. ;)

Sinteticamente: Windows95 lavora in modalità protetta, ma per questioni di compatibilità con DOS e Windows 3.x alcune aree di memoria "critiche" sono condivise (es: la tabella degli interrupt), come pure la gestione degli interrupt interrupt e le porte di I/O. Tutte cose estremamente delicate, per cui effettivamente poteva succedere che il s.o. andava in crash se venivano toccati "in malo modo".

Che la memoria sia protetta lo dimostra il semplice fatto che le applicazioni che vanno in crash "normalmente" (es: accedono a un'area di memoria non loro, che chiaramente non farte di quelle condivise / delicate) vengono tolte di mezzo e basta, senza che accada nulla a tutto il resto.

Se la memoria non fosse protetta, non ci potrebbe essere un controllo di questo tipo (ho scritto o letto su un'area di memoria non mia? E chi se ne frega: intanto continuo lo stesso a girare, tanto non se n'è accorto nessuno... :D) né tanto meno la memoria virtuale... ;)

Ho capito quello che dice Criceto: se ho un power PC G5, anche se uso un SO a 32 bit, posso usare i registri a 64 bit per i calcoli matematici, perchè i 64 bit sono una caratteristica del processore. Questo è vero, ma il SO è comunque a 32 bit e vedi solo 4 GB di RAM.
Esatto, ma non solo: se il s.o. non ha uno scheduler che supporta i processi a 64 bit, succede che magari usi i registri a 64 bit, poi c'è un context switch che salva soltanto la parte a 32 bit, e al prossimo context switch ti ritrovi tutti i 32 bit alti azzerati oppure che contengono dati di un altro processo che nel frattempo ha fatto uso dei 64 bit... :asd:

al di là che l'impatto sulle performance derivanti dalle operazioni a 64 bit è marginale e interessa solo ristretti ambiti d'impiego, non ci giurerei che non sia possibile... col dos a 16 bit io usavo i registri a 32, non escludo che fino ad usare i registri a 64 bit con un os a 32 si possa anche fare
Vedi sopra: non credo. :p

Col DOS era diverso perché era un s.o. "batch", per cui anche se usavi i 16 bit alti dei registri a 32 bit, non correvi il rischio che qualcuno te li cancellasse...

I registri a 64 bit non si possono usare in real mode, come avveniva coi 386, perché funzionano esclusivamente in Long Mode: quindi in un "ambiente" in cui la paginazione della memoria è abilitata, molte istruzioni legacy sono state rimosse, per gli indirizzi si usano registri a 64 bit, ecc.

Il kernel, non so come funziona nei dettagli, pur essendo a 32 bit può lanciare contemporaneamente processi a 32bit con limite di 4GB di Ram per processo, e processi a 64 bit senza restrizioni di memoria (2^64 bytes).

Panther (il 10.3) poteva solo lanciare più processi (applicazioni) a 32 bit, quindi grandi fino a 4 GB ciascuno, mentre Tiger, come detto, permette anche di eseguire processi con API Posix a 64 bit. Senza limiti di Ram.
Per Panther e Tiger il limite è sempre di 4GB di memoria in totale per il s.o., i driver e le applicazioni, non di 4GB per applicazione. La memoria oltre i 4GB viene utilizzata soltanto come cache.

http://developer.apple.com/macosx/tigerdevintro.html

"As you probably know, at the heart of the Power Mac G5 and the new iMac G5 is the PowerPC G5 processor, a fully capable 64-bit processor. It sports 64-bit registers, can perform 64-bit arithmetic operations, and can give the operating system access to greater than 4GB of main memory."

http://developer.apple.com/macosx/64bit.html

"Previous versions of Mac OS X have been able to take advantage of more than 4GB of system memory when running on a G5-equipped Mac, but each application was still subject to the 4GB limit imposed by a 32-bit address space."

http://developer.apple.com/business/macmarket/mathematica.html

"Before Tiger, the 32-bit limitation meant that 4GB of memory was the practical limit."

http://developer.apple.com/documentation/Carbon/Conceptual/carbon_porting_guide/cpg_intro_struct/chapter_1_section_1.html

"Each application can access up to 4GB of potential addressable memory"

Non è un workaround. E una feature dei PowerPC, che gli x86 non hanno.
Non è un workaround: se il kernel non imposta l'apposita tabella delle pagine per mappare gli indirizzi a 64 bit, non c'è verso di indirizzare la memoria oltre i 4GB.

In soldoni: non puoi infilare in un registro un indirizzo a 64 bit >4GB e pensare di effettuare una Load o Store con esso senza che il kernel ne abbia mappato l'indirizzo... Ma non esiste proprio: come minimo di spara un fault.

Ne abbiamo già parlato altre volte in passato: non è così. ;)

non con me =)

Sinteticamente: Windows95 lavora in modalità protetta, ma per questioni di compatibilità con DOS e Windows 3.x alcune aree di memoria "critiche" sono condivise (es: la tabella degli interrupt), come pure la gestione degli interrupt interrupt e le porte di I/O. Tutte cose estremamente delicate, per cui effettivamente poteva succedere che il s.o. andava in crash se venivano toccati "in malo modo".

Che la memoria sia protetta lo dimostra il semplice fatto che le applicazioni che vanno in crash "normalmente" (es: accedono a un'area di memoria non loro, che chiaramente non farte di quelle condivise / delicate) vengono tolte di mezzo e basta, senza che accada nulla a tutto il resto.

Se la memoria non fosse protetta, non ci potrebbe essere un controllo di questo tipo (ho scritto o letto su un'area di memoria non mia? E chi se ne frega: intanto continuo lo stesso a girare, tanto non se n'è accorto nessuno... :D) né tanto meno la memoria virtuale... ;)

si ma infatti capitava:

che l'applicazione scrivesse a cavolo dentro la sua area di memoria, e s'inchiodava solo lei
che l'applicazione scrivesse a cavolo altrove, e il risultato diventava randomico: continuava a funzionare tutto, continuava a funzionare lei e il sistema diventava instabile, si pallava tutto

tra l'altro ci sono due prove di quanto sto dicendo:
a) quando programmavo in assembler usavo regolarmente gli extender del dos, i quali per l'appunto portavano il processore in modalità protetta. in dos funzionavano, sui windows 9x pure, sugli nt e 200x / xp ovviamente no, perchè la modalità in cui era il processore era rispettivamente real 16, flat 32 e protected 32
b) prova a fare un programmino in win32 che scrive sulla ram a cavolo... sui win 9x si palla tutto, sugli nt si chiude il processo

può essere che per definizione la modalità impiegata da win 95 fosse sempre il "protected mode", ma nell'uso comune la si definiva "flat mode", ovvero una modalità in cui avevi accesso alla memoria con puntatori da 32 bit, senza che però questa fosse protetta.

poi mi posso sbagliare eh, però ricordo così...

I registri a 64 bit non si possono usare in real mode, come avveniva coi 386, perché funzionano esclusivamente in Long Mode: quindi in un "ambiente" in cui la paginazione della memoria è abilitata, molte istruzioni legacy sono state rimosse, per gli indirizzi si usano registri a 64 bit, ecc.

in compatibility mode (64 bit) puoi lavorare anche con i registri a 16... infatti in questa modalità non sfrutti le feature nuove dei 64 bit

http://img206.imageshack.us/img206/222/suck6aq.jpg

non con me =)
Lo so, infatti parlavo in generale... :p
si ma infatti capitava:

che l'applicazione scrivesse a cavolo dentro la sua area di memoria, e s'inchiodava solo lei
che l'applicazione scrivesse a cavolo altrove, e il risultato diventava randomico: continuava a funzionare tutto, continuava a funzionare lei e il sistema diventava instabile, si pallava tutto
Attenzione: non è che scrivesse "a cavolo", perché se lo faceva in aree di memorie non sue, il sistema la bloccava, esattamente come avviene adesso.

I problemi si verificavano soltanto se scriveva nell'area di memoria "critica" condivisa (quindi mappata anche nella sua tabella delle pagine).
Per farti un esempio: è come se, a causa di un bug :D, l'area di memoria della tabella degli interrupt di Windows XP venisse mappata in ogni applicazione. Puoi immaginare cosa succederebbe nel caso in cui, per sbaglio o per improvvisa pazzia, una di esse andasse a scriverci sopra qualcosa: KABOOM! :p
tra l'altro ci sono due prove di quanto sto dicendo:
a) quando programmavo in assembler usavo regolarmente gli extender del dos, i quali per l'appunto portavano il processore in modalità protetta. in dos funzionavano, sui windows 9x pure, sugli nt e 200x / xp ovviamente no, perchè la modalità in cui era il processore era rispettivamente real 16, flat 32 e protected 32
A parte il DOS che era libero, su Windows 9x funzionavano perché si accorgevano che c'era Windows sotto, e anziché installare i loro servizi DPMI usavano quelli di Windows (che implementa e rende disponibili i servizi DPMI).

Su NT & co non funzionavano nel momento in cui provavano ad accedere alle porte di I/O oppure a usare le istruzioni privilegiate.
b) prova a fare un programmino in win32 che scrive sulla ram a cavolo... sui win 9x si palla tutto, sugli nt si chiude il processo
Vedi sopra. ;)
può essere che per definizione la modalità impiegata da win 95 fosse sempre il "protected mode", ma nell'uso comune la si definiva "flat mode", ovvero una modalità in cui avevi accesso alla memoria con puntatori da 32 bit, senza che però questa fosse protetta.
Per flat mode s'intendeva la possibilità di usare registri a 32 bit, quindi con valori > 65535 come offset, ma normalmente non era possibile. Infatti se provavi questo:

mov eax,65536
mov eax,[eax]

sotto DOS, ricevevi un segmentation fault. Questo perché il limite di tutti i descrittori era impostato comunque a $FFFF (infatti con i 386 c'erano dei problemi di compatibilità con qualche vecchio codice 8086).

C'era il modo di togliere di mezzo questo limite e usare qualunque offset (quindi accedendo a tutta la memoria, anche sopra il megabyte "standard"), ed è stato chiamato Flat Real Mode: si entrava in modo protetto, e si usciva subito, "dimendicandosi" :D di impostare il limite dei descrittori a $FFFF, come affermava Intel nei suoi manuali... :asd:
poi mi posso sbagliare eh, però ricordo così...
La memoria era protetta, fidati. :D
in compatibility mode (64 bit) puoi lavorare anche con i registri a 16... infatti in questa modalità non sfrutti le feature nuove dei 64 bit
Esattamente.

La memoria era protetta, fidati. :D

si, peccato per la tabella degli interrupt, probabilmente se non fosse stata scoperta un'area di memoria "piuttosto" importante come questa avremmo avuto un windows molto più stabile... poi ovviamente capisco anche che sarebbe stato necessario probabilmente un intervento strutturale per farlo

Scusate l'OT:

avete letto l'ultima prova di AnandTech? Il G5 a 2,7 si pone come rivale del miglior x86 in circolazione e a livelli anche superiori di un P4 a 3+ Ghz. A patto di installare Linux (Yellowdog).

Questo per tutti quelli che hanno preso per il c..o il G5 con "va piano"... "non e' all'altezza" ecc...

Rimangiatevi tutto.

;)

Scusate l'OT:

avete letto l'ultima prova di AnandTech?
Sì, e non dice nulla di nuovo.
Il G5 a 2,7 si pone come rivale del miglior x86 in circolazione e a livelli anche superiori di un P4 a 3+ Ghz.
Il miglior x86 in circolazione non è certo un P4 a 3Ghz.
A patto di installare Linux (Yellowdog).
Indubbiamente: è evidente, e quest'articolo non fa che dimostrarlo ulteriormente, che OS X non è un s.o. nato per brillare nel campo delle prestazioni.
Questo per tutti quelli che hanno preso per il c..o il G5 con "va piano"... "non e' all'altezza" ecc...
Non so cos'abbia letto tu, ma certamente hai preso una gran cantonata:

http://images.anandtech.com/reviews/mac/mysteries2/MySQL_performance2.gif

Questa era l'unica immagine disponibile e mi spiace, perché mi sarebbe piaciuto riportare i risultati di tutti gli altri test...

"While the G5 is not the best integer processing unit out there, it is not the one to blame for the poor performance that we experienced in our first tests. Running Yellow Dog Linux, the Dual G5 was capable of performing similar to a 3 GHz Xeon."

"Combined with the data from our first article, we can safely say that the G5 2.7 GHz FP performance is at least as good as the best x86 CPUs. Integer performance seems to be between 70% and 80% of the fastest x86 CPUs, while FP/SIMD performance can actually surpass x86 in certain situations."
Rimangiatevi tutto.
Direi proprio di no. Anzi, secondo me faresti bene ad ascoltare Jobs una volta tanto che ha detto una cosa vera... ;)

>Il miglior x86 in circolazione non è certo un P4 a 3Ghz.

Infatti. Opteron.

In campo workstation (non server; e poi hanno provato solo mySQL; manca all'appello Oracle e FIlemaker entrambe su piattoforma x86 anche) OS X lascia dietro le varie versioni di Windows, come prestazioni ed usabilita': non da test specifici ma da utente che per 8h al gorno usa win e a casa OS X.

>between 70% and 80% of the fastest x86 CPUs, while FP/SIMD performance can actually surpass x86 in certain situations.

Opteron. Surpass: Intel.

Vedremo il 970MP dual core, con 1MB di cache per core (che dovrebbe aiutare sulle basse prestazioni integer) e le migliorie introdotte. Spero lo utilizzino prima di passare agli x86 e che non faccia la fine del 68060 :(
Sicuramente sara' una macchina che faro' di tutto per portarmela a casa.

Infatti. Opteron.
Infatti non riesce a competere, perché è polverizzato da questo processore (tra l'altro a 2,4Ghz e memorie DDR ECC registered): SOLTANTO nel test "sh" il G5 (a 2,5Ghz e con DDR 400 non registered) è riuscito a superarlo, e di poco.
In campo workstation (non server; e poi hanno provato solo mySQL; manca all'appello Oracle e FIlemaker entrambe su piattoforma x86 anche)
Hanno usato Apache e MySQL perché sono i server web e SQL più diffusi, usati e performanti.
I test con Oracle, ma anche con altre applicazioni, sono sempre i benvenuti.
Quelli con FileMaker lasciano il tempo che trovano: è diffuso soltanto in ambito Mac.
OS X lascia dietro le varie versioni di Windows, come prestazioni ed usabilita': non da test specifici ma da utente che per 8h al gorno usa win e a casa OS X.
Le tue impressioni non dimostrano niente: Windows come prestazioni sta sotto Linux con quelle applicazioni, ma mai come OS X, che ha problemi architetturali. Questo da test effettuati, che sono quelli che contano veramente.

Quanto all'usabilità hai ragione, ma questo è un altro discorso e con le performance non c'entra niente.
>between 70% and 80% of the fastest x86 CPUs, while FP/SIMD performance can actually surpass x86 in certain situations.

Opteron. Surpass: Intel.
Dove, scusa?

Il dual Xeon a 3,6Ghz è nettamente migliore del Dual G5 a 2,5Ghz in MySQL e Apache.
In Lmbench 3.0 è migliore in fork e exec, ma è peggiore in sh.
Nel signaling è migliore in null call, open I/O, stat, slct clos, sig TCP, ma è peggiore in null e sig inst.
Nell'IPC è migliore in pipe, UDP e TCP, ma è peggiore in AF Unix e TCP conn.

Quindi anche per Intel lo scenario è simile. Non è certo come per AMD, che spazza via il G5 praticamente in tutto, ma presenta prestazioni mediamente superiori al G5. Nelle applicazioni testate, in particolare, è NETTAMENTE superiore.

Questa superiorità del G5 la vedi soltanto tu.

Ti ripeto il consiglio: ascolta Jobs, una volta tanto che ha detto una cosa vera. Non c'è storia: x86 è il leader indiscusso.

Vedremo il 970MP dual core, con 1MB di cache per core (che dovrebbe aiutare sulle basse prestazioni integer)
Dipende dal contesto. Su K7/K8 col passaggio da 512KB a 1MB mediamente migliorano del 5-10%.

Comunque hanno messo 1MB più che altro perché in un sistema dual core la contesa per l'accesso alla memoria è ancora più pesante, e in questo modo risulta "mitigata"
e le migliorie introdotte.
Per consumare di meno. Per il resto dovrebbe essere identico al PPC970.
Spero lo utilizzino prima di passare agli x86 e che non faccia la fine del 68060
Mi sa di sì, invece: il 2006 è alle porte ormai...
Sicuramente sara' una macchina che faro' di tutto per portarmela a casa.
Che te ne fai? Hai già dei Mac mi pare e il futuro è segnato: se fossi un utente Apple non comprerei mai un Mac adesso, se non ne avessi realmente bisogno.

samslaves: posso chiarirti le idee? :D

dall'articolo di anand si evince che:
a) mac os x al di là della (obiettiva) sensazione di fluidità e di responsività che dà nei numeri dimostra di avere delle performance drammatiche in certe situazioni (laddove c'è un po' di multitask), a causa di un kernel che integra concetti di "modernità" di qualche lustro fa... se Next e Mach (sui quali si sono fatti mille mila sbrodolate dove però non i numeri ma le parole e le sensazioni la facevano da padrona) li si lasciava dov'erano e si teneva un kernel freeBSD puro a quest'ora i valori erano allineati con un kernel 2.6 di linux
b) il g5 a parità di os (che è l'unico test possibile per valutare le potenzialità di una macchina) o per lo meno di kernel performa comunque abbondantemente sotto - in apache + mysal - all'opteron a 2.4, che ha pure 100 mhz in meno rispetto al g5 2.5 preso in considerazione: se guardi il grafico il tetto dell'opteron è poco meno di 700 mentre il tetto del g5 è a poco più di 400... sarebbe anche assurdo pensare il contrario, a fronte degli investimenti che stanno dietro agli x86 e quelli che invece stanno dietro al g5
c) il fatto che in alcuni specifici casi la FPU + Altivec ottenga dei risultati brillanti, beh, sono il primo a dire che essendo delle architetture diverse ognuno avrà un ambito in cui eccelle, però mi sembra veramente un ambito un pochettino ristretto per poter gasarsi :D
d) il ppc970mp non cambierà di certo la situazione. realizzare una cpu dual core alla buona (come il pentium d, per intenderci) è piuttosto facile: basta mettere due core predisposti all'impiego in ambito multiprocessore dentro un solo package e hai lì il tuo bel "dual core" (fuffa, ma ce l'hai). ovviamente il dual core vero è diverso e parte da più lontano, come nel caso degli AMD64 che già dalla nascita sono stati strutturati pensando al dual core, cosa che lasciami dubitare vi sia nel ppc970. comunque dicevo non cambierà la situazione semplicemente perchè i dual core x86 a me risulta che siano già sul mercato da tempo, e vedendo com'è strutturato un opteron dual core la cosa che mi viene da pensare è che la differenza in termini prestazionali vada ad aumentare in un ipotetico scontro tra due g5 dual core e due opteron dual core...
e) in sintesi: prendi tiger x86 e mettilo su un pc, poi dimmi se rimpiangi il g5 :D

dall'articolo di anand si evince che:
a) mac os x al di là della (obiettiva) sensazione di fluidità e di responsività che dà nei numeri dimostra di avere delle performance drammatiche in certe situazioni (laddove c'è un po' di multitask), a causa di un kernel che integra concetti di "modernità" di qualche lustro fa... se Next e Mach (sui quali si sono fatti mille mila sbrodolate dove però non i numeri ma le parole e le sensazioni la facevano da padrona) li si lasciava dov'erano e si teneva un kernel freeBSD puro a quest'ora i valori erano allineati con un kernel 2.6 di linux
b) il g5 a parità di os (che è l'unico test possibile per valutare le potenzialità di una macchina) o per lo meno di kernel performa comunque abbondantemente sotto - in apache + mysal - all'opteron a 2.4, che ha pure 100 mhz in meno rispetto al g5 2.5 preso in considerazione: se guardi il grafico il tetto dell'opteron è poco meno di 700 mentre il tetto del g5 è a poco più di 400... sarebbe anche assurdo pensare il contrario, a fronte degli investimenti che stanno dietro agli x86 e quelli che invece stanno dietro al g5
c) il fatto che in alcuni specifici casi la FPU + Altivec ottenga dei risultati brillanti, beh, sono il primo a dire che essendo delle architetture diverse ognuno avrà un ambito in cui eccelle, però mi sembra veramente un ambito un pochettino ristretto per poter gasarsi :D
d) il ppc970mp non cambierà di certo la situazione. realizzare una cpu dual core alla buona (come il pentium d, per intenderci) è piuttosto facile: basta mettere due core predisposti all'impiego in ambito multiprocessore dentro un solo package e hai lì il tuo bel "dual core" (fuffa, ma ce l'hai). ovviamente il dual core vero è diverso e parte da più lontano, come nel caso degli AMD64 che già dalla nascita sono stati strutturati pensando al dual core, cosa che lasciami dubitare vi sia nel ppc970. comunque dicevo non cambierà la situazione semplicemente perchè i dual core x86 a me risulta che siano già sul mercato da tempo, e vedendo com'è strutturato un opteron dual core la cosa che mi viene da pensare è che la differenza in termini prestazionali vada ad aumentare in un ipotetico scontro tra due g5 dual core e due opteron dual core...
e) in sintesi: prendi tiger x86 e mettilo su un pc, poi dimmi se rimpiangi il g5 :D


This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:27:24 UTC
I think that this article is full of mistakes that are done by purpose (i dont know, maybe!!) or are due to the misunderstanding of those guys about many computing ideas and principles. I really think that such articles that claim to be informative should not be allowed to be on internet as it is simply saying wrong things.

My big concern about their tests is that they are not fair and they never tend yo be fair to the apple side and osx. For example i believe that everyone who pretend to make precise testing should realize that if they got results that differ so much and are so unexplained, well the best thing is to try different testing methods and tools. So tools may work well for a given platform, others may not work well. So any tempt to highlight any os design flaw should be done after testing many different benchmarking tools. They don't do that, instead they try to find some reasons that are completely meaningless in the sense that they are saying things that are technically wrong. Trying to find such whatever threading problems in osx in order to hurt the platform is not really fair......

So to begin with, let me comment on the Apache results. Well they use Apachebench to test osx, and they get rather low request per second with osx. Well ok, but why don't they try something else to test Apache performance, in that case they could figure out that the problem is either the os or the benchmarking tool (they recognize themself that apple did tell them that thre is a bug in ApacheServer, while running it on osx, maybe? i did not test it).

Try to run WebBench on osx and linux ppc or x86, and have a look to the results. Well WebBench is a largely accepted benchmarking tool for test Apache performance, so it make sense to use it too. pcmag.com have tested a Xserve G5,

http://www.pcmag.com/article2/0,1895,1630329,00.asp,

and their result show something like almost 8000 request per second for 60 clients for a static configuration test.

Ohhhh!!!! What's going on here? What we have here is something completely different, a completely different image compared to their results. What does this tell us? Well two different bench tools can produce very different outputs. But moreover everything that follows in their article simply collapse because nothing tell us that the tools that they use for MySQL testing are not having a problem too. Moreover WebBench involve as weel many threads creation, so their theory about this threading problem of osx collpase too.

We simply dont get any global image of osx performance in server applications with their limited set of bench tools. Did they never think that the problem of those results could come from the benchmarking tools or the app itself that may have performance problems while running on osx.

Here is the comment of pcmag.com

"Performance-wise, the dual-processor Xserve G5 compares well with Linux-based x86 servers. This is not surprising, considering that Mac OS 10.x is based on FreeBSD UNIX. Using the included Apache server, we ran the Xserve G5 through our standard WebBench tests. It did quite well on the static WebBench test, outperforming a competitor's dual processor x86-64 server running Apache server on SuSe Linux-64."

Something rather different to their general statement, isn't it?

So now about MySQL. So first they mention fsync(). Let me correct. What are they talking about is wrong?, fsync() behaves the same as it does on all unixes: it writes the data from the host to the drive. However this is not good enough because drives will buffer the data and potentially write it in a different order than the app did.
To deal with this, MacOS X provides an fcntl() called F_FULLFSYNC which does what fsync does and in addition asks the drive to flush all buffered data to disk. This is the only way for an app to be able to make any guarantees about things like transactions which is why InnoDB in MySQL uses it! And i think that because its an os feature it works whenever you use MyISAM or not.

And i don't understand why their benchmark should lower the pressure on the disk. A database app like MySQl has to write and read data on disk while running, so what they are saying is simply wrong.

to be continued....
1 Reply Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:30:32 UTC
Lets now talk about their insane theory about threading in osx. Here is their statement

"Readers pointed out that there were two errors in this sentence. The first one is that Mac OS X does use kernelthreads, and this is completely true. My confusion came from the fact that FreeBSD 4.x and older – which was part of the OS X kernel until Tiger came along - did not implement kernelthreads; rather, only userthreads. It was one of the reasons why MySQL ran badly on FreeBSD 4.x and older. In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. "

What does it mean this? What does it mean that os x prior to Tiger did not implement kernel threads, my God! what are they saying, they should just go and take some os design course.

Kernel threads are of course in previous version of osx and in Freebsd. Mach itself implements a multithreaded VM layer for example, and anyway i mean, every thread that access the kernel runs in the kernel. An app that makes files IO or network task has one of its threads dealing with that which enter in the kernel space and runs in the kernel until it resumes. So i dont really understand what does it mean to say that and what is their aim to say that osx did not have kernel threads. I think they seem to confuse kernel thread and fine grained locking.

When a thread enters the kernel, it shares the same memory space as the entire kernel itself as well as any other interrupts which run in the bottom half of the kernel (kenel thread are said to run on the top half). So os designers had to implement many technics (i don't really enter in the details here) to protect the data being manipulated by the kernel. One of them and still partially used by FreeBSD was a giant lock which protects the kernel of any threads which wish to enter inside its memeory space. Actually Giant Lock was implemented to protect the kernel space particularly in case of multiprocessor machines where the principle of not preemptable kernel was not enough anymore to protect the kernel in such hardware. OS X before Tiger used something similar to the Giant Lock although not identical. Os x implements funnels that serialize the access to the Bsd portion of the kernel.

Funnels are built on top of Mach mutexes, and are used simply because Mach is thread safe, the bsd protion was not, they needed something to serialize both of them. Funnels are sleeps locks, and each funnel backs to into a mutex, and one a thread gains a funnel is is holding that funnel while is executing. The difference between a funnel and a mutex is that a mutex is hold across rescheduling.

There were a funnel for the file system and one for everything else, mainly the network code. In Tiger the funnels are gone and the BSD portion of the kernel implements now fine grained locking in order that SEVERAL threads can exist in the kernel at the same time. So they confuse both ideas, of course kernel threads did exist prior to Tiger otherwise the system can not do any file system or network operation. What Tiger does is that it allow better scaling for multiple processors architecture for threads that run in the kernel space (this scaling requirement did not concern threads that runs in the user space) with fine grained locking. Right now the the network stack and the file system in the BDS portion in Tiger are thread safe.

"In the case of userthreads, it is not the kernel that manages the threads, but an application running on top of the kernel in userspace. "

That's not true, many os today offers a 1:1 mapping for executing the threads whatever they are. So any threads including user or kernel thread are managed by the kernel. What a hell is this app running on top of the kernel in the user space? Thats simply dont make sense.....

Now lets come to their process and thread theory.

"However, it is important to understand that threads and processes are not completely different, but they are related to each other. In the case of Linux, creating a thread is very similar to creating a process. In fact, you use the same procedure, only with different flags or parameters. Linux implements all threads as if they were standard processes. You create a new thread with the clone() call, and the necessary flags, which describe the resources (memory) to be shared. The process creation is done with fork(). But fork() is nothing else than a clone() without the flags that describe the resources that must be shared. So, if you test fork() on Linux, you also get a rough idea of how fast threads are created.

What about Mac OS X? Well, when the Mach kernel is asked to create a Unix process (fork()), the mach kernel creates a task (which describes the resources available) and one thread. So, thread creation time is included in the fork () benchmark of Lmbench. "

That's not true at all. An os calls fork() for creating process (or Task), right! An application is also a process, actually it is a the child of a parent process which is launched when logging in.

A thread, right! ,shares the same address space as the process that launch it and share the same address space as the another threads launched by the same application. But what Lmbench measures is process creation not thread creation.

Thats not the same thing ,creating a process and a thread are two different things. The first one is created by the os, the second is created by an application with a system call, and why are they talking about clone() to create threads, that does not happen like this in osx. Yes Mach creates a process if it is asked to do so, and one thread belonging to this process. But after that any new threads is created by the app, not by the os. When MySQL runs, it creates threads, right, but the latency or performance hit that they are talking about can not be measured by Lmbench as MySQL creates threads and this tools measures process creation.

to be continued....
0 Replies Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:31:38 UTC
How can they measure anything about any thread problem in osx running this tool that does not tell anything about what they are talking about. They try to explain an obscur relation between thread and process, but they completely miss the point.....they just dont understand how it works....

Threads are not sequential flow control within a program (what does it it anyway to say that!!!!), they are lightweight peace of code that are time-sliced by the kernel. Advice too them: Take a book about threads, and read it.....

"And although MySQL is only one process, it must cooperate with other process via IPC. "

Which over process is this. Any other process means an application or any other os proccess. Which one are they talking about? why to measure IPC in case of MySQL? Generally, their test about IPC and signaling are completely meaningless, because i really dont understand what they try to measure and besides that fact that they try to confirm a theory about threads in osx that comes mainly from their imagination and misunderstood.

"
relatively high TCP Latency that we measured
the implementation of the threading system. Does the pthread to Mach threads mapping involve some overhead? Or is this the result of the traditional performance problem of the micro kernel, namely the high latency of such a kernel on system calls? While Mac Os X is not a micro-kernel, the problem might still exist as the Mach core is deep inside that kernel. Is there IPC overhead? Lmbench signaling benchmarks seem to suggest that there is.
the finer grained locking in the current version of Tiger that is not working for some reason and we still have the “two lock” system of Panther.
"

Everything that comes from theitr Lmbench seems not to give trustable results about performance on ox. A given benchmarking tool can give you very untrustable results, see the apache test too.

God damm!!!! there is no thread mapping overhead why should there be? Osx use a 1;1 model for every thread, user or kernel space maps directly to Mach without any overhead. Or do they try to find any reasons even it does not make sense..... There is not high latency on system calls in osx, they just try to convince themself about it to support their ridiculous theory that simply comes from bad testing. Darwin is not a micro-kernel, xnu is monolithic. BSD does not run as a servie on top of Mach as i could also read in this forum.

And PLEASE dont say that i am wrong or that you know better than me. I am a damm Darwin coder......

Since macos x was not intended to work as a multi-server. and a crash of the BSD server was equivalent to a system crash from a user perspective, the advantage of protecting Mach from BSD were negligible. Rather than simple collocation, message passing was short circuited by having BSD DIRECTLY call Mach functions. The abstractions are maintained within the kernel at the source level, but the kernel is in fact monolithic. Saying that the problem might still exist as the Mach core is deep inside the kernel is simply meaningless, what does mean this? Again they just try to find stupid argument that have no technical meaning and proof. Their Lmbench simply seems to give bad results on osx, or whatever reasons, but right now nothing can alllow them to say such things with a single test.

Moreover some people seems to confuse where threads are handled in osx. Threads has to run, right? They have to get ressource to run (cpu ressource), so they are time-sliced by the kenel. Some people seem to think that it is the bsd portion of xnu that manages threads, not at all. Everything comes to the Mach portion of xnu where the threading management code is. Any call to a Cocoa, or a Carbon multhreading API, or any call to the Posix threads API which belongs to the BSD code mapps directly to Mach. Osx offers diffrent way for the programmer to create a thread, and to deal with them, but at the end everything is managed by Mach.

The fine grained locking is working in Tiger. The test that they did do not show anything about whether its working or not. Nothing can allow them again to say such stupid things. The funnels in Tiger are gone, believe it or not thats not my problem, but please i cant support that they try to make believe people about such wrong statement.

You may say me now that i just talk about the bads point of the bench that they did, and i just forget the rather good results done by the G5 with flops test. Well the same comment can be done, they are unfair because you take a very old floating point performance bench tool that is more suitable for x86 chips than for G5. Look at the code of flops, there is a lot of to do in the code to optimize it like unrolling the loops for better parallelism. You may say that the code is not optimized for x86 either, yes but it runs better on those chips as it is now than on G5. And why a hell they use such poor testing for floating point performance, why not using Linpack much more suitable for such task. So their conclusion about floating point performance on G5 compared to x86 is simply not true. Any reasonnable testing of floating point performance can not be done with a such limited tool like flops, its ridiculous.... Each G5 is capable of a fused, multiple-add operation per cycle, so you get 2 flops per cycle. This means that 2GHz corresponds to 8 GFlops, so each dual 2.0 GHZ G5 can deliver a peak of 16 GFlops of double-precision performance. An Opteron gives you 4 GFlops at 2.0 ghz. This does not correspond very well to their "as good as x86" statement, does it?

Well, well a lot of things isn't? I mean their text is so full of mistakes of any kinds mainly due to their poor understanding about os design and computer principles in general, and they come up with such interpretations that are so wrong.....

to be continued.....
0 Replies Reply Score: 0

This article is wrong all along!!!
By Anonymous (IP: 133.87.1.---) on 2005-09-03 06:32:12 UTC
And why dont they use Xserves for servers benchmarking. I mean, just forget about the osx/linux comparison and focus on the hardware comparison in server applications. The powermac is a not a server and it not designed as a server. that means that it is not designed to run server applications effectively. A power mac has an ethernet controler, which is directly connected to the I/O controler K2. This K2 controler manages every other I/O operations (except the PCI-X slots) like disk out and input, etc.... What does it mean is that the networking flow of data has to share the bus with I/O disk data with is a major and very important bottleneck in aplications like data base as they perform a lot of network and disk operations.

Network operation has then to share a 1.6 GBps bus from the K2 to the PCI-X bridge with everything else. And yet data has to go until the northbridge before to be put in memory or to be computed the cpu. Well this design is good for any desktop worstation, because this kind of machine don't deal with server network performance bounded applications. Now look at the Xserve. The Xserve has first a dedicated Ethernet ASIC controller, the powermac not. This ASIC provides many network tasks optmizations, like hardware-generated TCP, IP, and UDP checksum to detect packet corruption and transmission errors, 802.1q VLAN (Virtual LAN) tags let you group systems on different physical LANs and provide discrete services to them — as if they were on separate, physical LANs and a 64KB buffer supports jumbo frames, or packets up to 9KB, to reduce system overhead and increase throughput of all network activities.

Quiet a lot of things, isn't? Moreover the advanced ASIC includes two independent 10/100/1000BASE-T Ethernet interfaces, each with its own interrupt, on a dedicated 64-bit, 133MHz PCI-X bus. The Ethernet controler is linked directly to the PCI-X bridge which communicates at 4.8 GBps to the controler system. This makes a huge diffrence in networking performance, because the ethernet interface can communicate very quickly with the rest of the system in order that data can be processed much faster than a powermac. Thats a server design. Apple dont sell the Xserve just for fun.... And the amazing thing is that they talk about "The Xserve Server Platform", but they dont test the Xserve at all, something is wrong here!!!! Now i guess that they were saying in their first article that it was more fair to use a powermac than a Xserve for comparison with x86 boxes because the powermac shipped with a G5 that have higher frequencies. They totally missed the point, the performance of a server platform depends fisrt on how it is optimized to handle network communication.

I am sure that they wont, but i asked them to remove this article because it has so many mistakes, misunderstandings, etc, .... that any reader will misunderstand their statement, and Os X. Thats really insane and maybe dangerous to publish such articles which their content relies on people that do not understand everything about what they are writing.

Its really funny to see some small boys with still some acne on their face who think that they can teach you computers and computing, how it works and so on.....because they got a bunch of computers in a classroom.
This is just crap........

Have a nice day......

Hakime.

1) Apachebench è un benchmark integrato nel pacchetto Apache. WebBench è un benchmark sintetico sviluppato da PCMagazine.
Fra i due io preferisco il primo, visto che il più diffuso ed è supportato dalla casa madre.

Se Apachebench mostra quei risultati, è inutile recriminare o cercare scuse: con QUESTO strumento la situazione è questa e dev'essere accettata.

2) La suite di test usata da AnandTech per MySQL è ben nota, ha sempre funzionato su qualunque sistema e rappresenta il tipico carico di richieste di un server: "our MySQL tests - and the queries used in these tests - are based on a real world usage pattern of a real world database".
Qui http://www.anandtech.com/IT/showdoc.aspx?i=2291 si trovano informazioni sui tipi di test effettuati per i server.
Qui http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=4 quelli specifici per MySQL, con tanto di configurazione utilizzata.

3) I test non pretendono di estendere i risultati all'intero panorama delle applicazioni server.

4) Quelle sul comportamento di OS X con MySQL riguardo a fsync() sono soltanto delle impressioni e questo è scritto a chiare lettere su AnandTech. Nulla toglie ai risultati ottenuti dai test.

5) Lo stesso vale per le idee scrittu su AnandTech su kernel, processi, thread, ecc.: nulla tolgono ai risultati ottenuti nei test effettuati.

6) Lmbench è uno strumento molto usato per effettuare dei precisi test sulle chiamate di sistema. Anche qui, i risultati sono indiscutibili. Altro che "untrustable".

7) FLOPS è un benchmark sintetico costituito da una serie di test che rapresentano una tipica mistura di operazioni FP eseguite da applicazioni comuni.
E' pur sempre un benchmark sintetico, ma certamente è MOLTO più utile rispetto al calcolo dei FLOPS che un processore può teoricamente sviluppare e soltanto nelle condizioni più favorevoli in assoluto. Un G5 a 2Ghz può anche sviluppare 8GLOPS teoricamente, ma praticamente un'applicazione MOLTO difficilmente arriverà a sfruttare tutta questa potenza di calcolo; infatti i risultati si vedono.

8) Linpack è un test MOLTO specifico. Infatti è l'UNICO test usato per valutare le prestazioni dei supercomputer che vengono poi inseriti nella famosa TOP500. Quindi è quanto di più lontano dalla realtà si possa avere: applicazioni desktop e server generalmente si comportano in maniera molto diversa.

9) L'eventuale uso di un XServer non è detto che avrebbe migliorato i risultati: è vero che ha una gestione dell'I/O migliore, ma è anche vero che i G5 girano a 2,3Ghz (il massimo per adesso, se non erro) e le memorie sono le ben più lente ECC registered (usata negli Opteron e Xeon testati).

10) E' vero che gli XServer sono dotati di due LAN 1000, come gli Opteron e Xeon usati nelle prove, ma è anche vero è stato usato una sola LAN nei test.

Un G5 a 2Ghz può anche sviluppare 8GLOPS teoricamente, ma praticamente un'applicazione MOLTO difficilmente arriverà a sfruttare tutta questa potenza di calcolo; infatti i risultati si vedono.

a riconferma, un cell a 4 ghz può sviluppare teoricamente 256 GFLOPS, ovviamente non vuol dire un cazzo a meno che non ti serve decodificare / codificare mille mila flussi video assieme o non hai un cluster dedicato AD UN CERTO TIPO di calcolo vettoriale (mica va bene per tutto, non a caso di supercluster con i g5 ne hanno fatti due in tutto...)... ottenere una grande capacità di calcolo in vettoriale è facile (i processori delle nuove console lo dimostrano), ottenere invece capacità nel general purpose è complesso: per questo i concorrenti degli x86 non potendo primeggiare nel secondo ambito ripiegano sul primo... però alla fine è un po' come paragonare un dragster con un'impreza, il dragster sul dritto andrà l'incredibile, peccato che poi lo puoi usare solo per quello specifico tipo di applicazione =)

a riconferma, un cell a 4 ghz può sviluppare teoricamente 256 GFLOPS, ovviamente non vuol dire un cazzo a meno che non ti serve decodificare / codificare mille mila flussi video assieme o non hai un cluster dedicato AD UN CERTO TIPO di calcolo vettoriale (mica va bene per tutto, non a caso di supercluster con i g5 ne hanno fatti due in tutto...)... ottenere una grande capacità di calcolo in vettoriale è facile (i processori delle nuove console lo dimostrano), ottenere invece capacità nel general purpose è complesso: per questo i concorrenti degli x86 non potendo primeggiare nel secondo ambito ripiegano sul primo... però alla fine è un po' come paragonare un dragster con un'impreza, il dragster sul dritto andrà l'incredibile, peccato che poi lo puoi usare solo per quello specifico tipo di applicazione =)

Mille mila flussi video = 1 milione di flussi? :sofico: :asd:

Mille mila flussi video = 1 milione di flussi? :sofico: :asd:

no... mille mila = 3


oh, che volete? per me 3 è tanto :asd: