PDA

View Full Version : Apple e Intel, ancora indiscrezioni


Redazione di Hardware Upg
14-11-2005, 13:46
Link alla notizia: http://www.hwupgrade.it/news/apple/15784.html

Secondo voci attendibili pare che i primi sistemi ad essere protagonisti del passaggio ad Intel saranno gli iMac nel corso del MacWorld Expo 2006

Click sul link per visualizzare la notizia.

quartz
14-11-2005, 13:57
Bah...io continuo ad avere forti dubbi...
L'iMac sarebbe quello che meno di tutti ha bisogno di un processore Intel...
Con il G5 ha ancora ampi margini di crescita (soprattutto se pensiamo ai Dual-Core).

Inoltre i vantaggi di adottare subito un x86 verrebbero annullati (almeno in partenza) dalla praticamente nulla disponibilità di software compilato per tale architettura.
Con Rosetta le prestazioni sarebbero peggiori che con un vecchio PPC.. :muro:

Maggix
14-11-2005, 14:04
A me basterebbe che facessero una svendita degli attuali PowerBook :D Ci sarà qualche possibilità ?

Riguardo ai Powerbook: era ora di aggiornarli. Gli iMac invece è strano, il G5 è un'ottima CPU...

quartz
14-11-2005, 14:08
Non credo che i PowerBook li svenderanno...
Anzi, ben presto i PPC diventeranno di inestimabile valore! :sofico: :D

Bluknigth
14-11-2005, 14:09
Sinceramente trovo folle la mossa di Apple. Se è vero che i Power-Pc non avevano uno sviluppo grandioso, neanche i processori Intel o AMd hanno avuto nel corso dell'anno grandi rivoluzioni a livello di performance.

Fosse rimasta con IBM e il suo Cell (che ricordo verrà montato negli AS400, oltre che nella play) forse avrebbe mantenuto la sua nicchia senza
problemi. E avrebbe potuto continuare con le sue pubblicità di distinguo dal mondo pc. Voglio proprio vedere come faranno a bloccare il funzionamento dell'os, con un dispositivo hw, che secondo me verrà by- passato in tempo zero da qualche ben intenzionato.... O viceversa tutti col Tiger nel pc... Mah

Leron
14-11-2005, 14:23
Inoltre i vantaggi di adottare subito un x86 verrebbero annullati (almeno in partenza) dalla praticamente nulla disponibilità di software compilato per tale architettura.
veramente già ora esiste parecchio software già compilato per osx/x86, il resto arriverà nel giro di poco tempo

Sinceramente trovo folle la mossa di Apple. Se è vero che i Power-Pc non avevano uno sviluppo grandioso, neanche i processori Intel o AMd hanno
beh insomma... la presentazione dei dual core non è che sia poi da buttar via

e cmq non si parla di quest'anno, ma dei prossimi anni: g5 non ha più margini di sviluppo e sui portatili non ci poteva andare


Fosse rimasta con IBM e il suo Cell (che ricordo verrà montato negli AS400, oltre che nella play) forse avrebbe mantenuto la sua nicchia senza
problemi.
Cell non è un processore adatto a un PC o a un MAC: fa bene il suo lavoro per quello che deve fare in una play ma non è progettato per l'utilizzo in un PC, non ha senso quindi dire "se apple fosse rimasta a ibm e il suo cell": apple con Cell non ci è mai stata


in merito qui trovi una discussione interessante

http://www.hwupgrade.it/forum/showthread.php?t=933158&page=4&pp=20&highlight=cell+cluster.com


Il Cell e' uno stream processor, non certo un processore general purpose.
Come general purpose avrebbe la stragrande maggioranza dei transistor inoperanti nella stragrande maggioranza dei casi, operando solo con il core PowerPC; un multi core general purpose con lo stesso numero di transistor lo surclasserebbe.

Per un videogioco, approcci multi core + GPU sono estremamente piu' efficienti del Cell, che non e' in grado di svolgere operazioni di rasterizzazione con l'efficienza di una GPU ad esempio. Per suonare un MP3 (non credo si abbia bisogno di suonarne un centinaio in contemporanea ) non c'e' bisogno di scomodare uno stream processor e i restanti transistor potrebbero essere usati per altri compiti.

In ambiente scientifico, al contrario, un processore come il Cell avrebbe ottimi usi soprattutto per problemi altamente paralleli.

In sintesi: il Cell presentato come processore general purpose fantascientifico in grado di fare tutto piu' veloce di tutto e' pura fantasia da marketing. E' uno strumento ottimo per determinati compiti, non adatto ad altri compiti e va usato per quello.

Lud von Pipper
14-11-2005, 14:29
La gente compra gli I-Mac perchè "Fa figo", quindi venderanno a valanghe (sempre e comunque) e permetteranno un testing del software.
Gli I-Mac invece sono dedicati a chi non sa neppure che cosa c'è dentro e finchè "vanno" non c'è ragione di sostituirli con un nuovo prodotto.
I Mac professionali saranno gli ultimi ad uscire perchè il cliente cerca Software testato e stabile più che prestazioni, gia adesso adeguate con i G5 Dual.
Il Powermac richiede un pò più di ingegnerizzazione rispetto all' I-Mac specie nei consumi per non essere "Solo un altro portatile Centrino" e forse ritarderà ancora.

c#pefe#r
14-11-2005, 14:29
io ero deciso a fare il "grande passo" verso apple ma ora come ora nn me la sento di comprare un power book ke tra 3/4 mesi sarà "vekkio", vuol dire ke aspetterò. Apparte questo sono moooolto curioso di vedere ke prodotti verranno fuori, spero solo ke i prezzi nn aumentino ke gia così sono abbastanza proibitivi.

Bluknigth
14-11-2005, 14:58
Sinceramente parto dall'idea che il Mac sia utilizzato massicciamente in ambiti grafici, qualunque essi siano. Sicuramente in una funzione di calcolo pura una macchina intel o AMD dual core sarà più performante.
Ma per esperienza per le attività quotidiane da ufficio un Procio a 3,2GHz (reali o meno) mi sembra più che sufficiente. Negli ambiti videogame, forse perchè non ancora ottimizzati, vedo che le vere differenze le fanno le GPU. La maggior parte delle applicazioni utilizzate da amici e parenti sono la ricodifica di Film, musica e tanto altro con cui uno Streaming processor credo vada a nozze. Quindi a parte ambiti di progettazione particolari non vedo grandi svantaggi ad utilizzare Cell, come non credo che sia impossibile vederlo crescere con altri core dedicati al calcolo puro.

Io rimango dell'opinione che se Sony è furba e presenta la PS3 con un sistema operativo User Frendly (linux con una interfaccina a prova di stupido), un bell'HD, il Blue Ray, il supporto a periferiche di archiviazione di massa esterna, magari lapossibilità di registrare programmi televisivi e una grande connettività a un prezzo inferiore ai 600€ tanta gente il desktop lo butta via, specie se ha un bel TV lcd 720P.


Il 70% che fai con il pc potresti farle con la console di casa.
Per le altre siamo solo una nicchia che le sfrutta.....

Leron
14-11-2005, 15:05
ma lo hai letto il thread che ti ho postato? :D

il fatto non è che sia più o meno potente, è che il cell non è un processore general purpose e è uno spreco gigantesco usarlo per quello

alla apple non sono scemi: montare un processore che per il 90% del tempo starebbe agirarsi i pollici facendo da tappo non è una scelta granchè saggia


basta conoscere un attimo come funzionano i processori per capire che cell sarebbe una cosa sprecata su un computer general purpose


basta leggere quello che si dice in quel thread, e sinceramente fek non è il primo che passa

ShinjiIkari
14-11-2005, 15:16
Secondo me è tutta una buffonata, mo' tolgono i G5 per metterci gli Yonah, che poi sono a 32bit, con buona metà del Software che gira emulando un G3.. ma per piacere. In ogni caso passare da una cpu a 64bit ad una a 32bit è una mossa commercialmente sbagliatissima.

Leron
14-11-2005, 15:23
Secondo me è tutta una buffonata, mo' tolgono i G5 per metterci gli Yonah, che poi sono a 32bit, con buona metà del Software che gira emulando un G3.. ma per piacere. In ogni caso passare da una cpu a 64bit ad una a 32bit è una mossa commercialmente sbagliatissima.
quando il software non usa i 64bit il vantaggio non esiste

cmq preferirei un 32bit che consuma poco e ha buone prestazioni rispetto a un 64bit arrivato alla fine del ciclo vitale (nessuna possibilità di miglioramento) e che scalda troppo (mi riferisco a g5 su powerbook)


PS: ho un powerbook

sirus
14-11-2005, 15:58
Secondo me è tutta una buffonata, mo' tolgono i G5 per metterci gli Yonah, che poi sono a 32bit, con buona metà del Software che gira emulando un G3.. ma per piacere. In ogni caso passare da una cpu a 64bit ad una a 32bit è una mossa commercialmente sbagliatissima.
guarda che gli Yonah di sicuro non sfigurano contro un G5 anzi...
e sicuramente consumeranno molto meno fornendo la possibilità di rimpicciolire ancora di più iMac ;)
e poi con i G5 l'unico utilizzo dei 64bit si ha nell'indirizzamento della memoria, tutte le altre operazioni sono fatte a 32bit :( quindi dato che su un iMac è difficile montare più di 4GB di RAM (forse anche impossibile attualmente) aver questo limite iniziale non sarebbe un problema :O

io appoggio Apple ;) e sono molto curioso di vedere cosa tirerà fuori dal Pentium M DC ;)

ShinjiIkari
14-11-2005, 16:01
Magari queste voci le hanno messe in giro alla Apple per far sbrigare gli sviluppatori a fare il porting :D

quartz
14-11-2005, 16:07
Secondo me è tutta una buffonata, mo' tolgono i G5 per metterci gli Yonah, che poi sono a 32bit, con buona metà del Software che gira emulando un G3.. ma per piacere.
D'accordissimo! :mano:
Onore ai G5, che ancora possono dire molto, soprattutto in versione Dual-Core. :ave: :D
In ogni caso passare da una cpu a 64bit ad una a 32bit è una mossa commercialmente sbagliatissima.
Su questo sono un po' meno d'accordo.
In effetti i 64 bit servono REALMENTE solo per applicazioni scientifico-matematiche... :rolleyes:

GREZZO16
14-11-2005, 16:17
sotto sotto per me c'è qualcosa che centra con il palladium.
forse dato che ibm non riusciva a fare na roba seria per adeguarsi a quel nuovo standard di sicurezza, appla ha pensato di affiliarsi al più grande produttore di cpu in the world.
poi il logo intel (TU-tuTUtuTU = musichetta dell'intel) sarà di sicuro richiamo perchè per i profani APPLE= sicurezza ma non windows, ed INTEL= processori potenti su tutti i pc.
metti insieme ed ecco che la gente inzia a muoversi in massa verso gli apple.

ps= ho un pc con cpu amd

OverCLord
14-11-2005, 16:28
Grezzo ha ragione, sicuramento avranno chiesto a un po' di gente cosa ne pensavano di un Apple Intel based, e gli utonti avranno risposto uau che figo!
Lo sappiamo solo noi che Intel e' un monopolista attaccato piu' al ghello che alla bonta' dei prodotti e che non vede l'ora di rifilarci la sola DRM!
Speriamo che quanto avviene con Sony li faccia riflettere sull'opportunita' di fare cio'!
:yeah:

Xadhoomx
14-11-2005, 16:30
In realtà l'architettura G5 ha un indirizzamento a 42Bit...se non ci credete andate a leggere...

Xadhoomx
14-11-2005, 16:32
No quartz, quando inizi a lavorare su progetti di DVD molto grandi oltre i 4GB è solo un piacere..perchè non ci sono quasi più accessi all'HD...hai mai provato un Dual G5 con 6GB di RAM? Spaventosamente real time...

quartz
14-11-2005, 16:37
Grezzo ha ragione, sicuramento avranno chiesto a un po' di gente cosa ne pensavano di un Apple Intel based, e gli utonti avranno risposto uau che figo!
Lo sappiamo solo noi che Intel e' un monopolista attaccato piu' al ghello che alla bonta' dei prodotti e che non vede l'ora di rifilarci la sola DRM!
Speriamo che quanto avviene con Sony li faccia riflettere sull'opportunita' di fare cio'!
:yeah:
Prima di fare affermazioni del genere, fossi in te, mi darei un'occhiata alla roadmap di Intel. :rolleyes:
Nessuno nega che AMD stia facendo processori OTTIMI, ma anche Intel con questa sua recente Roadmap, promette molto bene.
In particolare apprezzo molto che farà sforzi soprattutto sul rapporto Performance/Watt, cosa non indifferente per l'evoluzione dei portatili e per l'ambiente!

Gli Yonah e i Merom sono davvero promettenti. Definire Intel "un monopolista attaccato piu' al ghello che alla bonta' dei prodotti" è quanto meno fuori luogo, specie guardando al futuro. :sofico:

quartz
14-11-2005, 16:40
In realtà l'architettura G5 ha un indirizzamento a 42Bit...se non ci credete andate a leggere...E' vero, ma credo che siano più che sufficienti.
Chi ha bisogno di più di 4 TeraByte di RAM? :sofico:

matteos
14-11-2005, 16:42
sotto sotto per me c'è qualcosa che centra con il palladium.
forse dato che ibm non riusciva a fare na roba seria per adeguarsi a quel nuovo standard di sicurezza, appla ha pensato di affiliarsi al più grande produttore di cpu in the world.
poi il logo intel (TU-tuTUtuTU = musichetta dell'intel) sarà di sicuro richiamo perchè per i profani APPLE= sicurezza ma non windows, ed INTEL= processori potenti su tutti i pc.
metti insieme ed ecco che la gente inzia a muoversi in massa verso gli apple.

imho palladium è solo un aspetto della migrazione ad intel....principalmente è dovuto allo sviluppo della piattaforma.
IBM ha puntato sul settore delle console dove l'hw rimane quello per tot anni mentre lo sviluppo in ambito pc o workstation avrebbe richiesto ingenti risorse e tempo.
come è successo per motorola che ha deciso di diversi in due aziende,freescale per i microprocessori e motorola per il reparto telefonia cellulare.
settori (console&cellulari)più redditizi del settore microprocessori per pc.
per il discrorso..."wow..intel processori più potenti del mondo",non crediate che molti macuser siano felici di questa scelta ;molti volevano AMD.

samslaves
14-11-2005, 17:29
http://www.flyingsnail.com/20051011macsinebench2003.html

samslaves
14-11-2005, 17:32
Least but not last

http://eshop.macsales.com/benchmark/results/step_2.cfm?gid=112

docvale
14-11-2005, 18:15
Partendo dal concetto che si sta speculando su previsioni di analisti, che notoriamente non hanno la sboccia di cristallo, tutti sanno che il grosso delle esigenze di apple da soddisfare col passaggio ad intel sono, per ora, quelle per soluzioni mobile. Difatti immaginavo un aggiornamento dei portatili e del mac mini (che ha hw portatile...). Se poi rinnoveranno in fretta iMac, ricordiamoci che parliamo di un computer che sta assumendo caratteri consumer e non professionali (media center, telecomando, iSight...), pertanto, commercialmente, conta più che tiri di più (e non perché c'è intel-inside, ma perché magari oltre ad un uso office puoi installare pur win così se vuoi ci giochi), piuttosto che preoccuparsi di quanto attendere per lanciarlo col miglior processore possibile. Quello è un problema per i PMac, che con ogni probabilità, e buon senso visto come sono messi ora, saranno gli ultimi a switchare

^TiGeRShArK^
14-11-2005, 18:26
D'accordissimo! :mano:
Onore ai G5, che ancora possono dire molto, soprattutto in versione Dual-Core. :ave: :D

Su questo sono un po' meno d'accordo.
In effetti i 64 bit servono REALMENTE solo per applicazioni scientifico-matematiche... :rolleyes:
stai parlando di x86-64 vero???:D
e il + 20% nel rendering e il +15% nel video editing dove lo metti???
tra lde applicazioni scientifike o tra quelle matematike??? :sofico:

^TiGeRShArK^
14-11-2005, 18:30
http://www.flyingsnail.com/20051011macsinebench2003.html
:rotfl:
ma li leggi i link ke posti????
vuoi paragonare un X2 3800+ con un quad g5?????
hai idea della PIKKOLISSIMA DIFFERENZA DI COSTI????
:rotfl:
almeno l'avessi paragonato con un A64 X2 4800+! :D

P.S. e nn dimentikiamoci del 4400+@2.8 del nostro caro mo3bius! :D

DioBrando
14-11-2005, 18:39
se Apple ha operato un cambio di rotta verso Intel e n AMD le motivazioni ci sn e n sn necessariamente tecnologiche.
Per quanto ora come ora dal pdv desktop e server le cpu AMD hanno IMHO qlc in +, bisogna tener conto delle due forze, della capacità di soddisfare la richiesta e di produrre conseguentemente ( avete presente il numero di Fab Intel e quelle AMD?), senza contare l'enorme forza del brand Centrino ( che potrebbe in un prox futuro applicarsi anche ad Apple) o gli interessi che ha Intel nel campo dei dispositivi mobili con gli XScale.

Insomma, senza nulla togliere ad AMD che sta facendo uno splendido lavoro, Intel ha tutto un altro spessore ( inteso come forza commerciale e trainante del mercato)...

neverloser
14-11-2005, 18:40
Avevo fatto una segnalazione ad Andrea Bai per una notizia secondo me molto interessante... peccato abbia scelto di non pubblicarla... la posto qui anche se non ha il risalto che merita:

"Apple brevetto per un doppio OS sui Mac
Apple registra un brevetto che potrebbe permettere ai Mac di caricare contemporaneamente due sistemi operativi. Potrebbe essere la carta vincente che metterà in un angolo i produttori di PC e potenzialmente anche Microsoft. "

notizia completa:
http://www.macitynet.it/macity/aA23022/index.shtml

nicgalla
14-11-2005, 18:55
A parte che postare dei link senza un minimo di commento mi sembra abbastanza inutile, ma almeno hai visto che razza di porcheria hai linkato?

Scrivono che un Athlon X2 3800+ va a 2.5Ghz quando invece fa a soli 2 Ghz, e i risultati dei tre PowerMac, con il medesimo processore, fa segnare i migliori risultati con una ATI 9650, e non con una X800 ma soprattutto la 6800 Ultra ultima.. e meno male che si tratta di un test OpenGL :D

Insomma il miglior processore per Apple sarebbe stato un Athlon64 X2, un prezzo inferiore considerata l'accoppiata mobo+cpu rispetto ad Intel, e non solo più prestazionale del P4 D (che però è stato testato con la VGA integrata....) ma paragonabili ai G5 che però vanno a ben 700 mhz in più, con tutto quel che ne consegue di consumi e rumorosità...

Gello
14-11-2005, 19:42
Non hanno scelto AMD xche' quest'ultima collabora in modo stretto con IBM tutto qui.....

Sottoscrivo poi il discorso del traino commerciale del nome Intel nonostante la dubbia qualita' delle cpu (parlo del presente).

Per quanto riguarda palladium, purtroppo anche AMD avra' la sua infausta variante..

jiadin
14-11-2005, 19:57
mi lascia un po' perplesso la possibilità che gli imac vengano subito upgradati, i primi a necessitarlo sono i mac basati su g4...
io spero nel mac mini (che vorrei acquistare), comunque anche il powerbook(soprattutto) e l'ibook necessiterebbero...
l'unica cosa sospetta, sul mini, è il fatto che pare abbiano cambiato la configurazione 1.33 il minimo e 1.50 il max e con scheda video da 64 mega, ma senza dire nulla a nessuno.. già da un po' poi..

siliconbrain
14-11-2005, 20:46
Ragazzi secondo me è tutta colpa della IBM che non è riuscita a fornire alla Apple nuovi processori a basso consumo con un rapporto potenza/watt consumati adeguato ed ai tempi nostri dove il mercato notebook è in fortissima crescita la Apple non poteva restare al palo e guardare. Quindi ONORE e GLORIA ai processori PowerPC ma cmq giustissima scelta commerciale da parte Apple.

PS. P4 630, Intel 915Gl, 512 MB ddr400, HD 80 Sata = XBench 38,34
Provato personalmente e chi usa Mac sa di cosa sto parlando.

quartz
14-11-2005, 21:29
Ragazzi secondo me è tutta colpa della IBM che non è riuscita a fornire alla Apple nuovi processori a basso consumo con un rapporto potenza/watt consumati adeguato ed ai tempi nostri dove il mercato notebook è in fortissima crescita la Apple non poteva restare al palo e guardare. Quindi ONORE e GLORIA ai processori PowerPC ma cmq giustissima scelta commerciale da parte Apple.

PS. P4 630, Intel 915Gl, 512 MB ddr400, HD 80 Sata = XBench 38,34
Provato personalmente e chi usa Mac sa di cosa sto parlando.
Hai proprio ragione!

PS: ma quello di Xbench è un punteggio bassissimo! Ovviamente tutto girava sotto Rosetta, vero?

ShinjiIkari
14-11-2005, 22:59
Lasciamo stare xbench, che è attendibile quanto lo è Emilio Fede.

^TiGeRShArK^
14-11-2005, 23:07
Avevo fatto una segnalazione ad Andrea Bai per una notizia secondo me molto interessante... peccato abbia scelto di non pubblicarla... la posto qui anche se non ha il risalto che merita:

"Apple brevetto per un doppio OS sui Mac
Apple registra un brevetto che potrebbe permettere ai Mac di caricare contemporaneamente due sistemi operativi. Potrebbe essere la carta vincente che metterà in un angolo i produttori di PC e potenzialmente anche Microsoft. "

notizia completa:
http://www.macitynet.it/macity/aA23022/index.shtml
ehm.....
vanderpool?
pacifica?
dicono niente? :mbe:

archibald tuttle
14-11-2005, 23:37
ehm.....
vanderpool?
pacifica?
dicono niente? :mbe:

la cosa interessante non è il brevetto, sul quale penso che quella news lasci il tempo che trova visto che appunto le tecnologie di virtualizzazione già esistono, ma il fatto che legalmente saranno solo le macchine apple che potranno far girare sia osx che vista

credo che la cosa stimoli l'immaginazione di un po' tutti gli appassionati di informatica (fermo restando che volendo si potrà fare anche con linux chiaramente)
e credo che possa essere un vantaggio per apple sugli altri produttori, chiaramente non su microsoft (anche perché a guardar bene il mercato senza ragionare da fanboy, apple e microsoft non sono neanche aziende concorrenti)

Daishi
15-11-2005, 07:19
Non so se la colpa è solo di IBM.

Considerando che IBM ha processori PPC a 15W, come presentati il giorno dopo l'annuncio del passaggio ad Intel di Apple . . .

Che sia un problema di chipset?

Credo che le ragioni del passaggio siano da ricercare nei costi di sviluppo delle piattaforme. (ormai Apple lascia tutto in mano ai "Cinesini" e si occupa solo di scelte commerciali ed estetiche)

Rob50
15-11-2005, 08:39
Prova:

http://reviews.zdnet.co.uk/software/os/0,39024180,39235916,00.htm

Leron
15-11-2005, 08:54
Prova:

http://reviews.zdnet.co.uk/software/os/0,39024180,39235916,00.htm
quei test sono fatti sulla beta leaked del 10.4.1: è vecchia di mesi (ora c'è la .3 e sta per uscire la .4)

tra il resto su quella versione non gira itunes compilato per x86 che è uscito solo per le versioni successive

matteos
15-11-2005, 09:02
Non so se la colpa è solo di IBM.

Considerando che IBM ha processori PPC a 15W, come presentati il giorno dopo l'annuncio del passaggio ad Intel di Apple . . .

Che sia un problema di chipset?

Credo che le ragioni del passaggio siano da ricercare nei costi di sviluppo delle piattaforme. (ormai Apple lascia tutto in mano ai "Cinesini" e si occupa solo di scelte commerciali ed estetiche)
ma guarda quell'annuncio mi ha dato l'idea "pariamoci le spalle",tra l'altro credo sia un processore che esiste solo su carta perchè la produzione non è mai partita

neverloser
15-11-2005, 09:06
ehm.....
vanderpool?
pacifica?
dicono niente? :mbe:

Mi dicono che esistono le potenzialità per far sì che il brevetto di Apple si possa effettivamente realizzare.
Mi dicono altresì che in futuro tutti i sistemi operativi gireranno virtualizzati grazie ai processori.
Mi dicono inoltre che (credo e non ne sono sicuro) che al momento non esiste nulla di tutto ciò se non a livello teorico (tranne forse su Linux).
Infatti ci sono i processori (sbaglio o proprio in questi giorni stanno uscendo? così mi sembra d'aver letto) ma manca il software per sfruttare questa caratteristica o no? Inoltre le prima applicazioni saranno in ambito server quindi niente per i PC comuni. Speri forse che la Microsoft sfrutti questa caratteristica? Mah può darsi io non ho sentito nulla su vista che ne parli ma lieto d'esser smentito. Restano 2 piattaforme Linux e MacOS.
Entrambe ci punteranno sicuramente.
Mi dicono che la tua risposta non ha un grande senso visto che non ho scritto rivoluzione: "Apple porta il verbo informatico sulla Terra: la virtualizzazione" (oooooooohhhhh... echi di persone incredule). Bensì è un semplice indizio di dove Apple stìa puntando e che ha un'arma in mano non da poco. Il triplo boot. Cosa che nessun altro PC può fare legalmente. E forse (ma ne dubito) non potrà mai fare. Se poi di triplo boot non si parla ma sarà virtualizzazione integrata in MacOSX o Windows funzionante come X11 funziona attualmente su OSX o proprio 2 sistemi in parallelo... chi lo sà? Io non ho le competenze adatte neanche per immaginarlo...

samslaves
15-11-2005, 10:35
ZDNet ha fatto un tet a tet tra OS X e Win su una macchina PC. Indovinate chi ne esce vincitore:

http://reviews.zdnet.co.uk/software/os/0,39024180,39235916,00.htm

anche se ancora in versione definitiva?

samslaves
15-11-2005, 10:39
Tra l'altro provato anche su di un AMD X2 4800+ ... non dico altro.

Automator
15-11-2005, 12:40
agli sviluppatori è stato un agg del dev kit per testare la funzione di "aggiornamento SW"....
in genere viene rilasciato quando si è vicini alla GM... per cui...

Automator
15-11-2005, 12:46
x neverloser:
hai presente come gira os9 su osx? ossia Classic?
penso che la macchina "virtuale" verrà implementata in maniera simile
ovviamente IMHO

samslaves
15-11-2005, 14:19
azz... gia' postato :| nella pag. precedente

cdimauro
16-11-2005, 07:59
Secondo me è tutta una buffonata, mo' tolgono i G5 per metterci gli Yonah, che poi sono a 32bit, con buona metà del Software che gira emulando un G3.. ma per piacere. In ogni caso passare da una cpu a 64bit ad una a 32bit è una mossa commercialmente sbagliatissima.
L'hai mai visto un G5 sfruttare (decentemente) i 64 bit?

Quando fu presentato il PowerMac G5, gli analisti (sempre loro, gli espertoni :rolleyes: ), dissero che ci sarebbe voluto un anno per vedergli sfruttare i 64 bit. S'è visto, infatti.

Non per negligenza degli sviluppatori, quanto per buon senso: far funzionare i G5 sempre a 64 bit avrebbe comportato mediamente un notevole calo prestazionale.

Ecco perché Apple s'è guardata bene di rilasciare una versione di OS X "full 64 bit".

Quindi il passaggio dai 64 bit /PPC ai 32 bit/x86 non è affatto una mossa sbagliata, tenendo in considerazione tutto ciò.

E' sbagliata perché, al contrario dei PowerPC, passando da x86 a x86-64 i benefici prestazionali sono notevoli, perché si tratta di un'architettura sostanzialmente diversa e che introduce notevoli migliorie (non soltanto l'estensione a 64 bit di registri e indirizzi, quindi).

cdimauro
16-11-2005, 08:03
No quartz, quando inizi a lavorare su progetti di DVD molto grandi oltre i 4GB è solo un piacere..perchè non ci sono quasi più accessi all'HD...hai mai provato un Dual G5 con 6GB di RAM? Spaventosamente real time...
Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente).

Attualmente il limite per le applicazioni (normali), s.o. e driver è comunque di 4GB TOTALI, il che vuol dire che:
- non si possono avere 4GB di memoria per applicazione (sarebbe ottimo sfruttare più di 4GB almeno in questo modo);
- la memoria oltre i 4GB viene utilizzata come cache dal s.o..

jo.li.
16-11-2005, 15:12
L'hai mai visto un G5 sfruttare (decentemente) i 64 bit?

Quando fu presentato il PowerMac G5, gli analisti (sempre loro, gli espertoni :rolleyes: ), dissero che ci sarebbe voluto un anno per vedergli sfruttare i 64 bit. S'è visto, infatti.

Non per negligenza degli sviluppatori, quanto per buon senso: far funzionare i G5 sempre a 64 bit avrebbe comportato mediamente un notevole calo prestazionale.

Ecco perché Apple s'è guardata bene di rilasciare una versione di OS X "full 64 bit".

Quindi il passaggio dai 64 bit /PPC ai 32 bit/x86 non è affatto una mossa sbagliata, tenendo in considerazione tutto ciò.

E' sbagliata perché, al contrario dei PowerPC, passando da x86 a x86-64 i benefici prestazionali sono notevoli, perché si tratta di un'architettura sostanzialmente diversa e che introduce notevoli migliorie (non soltanto l'estensione a 64 bit di registri e indirizzi, quindi).

Scusa ma che vuol dire fare girare sempre i g5 a 64bit????

I G5 fanno girare i normali programmi a 32bit alla stessa velocità di quelli scritti a 64bit, tanto che a differenza di altre architetture come dici tu non c'e' nessun vantaggio a fare girare il codice a 64bit se non per avere un indirizzamento maggiore di memoria.

Quindi 32 o 64 bit per i g5 sarebbe la stessa cosa dal punto di vista prestazionale, ecco perché OSX è interamente a 32 bit anche se è possibile comunque fare girare programmi a 64 bit ma senza interfaccia grafica che rimarrebbe a 32bit.

Il passaggio a intel non è semplicemente un problema di processore ma di ottenere un pacchetto completo migliore (chipset) dal punto di vista prezzo/prestazioni e del risparmio energetico, problema molto importante per la Apple non soltanto per il settore dei notebook ma anche per la produzione di macmini e degli iMac.

jo.li.
16-11-2005, 15:17
Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente).

Attualmente il limite per le applicazioni (normali), s.o. e driver è comunque di 4GB TOTALI, il che vuol dire che:
- non si possono avere 4GB di memoria per applicazione (sarebbe ottimo sfruttare più di 4GB almeno in questo modo);
- la memoria oltre i 4GB viene utilizzata come cache dal s.o..

E' vero che il 100% dei programmi per osx sono a 32bit e non possono indirizzare più di 4GB di memoria, ma se io ho la necessità di dovere adoperare contemporaneamente dei programmi che per esempio ognuno di essi mi occupa 3 o 4 gb di memoria, capisci che avere un sistema che può effettivamente adoperare 8 o anche 16GB (come gli ultimi PowerMac) di memoria può essere un notevole vantaggio.

Criceto
16-11-2005, 17:54
E' vero che il 100% dei programmi per osx sono a 32bit e non possono indirizzare più di 4GB di memoria, ma se io ho la necessità di dovere adoperare contemporaneamente dei programmi che per esempio ognuno di essi mi occupa 3 o 4 gb di memoria, capisci che avere un sistema che può effettivamente adoperare 8 o anche 16GB (come gli ultimi PowerMac) di memoria può essere un notevole vantaggio.

No, non è vero niente. Cdmauro come al solito sparge FUD su tutto ciò che Apple. OS X Tiger può avere applicazioni che allocano 64bit di Ram, quindi oltre 4 GBytes. Per esempio lo fa Mathematica.
Quello che dici tu lo faceva Panther (il 10.3).

jo.li.
16-11-2005, 21:45
No, non è vero niente. Cdmauro come al solito sparge FUD su tutto ciò che Apple. OS X Tiger può avere applicazioni che allocano 64bit di Ram, quindi oltre 4 GBytes. Per esempio lo fa Mathematica.
Quello che dici tu lo faceva Panther (il 10.3).

Già, non so da dove mi sia uscito quel 100%, ma comunque sapevo che c'era qualche applicazione a 64bit. :D

ZBrando
17-11-2005, 08:19
Secondo me queste voci sbagliano. A parte il fatto che in casa Apple tra presentazione e consegna c'è una bella differenza :p gli iMac e i Powerbook sono le ultime macchine che vedrei aggiornate in un arco così breve di tempo.
L'iMac perchè lo hanno appena aggiornato e il G5 ha ancora qualche margine di crescita, il Powerbook perchè sarebbe sprecato con Yonah, meglio aspettare Merom.
Semmai vedrei bene Yonah nei MacMini e negli iBook. Poi seguiranno gli iMac e infine i Powerbook con Merom. Per i Powermac e gli XServer, che credo saranno gli ultimi ad essere aggiornati per garantire loro stabilità di piattaforma, spero montino gli Xeon.

ZBrando
17-11-2005, 08:25
Sinceramente trovo folle la mossa di Apple. Se è vero che i Power-Pc non avevano uno sviluppo grandioso, neanche i processori Intel o AMd hanno avuto nel corso dell'anno grandi rivoluzioni a livello di performance.

Insomma, Centrino e Turion ti paiono poco? I G5 nei portatili proprio non ci entrano. Senza contare che volendo possono usare i processori ULV per fare macchine sottilissime o un tablet.
Conta inoltre che intel può spuntare prezzi migliori di IBM a causa della enorme produzione che ha e che oltre alle cpu da pc intel produce processori ARM che sono ottimi mi palmari, iPod o cellulari. E visto che Apple vorrebbe un iPhone...

Fosse rimasta con IBM e il suo Cell (che ricordo verrà montato negli AS400, oltre che nella play) forse avrebbe mantenuto la sua nicchia senza
problemi. E avrebbe potuto continuare con le sue pubblicità di distinguo dal mondo pc. Voglio proprio vedere come faranno a bloccare il funzionamento dell'os, con un dispositivo hw, che secondo me verrà by- passato in tempo zero da qualche ben intenzionato.... O viceversa tutti col Tiger nel pc... Mah

Sul fatto del perchè Cell non vada bene ti hanno già risposto, io mi limito a farti osservare che non è detto che Cell vada bene dapperutto (ad esempio sui portatili) e che Apple è bravissima a bloccare le sue macchine e i suoi programmi. (anche se una scappatoia gli smanettoni la troveranno)

cdimauro
17-11-2005, 09:17
Scusa ma che vuol dire fare girare sempre i g5 a 64bit????
Vuol dire avere s.o. e applicazioni che usano registri a 64 bit per dati e indirizzi.
I G5 fanno girare i normali programmi a 32bit alla stessa velocità di quelli scritti a 64bit,
Non è affatto vero: se le applicazioni fossero scritte tutte a 64 bit, mediamente ci sarebbe un calo prestazionale. Secondo te perché non c'è un Safari a 64 bit, ad esempio?
tanto che a differenza di altre architetture come dici tu non c'e' nessun vantaggio a fare girare il codice a 64bit se non per avere un indirizzamento maggiore di memoria.
Anche per manipolare dati a 64 bit più velocemente.

Sono comunque dei vantaggi rispetto all'architettura a 32 bit. Se non vengono sfruttati è perché non sempre vanno bene. Anzi.
Quindi 32 o 64 bit per i g5 sarebbe la stessa cosa dal punto di vista prestazionale,
Non è affatto vero.
ecco perché OSX è interamente a 32 bit anche se è possibile comunque fare girare programmi a 64 bit ma senza interfaccia grafica che rimarrebbe a 32bit.
E' così perché altrimenti le prestazioni ne avrebbero risentito. Inoltre i produttori di hardware avrebbero dovuto scrivere anche dei driver a 64 bit, il che non è certo cosa da poco.
Il passaggio a intel non è semplicemente un problema di processore ma di ottenere un pacchetto completo migliore (chipset) dal punto di vista prezzo/prestazioni e del risparmio energetico, problema molto importante per la Apple non soltanto per il settore dei notebook ma anche per la produzione di macmini e degli iMac.
Oltre a ciò è anche un problema di processore, visto che i PowerPC non sono più competitivi da tempo (parlando in generale ovviamente: poi ci sono casi specifici in cui sono la soluzione migliore).

cdimauro
17-11-2005, 09:19
E' vero che il 100% dei programmi per osx sono a 32bit e non possono indirizzare più di 4GB di memoria, ma se io ho la necessità di dovere adoperare contemporaneamente dei programmi che per esempio ognuno di essi mi occupa 3 o 4 gb di memoria, capisci che avere un sistema che può effettivamente adoperare 8 o anche 16GB (come gli ultimi PowerMac) di memoria può essere un notevole vantaggio.
E io cosa avrei detto di diverso?

Questo:

"Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente)."

Addirittura me l'hai anche quotato!

cdimauro
17-11-2005, 09:20
No, non è vero niente. Cdmauro come al solito sparge FUD su tutto ciò che Apple. OS X Tiger può avere applicazioni che allocano 64bit di Ram, quindi oltre 4 GBytes. Per esempio lo fa Mathematica.
Quello che dici tu lo faceva Panther (il 10.3).
Cosa non è ti chiaro di questo:
Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente).

Attualmente il limite per le applicazioni (normali), s.o. e driver è comunque di 4GB TOTALI, il che vuol dire che:
- non si possono avere 4GB di memoria per applicazione (sarebbe ottimo sfruttare più di 4GB almeno in questo modo);
- la memoria oltre i 4GB viene utilizzata come cache dal s.o..
? :rolleyes:

Sei sempre il solito fanboy. :mc:

quartz
17-11-2005, 09:59
Non è affatto vero: se le applicazioni fossero scritte tutte a 64 bit, mediamente ci sarebbe un calo prestazionale. Secondo te perché non c'è un Safari a 64 bit, ad esempio?
Addirittura un calo prestazionale?? :eek: :wtf: :ops:
E perchè?

cdimauro
17-11-2005, 10:47
Perché il G5 in modalità a 64 bit non offre nient'altro che registri dati a 64 bit e indirizzi a 64 bit. Questo vuol dire che:

1) il context switch passando da un processo/thread a un altro richiede più tempo (i dati da salvare/caricare sono di più, visto che quasi tutti i registri occupano il doppio dello spazio);

2) i puntatori occupano il doppio dello spazio; questo vuol dire che è richiesto più tempo per il loro caricamento/salvataggio richiede più tempo; inoltre occupando più spazio viene ridotto il numero di dati da caricare nelle cache dati, e quindi è più facile che si verifichino dei cache miss; poiché i puntatori sono molto utilizzati, puoi immaginare quanto questo possa inficiare le prestazioni (infatti è IL fattore che determina in buona sostanza il loro calo in questo caso).

quartz
17-11-2005, 10:56
Perché il G5 in modalità a 64 bit non offre nient'altro che registri dati a 64 bit e indirizzi a 64 bit. Questo vuol dire che:

1) il context switch passando da un processo/thread a un altro richiede più tempo (i dati da salvare/caricare sono di più, visto che quasi tutti i registri occupano il doppio dello spazio);

2) i puntatori occupano il doppio dello spazio; questo vuol dire che è richiesto più tempo per il loro caricamento/salvataggio richiede più tempo; inoltre occupando più spazio viene ridotto il numero di dati da caricare nelle cache dati, e quindi è più facile che si verifichino dei cache miss; poiché i puntatori sono molto utilizzati, puoi immaginare quanto questo possa inficiare le prestazioni (infatti è IL fattore che determina in buona sostanza il loro calo in questo caso).
I G5 però, a quanto ho letto, hanno la caratteristica di avere una branch prediction estremamente efficiente.
In più gli ultimi modelli hanno una cache di 1MB, quindi in parte recuperano . :mc: :D
Cmq sappi che neanche io sono un particolare estimatore dei G5. Secondo me hanno fatto un passo indietro, specie dal punto di vista dell'efficienza, rispetto ai G4. Hanno tolto, infatti, quella che era la caratteristica migliore dei G4, cioè la pipeline estremamente corta (7 stadi, contro 16 dei G5), e questo solo nella speranza di salire velocemente in frequenza (s'è visto infatti) :muro: :rolleyes:

In ogni caso IMHO i 64 bit sono una pura mossa commerciale da parte dei produttori di CPU (AMD in primis). A livello domestino non erano così necessari. In campo scientifico e/o server, magari sì.

jo.li.
17-11-2005, 14:32
Vuol dire avere s.o. e applicazioni che usano registri a 64 bit per dati e indirizzi.

Oltre a ciò è anche un problema di processore, visto che i PowerPC non sono più competitivi da tempo (parlando in generale ovviamente: poi ci sono casi specifici in cui sono la soluzione migliore).


Mi sa che stai generalizando un pò troppo, è chiaro che in alcuni casi riscrivere il codice a 64bit può avere dei vantaggi anche dal punto di vista prestazionale e forse dei svantaggi in altre situazioni ma se la Apple non ha riscritto il suo OS interamente a 64bit è perché ancora vende cpu che sono a 32bit e poi perché evidentemente le risorse da impiegare sarebbero state troppe in relazione ai vantaggi ottenuti.

Anche per i PowerPc mi sà che stai esagerando e generalizzando un pò troppo sembra quasi che tu stia parlando dei 68000. In prospettiva forse non sarerebbero più stati competitivi, ma adesso lo sono abbastanza.

jo.li.
17-11-2005, 14:44
E io cosa avrei detto di diverso?

Questo:

"Se l'applicazione gestisce l'indirizzamento a 64 bit si possono anche avere dei benefici accedendo a più di 4GB di memoria (dipende dal tipo di codice, ovviamente)."

Addirittura me l'hai anche quotato!

E' chiaro che se un'applicazione che gestisce i 64bit eccede i 4GB di memoria, ma poi tu avevi continuato dicendo che per il s.o. e i driver e le applicazioni "normali" il limite era di 4GB totali, e che tutto quello che eccedeva tale limite veniva utilizzato come cache dal sistema operativo, io ti ho fatto notare che nel MacOs X questo non è vero.

Criceto
17-11-2005, 17:28
Cosa non è ti chiaro di questo:

? :rolleyes:

Sei sempre il solito fanboy. :mc:

Oltre a sbagliare, sei perseverante nell'errore.
Ti è già stato spiegato 1000 volte come funzionano i 64bit di Tiger.
Non è come dici tu.

Criceto
17-11-2005, 17:30
Perché il G5 in modalità a 64 bit non offre nient'altro che registri dati a 64 bit e indirizzi a 64 bit. Questo vuol dire che:

E perchè. cos'altro dovrebbero includere questi fantomatici 64 bit?
Qual'è la definizione di processore a 64bit? E di applicazione a 64 bit?
Illuminaci... :rolleyes:

xeal
18-11-2005, 00:46
E perchè. cos'altro dovrebbero includere questi fantomatici 64 bit?

I 64 bit, di per sé, NIENTE.

La modalità a 64 bit (ovvero una implementazione dei 64 bit), poichè aggiunge comunque degli opcode, ovvero delle istruzioni nuove, potrebbe aggiungere anche delle funzionalità non disponibili in modalità a 32 bit, come nuove funzioni di calcolo (faccio un esempio banale e generico, senza riferimenti ad alcuna architettura: si potrebbe destinare uno dei nuovi opcode a un'istruzione che esegua la radice quadrata di un numero e aggiungere al processore la logica per calcolarla rapidamente, invece di usare più istruzioni e fare più calcoli - usando anche più registri), oppure anche nuove caratteristiche "interne", come l'aggiunta di nuovi registri.

L'architettura x86-64 (come l'equivalente EM64T di Intel) fa esattamente questo, fermo restando il "problema" di avere puntatori alla memoria più "grossi" per quelle applicazioni che non necessitano di molta memoria (e per le quali gli eventuali cache miss causati da molti puntatori a 64 bit potrebbero essere rilevanti).

Di conseguenza, un'implementazione dei 64 bit che "approfitta" dell'occasione per aggiungere qualosa di utile, come fa x86-64, presentera un comportamento (faccio una schematizzazione MOLTO generica) di questo tipo:

- in alcuni casi il problema "puntatori dopati" produrrà un calo prestazionale;

- in alcuni casi le caratteristiche "interne" e le nuove funzionalità aggiunte insieme alle nuove istruzioni compensano e annullano lo svantaggio precedente (se proprio non riescono a ribaltare la situazione);

- in alcuni casi (ad esempio, semplificando, applicazioni che elaborano dati a 32 bit, ma hanno bisogno di molta memoria, oppure eseguono molte operazioni e pochi accessi alla memoria e, avendo a disposizione più registri, possono ridurre ulteriormente gli accessi alla memoria) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano;

- in alcuni casi (applicazioni che manipolano dati a 64 bit e hanno bisogno di molta memoria e/o di più registri) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano.

Ne segue che (diciamo) mediamente o si hanno dei vantaggi, o non si hanno degli svantaggi, e cioè si hanno ancora dei vantaggi, perchè, nel caso in cui avere puntatori più "grossi" non comporta, complessivamente, uno svantaggio, il poter disporre di più memoria ram limita lo swap su hd, aumentando potenzialmente (la memoria "in più" chiaramente bisogna averla) le prestazioni con molti processi in esecuzione (questo potrebbe avvenire anche con le applicazioni per le quali i puntatori "dopati" cosituiscano un problema, poichè all'aumento di cache miss corrisponderebbe potenzialmente una diminuizione di page fault e accessi al disco; in ogni caso, sempre potenzialmente, sono di più i casi possibili in cui i vantaggi superano gli svantaggi).

Se invece si implementano i 64 bit in maniera "basilare", senza alcuna aggiunta/miglioria a contorno, è evidente che si possono avere vantaggi praticamente solo con applicazioni che elaborano massicciamente dati a 64 bit e/o necessitano di grandi quantità di memoria; in tutti gli altri casi, con gli applicativi già ben ottimizzati per l'architettura "di base" a 32 bit, alla quale sono stati semplicemente aggiunti 32 bit di dati in ciascun registro (senza aumentare il numero complessivo di registri - cosa che non è detto sia necessaria, comunque) e agli indirizzi di memoria, senza migliorare niente (che non si manifesti già in modalità a 32 bit), si rischia di avere dei cali prestazionali anche notevoli (e questo è tanto più vero, quanto più piccola è la quantità di ram richiesta dalle applicazioni e quanto minore è il numero di processi in esecuzione contemporanea).

E se il G5 applica il concetto dei 64 bit "nudo e crudo" ricade inevitabilmente in questa categoria. Se non vado errato è proprio per questo motivo che i programmi a 64 bit per OS X hanno un'interfaccia a riga di comando (o comunque non grafica).

Chiaramente tutto questo non ha nulla a che vedere con la definizione di processore a 64 bit; semplicemente ciò che sta a "contorno" e integra l'implementazione dei 64 bit può estenderne o limitarne l'utilità/i vantaggi, ovviamente parlando solo di ciò che si rende disponibile con le nuove istruzioni non disponibili se non "attivando" i 64 bit: in questo contesto non contano le migliorie che, ad esempio, possono essere state introdotte nei G5 rispetto ai G4 e sono disponibili anche per i programmi a 32 bit, così come non conta, per gli Athlon64, la maggiore velocità sulle moltiplicazioni intere a 32 bit (che è la stessa in tutte le modalità).

Criceto
18-11-2005, 01:44
I 64 bit, di per sé, NIENTE.

La modalità a 64 bit (ovvero una implementazione dei 64 bit), poichè aggiunge comunque degli opcode, ovvero delle istruzioni nuove, potrebbe aggiungere anche delle funzionalità non disponibili in modalità a 32 bit, come nuove funzioni di calcolo (faccio un esempio banale e generico, senza riferimenti ad alcuna architettura: si potrebbe destinare uno dei nuovi opcode a un'istruzione che esegua la radice quadrata di un numero e aggiungere al processore la logica per calcolarla rapidamente, invece di usare più istruzioni e fare più calcoli - usando anche più registri), oppure anche nuove caratteristiche "interne", come l'aggiunta di nuovi registri.

L'architettura x86-64 (come l'equivalente EM64T di Intel) fa esattamente questo, fermo restando il "problema" di avere puntatori alla memoria più "grossi" per quelle applicazioni che non necessitano di molta memoria (e per le quali gli eventuali cache miss causati da molti puntatori a 64 bit potrebbero essere rilevanti).

Di conseguenza, un'implementazione dei 64 bit che "approfitta" dell'occasione per aggiungere qualosa di utile, come fa x86-64, presentera un comportamento (faccio una schematizzazione MOLTO generica) di questo tipo:

- in alcuni casi il problema "puntatori dopati" produrrà un calo prestazionale;

- in alcuni casi le caratteristiche "interne" e le nuove funzionalità aggiunte insieme alle nuove istruzioni compensano e annullano lo svantaggio precedente (se proprio non riescono a ribaltare la situazione);

- in alcuni casi (ad esempio, semplificando, applicazioni che elaborano dati a 32 bit, ma hanno bisogno di molta memoria, oppure eseguono molte operazioni e pochi accessi alla memoria e, avendo a disposizione più registri, possono ridurre ulteriormente gli accessi alla memoria) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano;

- in alcuni casi (applicazioni che manipolano dati a 64 bit e hanno bisogno di molta memoria e/o di più registri) si hanno dei vantaggi prestazionali - piccoli, medi o grandi che siano.

Ne segue che (diciamo) mediamente o si hanno dei vantaggi, o non si hanno degli svantaggi, e cioè si hanno ancora dei vantaggi, perchè, nel caso in cui avere puntatori più "grossi" non comporta, complessivamente, uno svantaggio, il poter disporre di più memoria ram limita lo swap su hd, aumentando potenzialmente (la memoria "in più" chiaramente bisogna averla) le prestazioni con molti processi in esecuzione (questo potrebbe avvenire anche con le applicazioni per le quali i puntatori "dopati" cosituiscano un problema, poichè all'aumento di cache miss corrisponderebbe potenzialmente una diminuizione di page fault e accessi al disco; in ogni caso, sempre potenzialmente, sono di più i casi possibili in cui i vantaggi superano gli svantaggi).

Se invece si implementano i 64 bit in maniera "basilare", senza alcuna aggiunta/miglioria a contorno, è evidente che si possono avere vantaggi praticamente solo con applicazioni che elaborano massicciamente dati a 64 bit e/o necessitano di grandi quantità di memoria; in tutti gli altri casi, con gli applicativi già ben ottimizzati per l'architettura "di base" a 32 bit, alla quale sono stati semplicemente aggiunti 32 bit di dati in ciascun registro (senza aumentare il numero complessivo di registri - cosa che non è detto sia necessaria, comunque) e agli indirizzi di memoria, senza migliorare niente (che non si manifesti già in modalità a 32 bit), si rischia di avere dei cali prestazionali anche notevoli (e questo è tanto più vero, quanto più piccola è la quantità di ram richiesta dalle applicazioni e quanto minore è il numero di processi in esecuzione contemporanea).

E se il G5 applica il concetto dei 64 bit "nudo e crudo" ricade inevitabilmente in questa categoria. Se non vado errato è proprio per questo motivo che i programmi a 64 bit per OS X hanno un'interfaccia a riga di comando (o comunque non grafica).

Chiaramente tutto questo non ha nulla a che vedere con la definizione di processore a 64 bit; semplicemente ciò che sta a "contorno" e integra l'implementazione dei 64 bit può estenderne o limitarne l'utilità/i vantaggi, ovviamente parlando solo di ciò che si rende disponibile con le nuove istruzioni non disponibili se non "attivando" i 64 bit: in questo contesto non contano le migliorie che, ad esempio, possono essere state introdotte nei G5 rispetto ai G4 e sono disponibili anche per i programmi a 32 bit, così come non conta, per gli Athlon64, la maggiore velocità sulle moltiplicazioni intere a 32 bit (che è la stessa in tutte le modalità).

Tutto ciò è bellissimo ma va al di là del fatto che il G5 e Tiger siano a 64bit o meno. Lo sono. Il G5 in toto, Tiger solo quando ha senso (per i motivi che anche tu hai esposto) a discrezione dello sviluppatore. Direi con una soluzione ottimale allo stato delle cose, visto che un OS puro a 64 bit al momento attuale sarebbe controproducente.

Se poi Intel e AMD hanno approfittato del passaggio a 64 bit anche per dare una "svecchiata" alla loro architettura e renderla più efficiente prescinde la constestazione (come sempre pretestuosa, pedante, errata, noiosa, ecc) di Cdimauro riguardo ai G5 e OS X.

Sarà interessante, a questo punto, vedere come Apple si comporterà con il passaggio ad Intel. Anche perchè non ho capito se questi vantaggi architetturali degli Intel 64bit siano utilizzabili SOLO in modalità 64 bit o meno e se nel caso sono presenti (ad esempio) nel Yonah che è un processore a 32bit.

bjt2
18-11-2005, 09:53
I vantaggi architetturali, ossia il numero di registri in più, sono presenti SOLO in modalità a 64 bit. Non mi pare che siano state introdotte nuove istruzioni, usabili anche in modalità 32 bit, ma potrei sbagliarmi.

bjt2
18-11-2005, 09:57
AMD ha approfittato del fatto di cambiare architettura per supportare 40 bit per la memoria fisica, anzichè 36, ma questo poteva essere fatto indipendentemente dai 64 bit (per intenderci avrebbe potuto farlo anche sugli Atlon XP, ma avrebbe, forse, dovuto cambiare il bus), perchè il numero dei bit di indirizzamento della memoria è memorizzato in un MSR e si deve attivare il PAE (comunque non vi preoccupate: le versioni consumer di Windows supportano solo 32 bit, ossia 4GB di RAM fisica, quindi nessun PAE. Solo le versioni server di windows e Linux, se il kernel è stato appositamente compilato, lo supportano). Non ricordo se la memoria indirizzabile dei P4 rimane a 36 bit, ma poichè l'FSB dovrebbe, forse, essere cambiato (più pin per gli indirizzi), credo che sia rimasto a 36 bit.

cdimauro
18-11-2005, 10:59
I G5 però, a quanto ho letto, hanno la caratteristica di avere una branch prediction estremamente efficiente.
Ma anche 9 stadi di pipeline più, per cui soffrono molto di più i casi di misprediction.
In più gli ultimi modelli hanno una cache di 1MB, quindi in parte recuperano . :mc: :D
Soltanto il problema dell'occupazione di cache: in memoria lo spazio sarà sempre quello e comunque la richiesta di banda (e anche la latenza) verso il chipset e la memoria sarà comunque aumentata.
Cmq sappi che neanche io sono un particolare estimatore dei G5. Secondo me hanno fatto un passo indietro, specie dal punto di vista dell'efficienza, rispetto ai G4. Hanno tolto, infatti, quella che era la caratteristica migliore dei G4, cioè la pipeline estremamente corta (7 stadi, contro 16 dei G5), e questo solo nella speranza di salire velocemente in frequenza (s'è visto infatti) :muro: :rolleyes:
Beh, in frequenza è salito, c'è poco da recriminare: un G4 a 2,7Ghz te lo puoi soltanto sognare.

E' chiaro che il G5 è frutto di compromessi, in base agli obiettivi che IBM s'era posto (con la sua famiglia POWER, di cui il G5 è una "castrazione").
In ogni caso IMHO i 64 bit sono una pura mossa commerciale da parte dei produttori di CPU (AMD in primis). A livello domestino non erano così necessari. In campo scientifico e/o server, magari sì.
I 64 bit di per sé magari sì, come ha anche sottolineato xeal nel suo messaggio. Ma nel contesto dell'architettura x86-64 il discorso è molto diverso, come è stato detto (ci sono diverse migliorie all'architettura e all'ISA).

cdimauro
18-11-2005, 11:04
Mi sa che stai generalizando un pò troppo, è chiaro che in alcuni casi riscrivere il codice a 64bit può avere dei vantaggi anche dal punto di vista prestazionale e forse dei svantaggi in altre situazioni ma se la Apple non ha riscritto il suo OS interamente a 64bit è perché ancora vende cpu che sono a 32bit e poi perché evidentemente le risorse da impiegare sarebbero state troppe in relazione ai vantaggi ottenuti.
Non sto generalizzando e la scelta di Apple è dovuta alle considerazioni che ho già evidenziato.

Comunque puoi sempre leggerti i documenti che ha pubblicato in merito all'uso di codice a 64 bit e verificare tu stesso, leggendo i pro e i contro, se è come dico io o no. ;)
Anche per i PowerPc mi sà che stai esagerando e generalizzando un pò troppo sembra quasi che tu stia parlando dei 68000. In prospettiva forse non sarerebbero più stati competitivi, ma adesso lo sono abbastanza.
Nessuna generalizzazione: è la pura e semplice realtà, ed è il motivo per cui Steve ha deciso per il passaggio agli odiati (prima) x86.

Poi ho detto chiaramente, e lo ripeto, che esistono dei contesti in cui i PPC si dimostrano migliori dal punto di vista computazionale. Ma mediamente la situazione è a vantaggio degli x86. Fatevene una ragione. ;)

cdimauro
18-11-2005, 11:17
E' chiaro che se un'applicazione che gestisce i 64bit eccede i 4GB di memoria, ma poi tu avevi continuato dicendo che per il s.o. e i driver e le applicazioni "normali" il limite era di 4GB totali, e che tutto quello che eccedeva tale limite veniva utilizzato come cache dal sistema operativo, io ti ho fatto notare che nel MacOs X questo non è vero.
E' così invece. Se non c'è nessuna applicazione a 64 bit che fa uso di memoria oltre i 4GB, quella memoria rimane utilizza dal s.o. soltanto come cache.

Questo non vuol dire che se c'è un'applicazione a 64 bit il s.o. non continuerà a fare lo stesso: è chiaro che dipende tutto dalla quantità di memoria richiesta dall'applicazione.

cdimauro
18-11-2005, 11:18
Oltre a sbagliare, sei perseverante nell'errore.
Ti è già stato spiegato 1000 volte come funzionano i 64bit di Tiger.
Non è come dici tu.
E io ti ho già spiegato altrettante 1000 volte che ti sbagli.

Spiegami secondo te come funziona Tiger e vediamo di chiudere la questione una volta per tutte.

cdimauro
18-11-2005, 11:24
Se poi Intel e AMD hanno approfittato del passaggio a 64 bit anche per dare una "svecchiata" alla loro architettura e renderla più efficiente prescinde la constestazione (come sempre pretestuosa, pedante, errata, noiosa, ecc) di Cdimauro riguardo ai G5 e OS X.
Nessuna pretestuosità e pedanteria: queste sono parole da fanboy che non è in grado di accettare la realtà delle cose.

Quanto ai presunti errori, non hai che da farmi vedere dove avrei sbagliato, cortesemente: dire a qualcuno che sbaglia senza fornirne la prova è una cosa che si commenta da sé.

Quanto alla noia, son fatti tuoi.
Sarà interessante, a questo punto, vedere come Apple si comporterà con il passaggio ad Intel. Anche perchè non ho capito se questi vantaggi architetturali degli Intel 64bit siano utilizzabili SOLO in modalità 64 bit o meno e se nel caso sono presenti (ad esempio) nel Yonah che è un processore a 32bit.
Solo col la modalità a 64 bit. Questo vuol dire che se Apple passa prima a x86 (a 32 bit) e poi a x86-64 sarà necessario: cambiare il kernel, cambiare i driver e anche le applicazioni (altrimenti non ha senso il passaggio). Roba non da poco (è la stessa situazione con cui MS s'è trovato con Windows XP x64).

cdimauro
18-11-2005, 11:25
I vantaggi architetturali, ossia il numero di registri in più, sono presenti SOLO in modalità a 64 bit. Non mi pare che siano state introdotte nuove istruzioni, usabili anche in modalità 32 bit, ma potrei sbagliarmi.
Niente istruzioni: solo il flag NX, se non ricordo male.

^TiGeRShArK^
18-11-2005, 12:59
Scusa ma che vuol dire fare girare sempre i g5 a 64bit????

I G5 fanno girare i normali programmi a 32bit alla stessa velocità di quelli scritti a 64bit, tanto che a differenza di altre architetture come dici tu non c'e' nessun vantaggio a fare girare il codice a 64bit se non per avere un indirizzamento maggiore di memoria.

Quindi 32 o 64 bit per i g5 sarebbe la stessa cosa dal punto di vista prestazionale, ecco perché OSX è interamente a 32 bit anche se è possibile comunque fare girare programmi a 64 bit ma senza interfaccia grafica che rimarrebbe a 32bit.

Il passaggio a intel non è semplicemente un problema di processore ma di ottenere un pacchetto completo migliore (chipset) dal punto di vista prezzo/prestazioni e del risparmio energetico, problema molto importante per la Apple non soltanto per il settore dei notebook ma anche per la produzione di macmini e degli iMac.
no le applicazioni a 64 bit girano piu' lente in media sui G5...
a meno di non necessitare di calcoli che usino interi a 64 bit.

EDIT ho visto che ha spiegato tutto correttamente cdimauro...
e il bello è ke ci sono sempre i soliti ke dicono ke spara cazzate... :rolleyes:

jo.li.
18-11-2005, 14:37
Non sto generalizzando e la scelta di Apple è dovuta alle considerazioni che ho già evidenziato.

Comunque puoi sempre leggerti i documenti che ha pubblicato in merito all'uso di codice a 64 bit e verificare tu stesso, leggendo i pro e i contro, se è come dico io o no. ;)

Nessuna generalizzazione: è la pura e semplice realtà, ed è il motivo per cui Steve ha deciso per il passaggio agli odiati (prima) x86.

Poi ho detto chiaramente, e lo ripeto, che esistono dei contesti in cui i PPC si dimostrano migliori dal punto di vista computazionale. Ma mediamente la situazione è a vantaggio degli x86. Fatevene una ragione. ;)

Guarda che sapere se un tal proc. è più veloce del 10-20% ad eseguire un determinato compito e viceversa a me non interessa per niente, chi si fà le pippe mentali per avere un frames in più nei vari giochi mi fà ridere, poi l'ottimizzazione del codice è un'altro fattore importante nel complicare ancora di più la questione, e torno a ripetere che i powerPc non hanno nulla da invidiare agli x86, anzi.

jo.li.
18-11-2005, 14:48
E' così invece. Se non c'è nessuna applicazione a 64 bit che fa uso di memoria oltre i 4GB, quella memoria rimane utilizza dal s.o. soltanto come cache.

Questo non vuol dire che se c'è un'applicazione a 64 bit il s.o. non continuerà a fare lo stesso: è chiaro che dipende tutto dalla quantità di memoria richiesta dall'applicazione.

E' chiaro che se l'utilizzo su di un sistema che ha per es. 8GB di memoria, di meno di 4GB il resto viene utilizzato come cache dal sistema, ma quello che dicevo io era che a prescindere dalle applicazioni a 64bit, io posso lavorare con più applicazioni a 32 bit senza incorrere in problemi di paginazione e quindi rallentamenti per acceder al disco.

jo.li.
18-11-2005, 15:03
no le applicazioni a 64 bit girano piu' lente in media sui G5...
a meno di non necessitare di calcoli che usino interi a 64 bit.

EDIT ho visto che ha spiegato tutto correttamente cdimauro...
e il bello è ke ci sono sempre i soliti ke dicono ke spara cazzate... :rolleyes:

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.

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??

cdimauro
19-11-2005, 05:25
Guarda che sapere se un tal proc. è più veloce del 10-20% ad eseguire un determinato compito e viceversa a me non interessa per niente,
A te no, a tanti altri sì. Incluso un certo Steve Jobs... :D
chi si fà le pippe mentali per avere un frames in più nei vari giochi mi fà ridere,
Indubbiamente, ma stai considerando un caso estremo. Il bisogno di performance non se lo sono inventati i produttori di CPU & affini.
poi l'ottimizzazione del codice è un'altro fattore importante nel complicare ancora di più la questione,
Più esattamente, a cosa ti riferisci?
e torno a ripetere che i powerPc non hanno nulla da invidiare agli x86, anzi.
Sono dei buoni processori e questo nessuno l'ha mai negato, ma torno a ripetere: non sul piano delle prestazioni.

cdimauro
19-11-2005, 05:37
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
19-11-2005, 05:46
cdimauro, scusa l'ignoranza, ma che cosa è il context switching?

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
19-11-2005, 07:11
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. :D

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

jo.li.
19-11-2005, 10:02
A te no, a tanti altri sì. Incluso un certo Steve Jobs... :D

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.
19-11-2005, 10:15
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
19-11-2005, 14:43
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.
19-11-2005, 14:52
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
19-11-2005, 15:28
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.
19-11-2005, 15:59
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
20-11-2005, 11:37
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... :D
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
20-11-2005, 11:43
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
20-11-2005, 11:47
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.
20-11-2005, 22:03
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.
20-11-2005, 22:06
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.
20-11-2005, 22:08
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.
20-11-2005, 22:11
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
21-11-2005, 08:32
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é. :rolleyes:

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... :rolleyes:

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.
21-11-2005, 10:03
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é. :rolleyes:

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... :rolleyes:

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
21-11-2005, 11:31
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
21-11-2005, 12:38
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?

MenageZero
21-11-2005, 13:13
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?

quoto e mi associo alla domanda (molto meglio e più precisamente posta di come avevo fatto io)

tra l'altro pensavo di essere il solo con questo dubbio causa zero esperienza e poca conoscenza teorica su osx e g5 e che jo.li. e cdimauro fossero più o meno implicitamnte pervenuti ad una conclusione comune su questo punto fin dall'inizio della discussione,

ma a quanto pare dagli ultimi post è invece una questione ancora "aperta"... :D

va beh, appena ho tempo assumerò la mia dose quotidiana di google così magari potrò postare anche qualcosa di costruttivo(nel senso che i miei post non lo erano, eh) ... :p

jo.li.
21-11-2005, 14:47
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."

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.


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.

Mi sa che sei tu che devi leggere bene :

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

Nei due test iniziali con Cinebench "test di rendering" e after effect "test di rendering" nella tabella è chiaramente incluso, il primo della lista un modello dual processor Xeon 3,4Ghz. E come puoi notare i vecchi Powermac non erano andati male. I nuovi hanno i dual-core e 2 megabyte di cache per processore, mentre i vecchi G5 singol core ne avevano soltanto 512K. Il top gamma di adesso è un quadricore e i test non sono stati aggiornati, né per includere i nuovi mac né i più recenti intel.

Sul secondo punto è chiaro che adoperando dei linguaggi di sviluppo ci può essere una certa astrazione dall'hardware questo facilita al giorno d'oggi la creazione di programmi per diverse architetture, tu saprai comunque che nonostante Tiger non sia un sistema operativo a 64bit in realtà può comunque fare girare dei programmi con il "motore" a 64bit es. "Mathematica", ed avere la parte della Gui a 32bit, inoltre tutti i programmi che accedono alle librerie matematiche dell'Os siano a 32 o a 64bit, quando girano sui G5 hanno un certo aumento delle prestazioni perché sono state riscritte per sfruttare i 64bit. Quindi senza bisogno di riscrivere il tutto Tiger consente lo stesso di sfruttare molti dei vantaggi di questi processori.
Come saprai visto che quasi l'intero S.O. sfrutta il concetto di bundle è possibile creare dei singoli programmi che possono girare su architetture diverse sia a 32bit che a 64bit, intel o PowerPc, etc.. e molto probabilmente questa sarà la strada che intraprenderà la Apple quando userà gli x-86 a 64bit.

Per quanto riguarda l'ultimo punto, è chiaro che sarà il sistema a gestire tutto il meccanismo, ma questo ti consente comunque di fare girare più applicazioni oltre il limite dei 4GB. Leggi per esempio cosa c'e' scritto sempre nella pagina del link che ho inserito sopra quando nel primo test con photoshop dicono che nonostante avessero allocato circa 3,5GB al programma, quest'ultimo durante il test avesse finito per occupare circa 6,5 GB di ram fisica.

"We weren't able to test the Dual Xeon and Single Core Pentium 4 with the next set of apps, since we no longer have them. Adobe Photoshop CS2, though not a 64 bit app, does make use of up to 4GB of RAM for memory cache under Windows 64. Under Mac OS X "Tiger," you can dedicate up to 3.5GB but we've observed the OS setting aside up to 6.5GB when nothing else is running."

cdimauro
22-11-2005, 07:42
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?
I PowerPC a 32 bit possono indirizzare fino a 2^32 (quindi 4GB) di memoria fisica.
I PPC a 64 bit (come il G5) possono indirizzare fino a 2^62 (fino a 4EB) di memoria fisica.
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?
Facciamo un po' di chiarezza. :)

I G5 CON UN S.O. A 64 BIT possono anche mappare le pagine dei 4GB di memoria virtuale di un processo a 32 bit in QUALUNQUE porzione di memoria fisica, quindi anche oltre i 4GB di "memoria bassa".
Quindi in teoria ogni processo a 32 bit potrebbe risiedere nei suoi 4GB di memoria fisica (come avviene con Windows XP x64).

Il problema è Tiger, che non è un s.o. "interamente a 64 bit" e che, quindi, obbliga tutti i processi a 32 bit a risiedere nei 4GB di "memoria bassa", lasciando tutta la memoria oltre questi 4GB alle applicazioni a 64 bit e alla cache del disco.
D'altra parte oltre al kernel servirebbero anche i driver a 64 bit.
Tiger è una soluzione di compromesso fra compatibilità col passato e parziale supporto al futuro.

cdimauro
22-11-2005, 08:01
Mi sa che sei tu che devi leggere bene :

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

Nei due test iniziali con Cinebench "test di rendering" e after effect "test di rendering" nella tabella è chiaramente incluso, il primo della lista un modello dual processor Xeon 3,4Ghz.
Sì, ma ci sono soltanto quelli. Infatti il tema dell'articolo (purtroppo) era questo:

"Dual Core Pentium versus Dual CPU G5"

Che è confermato anche dalle configurazioni di test che sono riportate in coda all'articolo.

I due test col lo Xeon sono stati inclusi soltanto perché erano disponibili, come puoi leggere quando ne parlano, altrimenti non ci sarebbero nemmeno.
E come puoi notare i vecchi Powermac non erano andati male.
Nessuno l'ha mai negato.
I nuovi hanno i dual-core e 2 megabyte di cache per processore, mentre i vecchi G5 singol core ne avevano soltanto 512K.
2MB sono in tutto: ogni core ha 1MB di cache L2.
Il top gamma di adesso è un quadricore e i test non sono stati aggiornati, né per includere i nuovi mac né i più recenti intel.
E avrebbe senso farlo invece. Anzi, da rifare completamente i test, confrontando i sistemi dual core coi dual core e quelli SMP con gli SMP. Quello che è stato fatto nell'articolo ha poco senso, IMHO.
Sul secondo punto è chiaro che adoperando dei linguaggi di sviluppo ci può essere una certa astrazione dall'hardware questo facilita al giorno d'oggi la creazione di programmi per diverse architetture, tu saprai comunque che nonostante Tiger non sia un sistema operativo a 64bit in realtà può comunque fare girare dei programmi con il "motore" a 64bit es. "Mathematica", ed avere la parte della Gui a 32bit,
Sì, infatti.
inoltre tutti i programmi che accedono alle librerie matematiche dell'Os siano a 32 o a 64bit, quando girano sui G5 hanno un certo aumento delle prestazioni perché sono state riscritte per sfruttare i 64bit. Quindi senza bisogno di riscrivere il tutto Tiger consente lo stesso di sfruttare molti dei vantaggi di questi processori.
I vantaggi ci sono, ma sono limitati. Tutt'altra cosa è invece avere un'applicazione che manipola direttamente i dati a 64 bit, senza richiamare le librerie di sistema.
Come saprai visto che quasi l'intero S.O. sfrutta il concetto di bundle è possibile creare dei singoli programmi che possono girare su architetture diverse sia a 32bit che a 64bit, intel o PowerPc, etc.. e molto probabilmente questa sarà la strada che intraprenderà la Apple quando userà gli x-86 a 64bit.
Già, ma non sarà bello avere dei FAT binary contenenti codice PowerPC, x86 e x86-64.
Per quanto riguarda l'ultimo punto, è chiaro che sarà il sistema a gestire tutto il meccanismo, ma questo ti consente comunque di fare girare più applicazioni oltre il limite dei 4GB. Leggi per esempio cosa c'e' scritto sempre nella pagina del link che ho inserito sopra quando nel primo test con photoshop dicono che nonostante avessero allocato circa 3,5GB al programma, quest'ultimo durante il test avesse finito per occupare circa 6,5 GB di ram fisica.

"We weren't able to test the Dual Xeon and Single Core Pentium 4 with the next set of apps, since we no longer have them. Adobe Photoshop CS2, though not a 64 bit app, does make use of up to 4GB of RAM for memory cache under Windows 64. Under Mac OS X "Tiger," you can dedicate up to 3.5GB but we've observed the OS setting aside up to 6.5GB when nothing else is running."
Letto, ma vedi anche il mio messaggio precedente. Il fatto di avere occupato quella memoria non vuol dire che l'applicazione abbia allocato memoria oltre i 4GB: è stato il sistema a usarla per minimizzare gli accessi al disco, ma niente di più.

Il limite rimane sempre di 4GB per tutte le applicazioni a 32 bit, kernel e driver inclusi.

Al contrario, come si vede XP x64 permette di assegnare ben 4GB di memoria all'applicazione a 32 bit, e può fare lo stesso con ogni applicazione a 32 bit.

jo.li.
22-11-2005, 10:13
Sì, ma ci sono soltanto quelli. Infatti il tema dell'articolo (purtroppo) era questo:

"Dual Core Pentium versus Dual CPU G5"

Che è confermato anche dalle configurazioni di test che sono riportate in coda all'articolo.

I due test col lo Xeon sono stati inclusi soltanto perché erano disponibili, come puoi leggere quando ne parlano, altrimenti non ci sarebbero nemmeno.

Nessuno l'ha mai negato.

Bene. Come vedi in quei due test i PowerMac dual-processors a 2,7Ghz sono stati più veloci dello Xeon dual-processors a 3,4 Ghz da un minimo del 9 % fino al 45%.


2MB sono in tutto: ogni core ha 1MB di cache L2.

Si, esattamente.


E avrebbe senso farlo invece. Anzi, da rifare completamente i test, confrontando i sistemi dual core coi dual core e quelli SMP con gli SMP. Quello che è stato fatto nell'articolo ha poco senso, IMHO.

Si sarebbe interessante, specialmente facendo un confronto dei prezzi, cioè quanto verrebbe a costare un dual-processors Xeon a 3,8GHz in confronto al quadricore a 2,5 Ghz della Apple, in cui però la controparte sia anch'essa un'azienda con una marca conosciuta e non un'assemblato.



I vantaggi ci sono, ma sono limitati. Tutt'altra cosa è invece avere un'applicazione che manipola direttamente i dati a 64 bit, senza richiamare le librerie di sistema.

Un'applicazione che manipola direttamente i dati a 64bit è perfettamente fattibile:

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

quella della libreria di sistema che ti ho riportato (librerie matematiche) è per farti notare che bisognerà proprio riconvertire tutte le librerie di sistema a 64bit mentre la stragrande maggioranza è ancora a 32bit.


Già, ma non sarà bello avere dei FAT binary contenenti codice PowerPC, x86 e x86-64.

E perché di grazia??, già adesso quasi tutti i programmi dei Tool di sviluppo (XCode 2.2), sono fat-binary contenenendo sia il codice per i PowerPc che per gli intel. E sai che le dimensioni sono aumentate pochissimo.


Letto, ma vedi anche il mio messaggio precedente. Il fatto di avere occupato quella memoria non vuol dire che l'applicazione abbia allocato memoria oltre i 4GB: è stato il sistema a usarla per minimizzare gli accessi al disco, ma niente di più.

Il limite rimane sempre di 4GB per tutte le applicazioni a 32 bit, kernel e driver inclusi.

Al contrario, come si vede XP x64 permette di assegnare ben 4GB di memoria all'applicazione a 32 bit, e può fare lo stesso con ogni applicazione a 32 bit.

E' esattamente quello che dicono nel sito riguardo a Photoshop a 32bit su windows 64bit e cioè che il sistema arriva ad occupare per quella applicazione fino a 4Gb di memoria proprio per una questione di memory cache.

cdimauro
22-11-2005, 10:42
Bene. Come vedi in quei due test i PowerMac dual-processors a 2,7Ghz sono stati più veloci dello Xeon dual-processors a 3,4 Ghz da un minimo del 9 % fino al 45%.
Bisogna vedere che modello di Xeon era: non ce n'è soltanto uno.
Si sarebbe interessante, specialmente facendo un confronto dei prezzi, cioè quanto verrebbe a costare un dual-processors Xeon a 3,8GHz in confronto al quadricore a 2,5 Ghz della Apple, in cui però la controparte sia anch'essa un'azienda con una marca conosciuta e non un'assemblato.
Non abbiamo fatto discorso di prezzi all'inizio: si stava misurando le prestazioni dei processori (quindi nemmeno l'intero sistema).

Inoltre non vedo perché mettere da parte gli assemblati: il fatto che non esistano per il mercato Mac non dev'essere una pregiudiziale. Per i PC ci sono, per cui ha senso fare questo tipo di confronti.
Se devo comprare un PC io scelgo la soluzione A ME più congeniale: sia essa una soluzione di marca o un assemblato.
Un'applicazione che manipola direttamente i dati a 64bit è perfettamente fattibile:

http://developer.apple.com/macosx/64bit.html
Guarda che non ho mai detto che fosse impossibile. Al contrario: esprimevo la mia preferenza sulle applicazioni che manipolano direttamente i dati a 64 bit, senza passare dal collo di bottiglia rappresentato da una chiamata a libreria.
quella della libreria di sistema che ti ho riportato (librerie matematiche) è per farti notare che bisognerà proprio riconvertire tutte le librerie di sistema a 64bit mentre la stragrande maggioranza è ancora a 32bit.
Allora vedi che ha senso pensare a un porting del s.o. a 64 bit ANCHE nell'ottica di un passaggio a x86-64? ;)
E perché di grazia??, già adesso quasi tutti i programmi dei Tool di sviluppo (XCode 2.2), sono fat-binary contenenendo sia il codice per i PowerPc che per gli intel. E sai che le dimensioni sono aumentate pochissimo.
Mi sembra molto strano. Hai qualche link che fornisca un esempio che mostri la differenza di dimensioni fra un'applicazione presente solamente in formato PPC e la stessa identica, ma in entrambi i formati?

Il codice è completamente diverso e occupa non poco spazio: le differenze NON possono essere minime. A meno che nei fat binary non siano presenti soltanto ALCUNE parti di codice x86.

L'unica parte in comune che potrebbe essere in condivisione è quella relativa ai dati e alle sezioni BSS. Ad esempio, se integro un'immagine nell'applicazione, questa può essere usata sia dal codice PPC sia da quello x86, senza per questo richiederne una duplicazione.
E' esattamente quello che dicono nel sito riguardo a Photoshop a 32bit su windows 64bit e cioè che il sistema arriva ad occupare per quella applicazione fino a 4Gb di memoria proprio per una questione di memory cache.
Occhio che Photoshop ha un suo sistema di caching, che puoi anche impostare dalle preferenze dell'applicazione stessa. Da questo punto di vista con XP x64 può arrivare a occupare fino a 4GB di memoria fisica assegnata direttamente a Photoshop, mentre con Tiger il massimo è di 3,5GB.

jo.li.
22-11-2005, 18:00
Bisogna vedere che modello di Xeon era: non ce n'è soltanto uno.

Credo fosse un dell.


Non abbiamo fatto discorso di prezzi all'inizio: si stava misurando le prestazioni dei processori (quindi nemmeno l'intero sistema).

Inoltre non vedo perché mettere da parte gli assemblati: il fatto che non esistano per il mercato Mac non dev'essere una pregiudiziale. Per i PC ci sono, per cui ha senso fare questo tipo di confronti.
Se devo comprare un PC io scelgo la soluzione A ME più congeniale: sia essa una soluzione di marca o un assemblato.

Appunto la soluzione a "te" più congeniale, anche io quando ho comprato un pc l'ho assemblato pezzo per pezzo, ma perché ne avevo le capacità, la gente comune non sarebbe mai in grado di farlo senza un "aiutino". Ma mentre nel settore dei Pc questo lo puoi fare e installarci windows, nel mercato dei Mac questo non è possibile e spero che non lo sia mai, non perché non ami la concorrenza tutt'altro ma perché questo vorrebbe dire la fine della Apple, che in definitiva ricava circa il 90% del suo fatturato dalla vendita dell'hardware e poi perché OS X è per me una valida alternativa a Windows anzi con Tiger è diventato nettamente superiore e quindi un possibile concorrente. Quindi il Mac OS X per gli Intel non dovrebbe girare su un Pc di altre marche, né tanto meno su un assemblato, perciò non potrei assemblarmi un mac e se volessi utilizzare questo sistema dovrei per forza acquistare un Apple. Poi i mac, guarda agli iMac ai Powermac ai PowerBook, etc.. sono costruiti con dei materiali di qualità e questo costa, per non parlare dell'attuale dotazione di software, che comprende anche i "developer code". E visto che un assemblato può essere sia supereconomicissimo o addirittura più caro di un Pc di marca, perché la Apple dovrebbe confrontarsi con il segmento di mercato più basso?? Non sarebbe più la Apple.


Guarda che non ho mai detto che fosse impossibile. Al contrario: esprimevo la mia preferenza sulle applicazioni che manipolano direttamente i dati a 64 bit, senza passare dal collo di bottiglia rappresentato da una chiamata a libreria.

Allora vedi che ha senso pensare a un porting del s.o. a 64 bit ANCHE nell'ottica di un passaggio a x86-64? ;)

Ma infatti chi ti dice che non lo stiano già facendo ma soltanto per gli x86-64. Una volta terminato lo sviluppo di Tiger a giugno, la Apple ha già cominciando con la prossima major release la 10.5 (Leopard), di cui si dice che supporterà proprio i proc. a 64bit della Intel e dovrebbe uscire all'inizio del 2007 e "vedersela" con Vista.


Mi sembra molto strano. Hai qualche link che fornisca un esempio che mostri la differenza di dimensioni fra un'applicazione presente solamente in formato PPC e la stessa identica, ma in entrambi i formati?

Il codice è completamente diverso e occupa non poco spazio: le differenze NON possono essere minime. A meno che nei fat binary non siano presenti soltanto ALCUNE parti di codice x86.

L'unica parte in comune che potrebbe essere in condivisione è quella relativa ai dati e alle sezioni BSS. Ad esempio, se integro un'immagine nell'applicazione, questa può essere usata sia dal codice PPC sia da quello x86, senza per questo richiederne una duplicazione.

Guarda in questo momento ho sottomano alcuni mac, uno con il "vecchio" tool di sviluppo (xcode 2) e l'altro l'ultima versione (xcode 2.2) che è fat-binary e tra le varie applicazioni abbiamo che "alcuni esempi":

Descrizione powerPc fat-binary
Core Image Fun House 2,8MB 3MB
OpenGL Driver Monitor 480Kb 628Kb
OpenGl shader Builder 2,1MB 3,3MB
Pixie 148Kb 208Kb
Interface Builder 7,3MB 9,3MB
Xcode 51,1MB 45,8MB

In alcuni casi c'e' un certo aumento (al massimo 30%), in un caso e cioè con l'applicazione più importante e cioè Xcode c'e' stata addirittura un diminuzione.
Sembra che dipenda dal peso dell'eseguibile rispetto al resto delle risorse di un programma, mentre per esempio in "core image fun house" questo è di 156Kb e diventa in fat 348Kb, e visto che è relativamente piccolo rispetto al resto delle risorse (picture,text, etc..) la differenza è minima, mentre in "OpenGl shader builder" questo pesa 1,1MB e passa a circa 2MB e dato che relativamente al resto è maggiore la dimensione, la differenza è più grande.

xeal
22-11-2005, 23:50
In alcuni casi c'e' un certo aumento (al massimo 30%),

In realtà, dai dati che hai postato l'aumento risulta ben maggiore del 30% (nel caso "peggiore" ): OpenGl shader Builder aumenta del 57% (Fun House del 7%, OpenGL Driver Monitor del 30.8%, Pixie del 40%, Interface Builder del 27%).

in un caso e cioè con l'applicazione più importante e cioè Xcode c'e' stata addirittura un diminuzione.

Questo è sorprendente: probabilmente non hanno solo aggiunto il codice per x86, ma anno anche modificato qualcosa (ad esempio, potrebbero aver ottimizzato meglio alcune parti del codice, ottenendone un binario più snello, e/o potrebbero aver eliminato alcune risorse non indispensabili), ragion per cui anche le altre stime lasciano il tempo che trovano, in mancanza di dati sui sorgenti. Avendoli a disposizione, insieme alle risorse, e ricompilando tutto in entrambe le "modalità" (ovvero con un compilatore in grado sia di produrre i soli binari per PowerPC, sia i fat binary) ci si potrebbe fare un'idea più precisa.

Sembra che dipenda dal peso dell'eseguibile rispetto al resto delle risorse di un programma, mentre per esempio in "core image fun house" questo è di 156Kb e diventa in fat 348Kb, e visto che è relativamente piccolo rispetto al resto delle risorse (picture,text, etc..) la differenza è minima, mentre in "OpenGl shader builder" questo pesa 1,1MB e passa a circa 2MB e dato che relativamente al resto è maggiore la dimensione, la differenza è più grande.

Qui rientriamo nel discorso di Cesare: la dimensione dell'eseguibile "puro" è circa il doppio in entrambi i casi (il 123% in più nel caso di fun house, l'82% in più per lo shader builder - oggi sono pignolo :p ), però tutto il resto (risorse, dati "statici") resta invariato e varia di conseguenza il peso del codice rispetto all'intero file. Nel caso di un programma che non si porti dietro molte risorse (in particolare all'interno dell'eseguibile), compilando per ottenere dei fat binary possiamo aspettarci un aumento notevole in termini di spazio su disco (come aumento percentuale, s'intende, qui in alcuni casi stiamo parlando di KB); poi magari le risorse "esterne" vanno a riequilibrare e ridurre il peso del codice rispetto al tutto (ad esempio, in un videogioco - spero che fek, se legge, non mi caxxii per eventuali imprecisioni :p - potremmo pensare di avere il codice del gioco raddoppiato, ma le mappe, i file con le impostazioni, i salvataggi, le caratteristice dei personaggi, ecc. a compensare in qualche misura). Bye ;)

cdimauro
23-11-2005, 08:45
Credo fosse un dell.
Dici poco. Avrebbero dovuto quanto meno mettere un link per recuperare la descrizione della macchina in oggetto. Comunque lasciamo perdere: ormai li conosco bene...
Appunto la soluzione a "te" più congeniale, anche io quando ho comprato un pc l'ho assemblato pezzo per pezzo, ma perché ne avevo le capacità, la gente comune non sarebbe mai in grado di farlo senza un "aiutino".
Ci sono anche tanti negozi che ti assemblano il PC di cui hai scelto tutti i pezzi. ;)
Ma mentre nel settore dei Pc questo lo puoi fare e installarci windows, nel mercato dei Mac questo non è possibile e spero che non lo sia mai, non perché non ami la concorrenza tutt'altro ma perché questo vorrebbe dire la fine della Apple, che in definitiva ricava circa il 90% del suo fatturato dalla vendita dell'hardware
Esattamente. Ed è lo stesso motivo per cui, al contrario, non comprerò mai un Mac Apple: voglio essere io a decidere come spendere i miei soldi.
e poi perché OS X è per me una valida alternativa a Windows anzi con Tiger è diventato nettamente superiore e quindi un possibile concorrente.
Se parli di facilità di utilizzo sì, è migliore ma Windows non è certo roba da trogloditi. :p

Comunque Tiger non è un concorrente di Windows, visto che, come hai detto, il mercato dell'hardware Mac è in mano a Apple. Per Windows il mercato è quello dei PC, di (più o meno) tutti e non soltanto quelli di una certa marca e/o con un certo hardware.
Quindi il Mac OS X per gli Intel non dovrebbe girare su un Pc di altre marche, né tanto meno su un assemblato, perciò non potrei assemblarmi un mac e se volessi utilizzare questo sistema dovrei per forza acquistare un Apple. Poi i mac, guarda agli iMac ai Powermac ai PowerBook, etc.. sono costruiti con dei materiali di qualità e questo costa,
E se a me non importa la qualità dei prodotti? E se voglio decidere di avere, ad esempio, un hd di qualità mentre per la ram mi basta una "di quarta mano"?

Personalmente non tengo all'estetica (se vedessi i miei PC rimarresti shockato :D), ma voglio essere libero di decidere cosa comprare e come spendere i miei soldi.
per non parlare dell'attuale dotazione di software, che comprende anche i "developer code".
Il discorso del software in dotazione non regge: MS non è libera di infilare in Windows ciò che vuole (nemmeno Windows Media Player, per farti un esempio, e che è gratuito e liberamente scaricabile dal suo sito), come invece fanno TUTTI gli altri, Apple inclusa.
E visto che un assemblato può essere sia supereconomicissimo o addirittura più caro di un Pc di marca, perché la Apple dovrebbe confrontarsi con il segmento di mercato più basso?? Non sarebbe più la Apple.
E se a me di Apple non frega una mazza per quanto riguarda l'hardware, ma m'interessa invece soltanto il software? ;)
Ma infatti chi ti dice che non lo stiano già facendo ma soltanto per gli x86-64. Una volta terminato lo sviluppo di Tiger a giugno, la Apple ha già cominciando con la prossima major release la 10.5 (Leopard), di cui si dice che supporterà proprio i proc. a 64bit della Intel e dovrebbe uscire all'inizio del 2007 e "vedersela" con Vista.
Vedi sopra: non se la vedrà con Vista semplicemente perché non è un suo concorrente. ;)
Guarda in questo momento ho sottomano alcuni mac, uno con il "vecchio" tool di sviluppo (xcode 2) e l'altro l'ultima versione (xcode 2.2) che è fat-binary e tra le varie applicazioni abbiamo che "alcuni esempi":
Su questo ha già risposto esaustivamente xeal. :p

jo.li.
23-11-2005, 09:39
Dici poco. Avrebbero dovuto quanto meno mettere un link per recuperare la descrizione della macchina in oggetto. Comunque lasciamo perdere: ormai li conosco bene...

Ci sono anche tanti negozi che ti assemblano il PC di cui hai scelto tutti i pezzi. ;)

Esattamente. Ed è lo stesso motivo per cui, al contrario, non comprerò mai un Mac Apple: voglio essere io a decidere come spendere i miei soldi.

Se parli di facilità di utilizzo sì, è migliore ma Windows non è certo roba da trogloditi. :p

Comunque Tiger non è un concorrente di Windows, visto che, come hai detto, il mercato dell'hardware Mac è in mano a Apple. Per Windows il mercato è quello dei PC, di (più o meno) tutti e non soltanto quelli di una certa marca e/o con un certo hardware.

E se a me non importa la qualità dei prodotti? E se voglio decidere di avere, ad esempio, un hd di qualità mentre per la ram mi basta una "di quarta mano"?

Personalmente non tengo all'estetica (se vedessi i miei PC rimarresti shockato :D), ma voglio essere libero di decidere cosa comprare e come spendere i miei soldi.

Il discorso del software in dotazione non regge: MS non è libera di infilare in Windows ciò che vuole (nemmeno Windows Media Player, per farti un esempio, e che è gratuito e liberamente scaricabile dal suo sito), come invece fanno TUTTI gli altri, Apple inclusa.

E se a me di Apple non frega una mazza per quanto riguarda l'hardware, ma m'interessa invece soltanto il software? ;)

Vedi sopra: non se la vedrà con Vista semplicemente perché non è un suo concorrente. ;)

Su questo ha già risposto esaustivamente xeal. :p

Ma infatti io ho detto che le possibilità di scelta sono molte, chi non si cura della qualità può farlo benissimo, io invece quando ho assemblato il mio Pc ho finito per spendere più di un Pc di marca, ma perché non c'era nessuna offerta che mi soddisfasse, adesso sarei sicuramente meno pretenzioso.
I mac sono sempre stati per me tutta un'altra cosa, io li considero quasi delle "opere d'arte", e visto che odio i monopoli, e c'è un'altra offerta valida io patteggio per quella, sarei felicissimo se linux avesse almeno il 50% del mercato consumer oppure se il Mac OS X arrivase al 30% (cazzo che sogni!), sicuramente la situazione sarebbe migliore.

jo.li.
23-11-2005, 09:45
Qui rientriamo nel discorso di Cesare: la dimensione dell'eseguibile "puro" è circa il doppio in entrambi i casi (il 123% in più nel caso di fun house, l'82% in più per lo shader builder - oggi sono pignolo :p ), però tutto il resto (risorse, dati "statici") resta invariato e varia di conseguenza il peso del codice rispetto all'intero file. Nel caso di un programma che non si porti dietro molte risorse (in particolare all'interno dell'eseguibile), compilando per ottenere dei fat binary possiamo aspettarci un aumento notevole in termini di spazio su disco (come aumento percentuale, s'intende, qui in alcuni casi stiamo parlando di KB); poi magari le risorse "esterne" vanno a riequilibrare e ridurre il peso del codice rispetto al tutto (ad esempio, in un videogioco - spero che fek, se legge, non mi caxxii per eventuali imprecisioni :p - potremmo pensare di avere il codice del gioco raddoppiato, ma le mappe, i file con le impostazioni, i salvataggi, le caratteristice dei personaggi, ecc. a compensare in qualche misura). Bye ;)

Si in effetti come ho già detto dipende dalla grandezza relativa dell'eseguibile rispetto al resto delle risorse di un programma, al limite se esistesse una applicazione in cui l'eseguibile fosse il 99% del programma quest'ultimo raddoppierebbe le dimensioni. Anche per i giochi, di solito l'eseguibile è una parte molto piccola rispetto al resto delle risorse (Mappe, texture, audio, video, testo, etc..), quindi avere un gioco fat-binary non comporterebbe un aumento considerevole delle dimensioni del gioco, anzi.

cdimauro
23-11-2005, 09:48
Ma bisogna anche metterci i mezzi, no?
Per OS X il problema è dato dall'ostinazione di Apple a venderlo per il suo solo hardware.
Per Linux la causa è invece la sindrome da fork che finora non ha permesso di mettere assieme una distribuzione che faccia seriamente concorrenza a Windows.

jiadin
23-11-2005, 10:23
Ma bisogna anche metterci i mezzi, no?
Per OS X il problema è dato dall'ostinazione di Apple a venderlo per il suo solo hardware.
Per Linux la causa è invece la sindrome da fork che finora non ha permesso di mettere assieme una distribuzione che faccia seriamente concorrenza a Windows.
apple guadagna con l'hardware...e poi lo dico sinceramente... se apple si aprisse non so se acquisterei la copia (chi vuole intendere intenda) e non conosco nessuno che lo farebbe... che poi è la tecnica di win, cd a protezione zero, la cui unica menata è (forse) quella di non poter fare gli aggiornamenti... il maggior guadagno viene dal obbligare i produttori a inserirlo dentro(e a farlo pagare) oltre che dagli utenti professionali che sono costretti a pagare le licenze in quanto subiscono maggiori controlli, poichè apple non so quanto mercato professionale acquisirebbe, ci sarebbero da aspettare anni e anni e dal futuro incerto..
e poi, apple è bella anche abbinata all'hardware... sinceramente non sarei troppo contento di un'espansione eccessiva, spero continui così ma piano piano.

linux, beh si sa.. p.s cosa intendi per fork?

MenageZero
23-11-2005, 14:22
apple guadagna con l'hardware...e poi lo dico sinceramente... se apple si aprisse non so se acquisterei la copia (chi vuole intendere intenda) e non conosco nessuno che lo farebbe... che poi è la tecnica di win, cd a protezione zero, la cui unica menata è (forse) quella di non poter fare gli aggiornamenti... il maggior guadagno viene dal obbligare i produttori a inserirlo dentro(e a farlo pagare) oltre che dagli utenti professionali che sono costretti a pagare le licenze in quanto subiscono maggiori controlli...

linux, beh si sa.. p.s cosa intendi per fork?

ad esempio xp non è affatto a protezione "zero", ci sarebbe da "attivarlo" se no dopo un certo tempo smette di funzionare... il fatto è che finché le protezioni sono solamente a livello sw, ci sono sempre buone possibilità con un po' di reverse engineering di arrivare ad un "crack"...
(poi c'è anche la versione "corporate" che non necessita di attivazione per non complicare la vita ad una azioenda o ente che magari acquista un numero di licenze dell'ordine di 10, 10^2, o addirittura 10^3; la cosa facilita ulteriormente la diffusione di copie non licenziate, ma in se ha anche senso per quanto detto, tanto più che ms certo se lo "immaginava" che qualcuno avrebbe cmq "crackato" xp e che prima o poi chi volesse avrebbe potuto averlo gratis, anche senza vers. "corporate")

c'è anche da considerare che una situazione come quella italiana non è detto che rifletta in toto quella mondiale, prob. ci sono mercati importanti dove il sw "piratato" non è il default... (ad es USA?)

Poi prendi ad esempio i videogiochi: almeno per pc, quale se ti "impegni", non riesci, una volta in possesso di una copia non originale, a giocarci ? e sono un tipo di prodotto in cui difficilmente ci si può vedere un vantaggio startegico a diffonderli anche senza avere i $ della licenza in cambio.

Detto questo può benissimo darsi che in passato o anche tutt'ora, in teoria, ms abbia "gradito" o favorito una certa "pirateria" per i vantaggi startegici della diffusione globale e capillare del suo os (forse proprio perché in certi paesi il fenomeno rimane comunque minoritario, anche nel privato e quindi un certo livello di entrate rimane garantito o forse perché il grosso dei guadagni è sempre stato preventivato su licenze oem ed utenza "pro"), questo non posso saperlo o comunque non ho info "abbastanza sicure" per poter prendere una posizione netta e convinta su questo.

Poi i produttori di pc "chiavi in mano" più che "obbligati" a metter win secondo me si sentono ben felici di poterlo mettere(con una licenza "oem" che incide molto meno sul prezzo totale di quanto farebbe una "retail") dato che probabilmente la grande maggioranza di chi compra un pc pronto all'uso gradisce che esso si effetivamente tale (e quindi contenga insatallato almeno un s.o. abbastanza "friendly");

e poi win (senza entrare nel merito se la cosa sia "giusta" o sbagliata", "positiva" o "negativa") è lo standard di fatto per l'utenza desktop home/office (su x86) di adesso e degli ultimi anni,
come "default" che ci dovrebbero mettere:
(osx non si può perché è solo per chi compra Apple)
linux, *bsd, solaris, qualche unix proprietario ?
os/2, be-os (ammesso che siano ancora in vendita) ?
Sinceramente, ma è solo una opinione personale ovviamente, e non viene certo da antipatia per linux & sistemi open vari (tutt'altro), credo che allo stato attuale un utente "medio", anche completamente "digiuno" di pc, che si facesse una esperienza parallela su uno dei s.o. citati e su win, sceglierebbe win...

Certo anche secondio me sarebbe bello e "comodo" avere sempre l'opzione pc(solo hw) o pc+s.o.(+eventuale altro sw), ma che oltre a questo si speri di avere qualcos'altro invece di win preinstallato per il mercato di massa in grandi % per il momento almeno è secondo me solo utopia...

riugardo al "fork" su linux, credo che cdimauro intendesse la tendenza a dipserdere grande potenziale umano e lavoro su diversi progetti con obbiettivi analoghi se non del tutto identici, cosa che purtroppo secondo me avviene (e forse è l'apsetto peggiore perché lascia presupporre una certa persistenza di questo status per il futuro) in genere come scelta programatica del tutto volontaria e convinta...

es: forse se negli anni si fossero avuti sforzi organizzati e "unificati" da parte della "comunità" di dev che anno lavorato per dare la "grafica" a gnu/linux (e quindi sui relativi layer e componeti sw) forse oggi, invece che diverse implementazioni open di x11 e tanti desktop environment di cui i due maggiori includono anche tante apps end-user di produttività (anche suite office con la k, fortuna che la filosofia originaria di unix era diversi tool "piccoli" per ogni specifico compito vs sw grandi per "tutto"!), tutte cose ottime in se eh, forse oggi i linux avrebbe un sottosistema grafico più avanzato di un tiger/leopard o di un imminente vista (intendo le relative tecnologie sw, non l'estetica), e magari anche delle librerie clone, come api, delle dx(che ormai sono quasi lo standard per lo sviluppo dei giochi, almeno come % di utilizzo rispetto a ogl, e sono anch più dev-friendly a detta di chi ci lavora nello sviluppo giochi...) così da essere una potenziale pittaforma alternativa anche per lo sviluppo dei giochi, un mercato che rende e "traina" parecchio il settore home ...

*azz*. come sono andato OT... scusate... se i mod vorranno cancellare il post sappiano che capisco perfettamente

MenageZero
23-11-2005, 14:22
doppio post... non è giornata... scusate

jiadin
23-11-2005, 14:43
decisamente esaustivo..! :D
per protezione zero intendo che lo copi come niente con un masterizzatore di 5 anni fa e pc da museo, per l'attivazione ci sono, come hai detto tu, le versioni corporate..! ;)
con qualche fregatura prendi pure gli aggiornamenti.. e appunto, confermo che ci guadagnano sulle versioni oem e quelle per usi professionali e quindi soggetti a più controlli...

apple non lo darebbe oem, se non sui suoi hw o al max a scelta (ma penso tutti prenderebbero win originale e poi per provare una copia piratata di mac os..)
per gli utilizzatori professionali, prima che pensino di adottare mac ne passerebbe di tempo, visto che lo standard, come tu stesso hai sottolineato è win e non mac.. penso a uffici, pubblica amministrazine ecc ecc

i videogiochi sono infatti mooolto ma moolto più difficili da copiare, devi avere programmi specifici, masterizzatori che supportano tipi di scrittura al passo coi tempi, sicuramente un exe modificato(per non usare brutte parole! :D) ameno di copie 1:1 (da fare e masterizzare sempre con prgrm specifici!)
senza contare la starforce che pare per ora essere molto difficile da copiare, se non con metodi scomodi o molto macchinosi in parecchi casi
win invece te lo copia anche pincopallo con software caxuti..

comunque l'attivazione è stata inserita appunto con l'ultimo (winxp), anche perchè il mercato oramai era al massimo possibile(leggasi tutti con win)e quindi cercano di aumentare i profitti(senza troppa convinzione sec me comunque)
tanto la maggior parte della gente prende il pc al supermercato o in negozi con assemblati o di marca, la cui licenza si paga sempre e comunque , anche sui portatili...

quindi a meno che la apple non faccia così, una sua entrata su tale tipo di mercato potrebbe diventare molto rischiosa, in quanto ad ora non avrebbe forza contrattuale tale da imporre un utilizzo di mac os...
l'unica cosa potrebbe licenziare(dare in licenza) mac os a produttori specifici(dell?) per entrare nella fascia bassa, anche se già degli ibook...
confermo comunque i miei dubbi sun una manovra del genere, che potrebbe rivoltarglisi contro...
senza contare il fatto che parte della stabilitò di mac os è dovuta al parco hardware ristretto, cosa che non potrebbe più esserci se venisse "aperto"..
e in ultimo, la possibilità a smanettoni di creare virus aumentare, per oraè difficle che uno si compri un mac solo per creare virus.. ma se lo si potesse installare su qualsiasi pc, beh sicuramente aumentano le probabilità... senza contare dialer, spyware ecc se ne aumentasse la diffusione, nonostante l'intrinseca sicurezza di mac os...

jo.li.
23-11-2005, 15:50
Detto questo può benissimo darsi che in passato o anche tutt'ora, in teoria, ms abbia "gradito" o favorito una certa "pirateria" per i vantaggi startegici della diffusione globale e capillare del suo os (forse proprio perché in certi paesi il fenomeno rimane comunque minoritario, anche nel privato e quindi un certo livello di entrate rimane garantito o forse perché il grosso dei guadagni è sempre stato preventivato su licenze oem ed utenza "pro"), questo non posso saperlo o comunque non ho info "abbastanza sicure" per poter prendere una posizione netta e convinta su questo.

Poi i produttori di pc "chiavi in mano" più che "obbligati" a metter win secondo me si sentono ben felici di poterlo mettere(con una licenza "oem" che incide molto meno sul prezzo totale di quanto farebbe una "retail") dato che probabilmente la grande maggioranza di chi compra un pc pronto all'uso gradisce che esso si effetivamente tale (e quindi contenga insatallato almeno un s.o. abbastanza "friendly");

e poi win (senza entrare nel merito se la cosa sia "giusta" o sbagliata", "positiva" o "negativa") è lo standard di fatto per l'utenza desktop home/office (su x86) di adesso e degli ultimi anni,
come "default" che ci dovrebbero mettere:
(osx non si può perché è solo per chi compra Apple)
linux, *bsd, solaris, qualche unix proprietario ?
os/2, be-os (ammesso che siano ancora in vendita) ?
Sinceramente, ma è solo una opinione personale ovviamente, e non viene certo da antipatia per linux & sistemi open vari (tutt'altro), credo che allo stato attuale un utente "medio", anche completamente "digiuno" di pc, che si facesse una esperienza parallela su uno dei s.o. citati e su win, sceglierebbe win...


Il monopolio della Microsoft sui s.o. con windows ormai dura molto più di dieci anni, e non perché abbia creato il prodotto migliore ma per altre ragioni. Nel 1995 quando la Microsoft se ne uscì con Windows 95 i "concorrenti" erano un certo BeOs , il NextStep ed anche l'OS/2 della IBM, e dei quattro il migliore non era sicuramente W95 soltanto che quest'ultimo aveva stampigliato il marchio Microsoft conosciuto da tutti, visto che tutti avevano installato nel proprio computer l'MSDOS e altri anche il windows 3.1 e per le grandi capacità di "marketing" del sig. Bill Gates, per la possibilità di poter mantenere la retrocompatibilità con tutto il software precedentemente acquistato e la possibilità di utilizzare i pacchetti office sempre della Microsoft e perché poi alla fine te lo ritrovavi installato nel tuo computer alla fine sappiamo come è andata a finire.
Se penso ai primi anni 90 e quali Sistemi operativi videro la nascita in quel periodo mi viene una tristezza a pensare che dal 1995 non c'è stata più una tale capacità di innovazione, anche perché ormai non c'è più concorrenza, anche se per fortuna di quei quattro s.o. almeno uno è sopravvissuto.
;)

MenageZero
23-11-2005, 15:53
i videogiochi sono infatti mooolto ma moolto più difficili da copiare, devi avere programmi specifici, masterizzatori che supportano tipi di scrittura al passo coi tempi, sicuramente un exe modificato(per non usare brutte parole! :D) ameno di copie 1:1 (da fare e masterizzare sempre con prgrm specifici!)
senza contare la starforce che pare per ora essere molto difficile da copiare, se non con metodi scomodi o molto macchinosi in parecchi casi
win invece te lo copia anche pincopallo con software caxuti...
sullo specifico, non sono bene informato anche perché praticamente non gioco, ma cmq si possono copiare come dici anche tu e poi oggi chi gioca col pc difficilmente ha hw datato (mast. compresi) e quelli (tanti) che vogliono giocare gratis non credo si preoccupino di dover aqcuisire qualche info e esperienza al riguardo... poi quelli che "se la devono vedere" con il cd originale e replicarlo, date le possibilità fornite da internet con banda larga e dalla vendita al dettaglio a prezzi stracciati da parte di certi soggetti (e questa è forse la pirateria più grave e da combattere di più perché magari quei soldi vanno nel giro di vere organizzazioni criminali...; anche se sw per pc in questo ultimo "canale" non mi è mai capitato di vederlo) che si aggiungono al tradizionale "passamano" sono una netta minoranza credo.
(ora non è che voglio stare qui a fare l'utente integerrimo, come detto non "videogioco" ma apprezzo molto i vg come opera di ingeno e tecnologia sw e mi è capitato di provare qualche titolo "passatomi" da conoscenti/amici solo per la curiosità di vederlo, per pochi minuti, e cmq il massimo sbattimento consiteva in inserire un seriale e sostituire un exe, cose già presenti nel cd/dvd tra l'altro)

l'unica cosa potrebbe licenziare(dare in licenza) mac os a produttori specifici(dell?) per entrare nella fascia bassa, anche se già degli ibook...
confermo comunque i miei dubbi sun una manovra del genere, che potrebbe rivoltarglisi contro...
senza contare il fatto che parte della stabilitò di mac os è dovuta al parco hardware ristretto, cosa che non potrebbe più esserci se venisse "aperto"..
e in ultimo, la possibilità a smanettoni di creare virus aumentare, per oraè difficle che uno si compri un mac solo per creare virus.. ma se lo si potesse installare su qualsiasi pc, beh sicuramente aumentano le probabilità... senza contare dialer, spyware ecc se ne aumentasse la diffusione, nonostante l'intrinseca sicurezza di mac os...
anche secondo me, finché il suo core-business è sull'hw, apple fa benissimo a fare il possibile per mantenere OSX solo sulle sue macchine (infatti secondo me "un'aiutino" hw alla protezione per evitare osx su pc qualunque lo useranno...) perché osx è forse, soprattutto per chi non dà importanza primaria all'estetica o alla qualità dell' "infrastruttura" (case, materiali, sistema di raffreddamento...), il maggior valore aggiunto nell'acquistare pc Apple proprio perché oltre ad essere un ottimo s.o. home/office(da quel che leggo, mai avuto un mac, senza voler entrare nei paragoni con win linux o qualunque altro) lo puoi avere solo se compri Apple...
Mi trovi d'accordo sui problemi che potrebe potenzialmente soffrire un osx con diffusuione analoga a win su combinazioni hw non predefinite ed estremamente varie, semplicemente per questioni statistiche, ma lungi da me l'idea di entrare in confronti su chi è più stabile e/o sicuro di chi, se si prendono questi argomenti, dato un numero sufficiente di lettori per il thread, si finisce sempre in un flame o giù di lì... :p

MenageZero
23-11-2005, 16:23
Il monopolio della Microsoft sui s.o. con windows ormai dura molto più di dieci anni, e non perché abbia creato il prodotto migliore ma per altre ragioni. Nel 1995 quando la Microsoft se ne uscì con Windows 95 i "concorrenti" erano un certo BeOs , il NextStep ed anche l'OS/2 della IBM, e dei quattro il migliore non era sicuramente W95 soltanto che quest'ultimo aveva stampigliato il marchio Microsoft conosciuto da tutti, visto che tutti avevano installato nel proprio computer l'MSDOS e altri anche il windows 3.1 e per le grandi capacità di "marketing" del sig. Bill Gates, per la possibilità di poter mantenere la retrocompatibilità con tutto il software precedentemente acquistato e la possibilità di utilizzare i pacchetti office sempre della Microsoft e perché poi alla fine te lo ritrovavi installato nel tuo computer alla fine sappiamo come è andata a finire.
Se penso ai primi anni 90 e quali Sistemi operativi videro la nascita in quel periodo mi viene una tristezza a pensare che dal 1995 non c'è stata più una tale capacità di innovazione, anche perché ormai non c'è più concorrenza, anche se per fortuna di quei quattro s.o. almeno uno è sopravvissuto.
;)

guarda sostanzialmente mi trovi d'accordo in particolare su win95 vs quei sistemi di allora che hai citato;

in particolare os/2 (gli altri non ho avuto il piacere di conoscerli personalmente); di next non sapevo che fosse in vendita separatamente dall'hw, beos mi pare(solo un dubbio eh, potrei sbagliare) sia venuto fuori un pò dopo, nella seconda metà anni 90, quando il win "post95" era già una realtà solida; poi non ricordo quale fosse la situazione prezzi all'uscita di win95, ma ho il sospetto che fosse a favore di ms.

come giustamente dicevi, la retrocompatibilità ha avuto un ruolo importante e secondo me è stata IBM a giocarsi peggio le sue carte, forse proprio a livello di marketing, dato che os/2, oltre ad essere un ottimo e tecnicamnte avanzato s.o., aveva una certa compatibilità con app dos (win16 win32 non ricordo)...

a difesa della qualità in casa ms all'epoca c'è da dire che l'architettura nt era già disponibile sul mercato prima di w95, con winNT 3.5(anche se aveva gui più simile a win3.1, ma non vuol dire niente a livello di architettura di s.o.) ; tra l'altro NT ha avuto genesi comune con os/2 in collaborazione con IBM, pi c'è stato il "fork" mi sembra per disaccordo su quali api usare come principali per il sistema...
sul perché poi si doveva aspettare il 2001 con xp per avere o.s. nt based anche per la fascia home (penso il problema retrocompatibilità potesse essere risolto in qualche modo, visto che ad oggi con xp molte app dos funzionano con un smplice click sull'eseguibile, anche se emulate) non saprei proprio che dire...

riguardo la possibilità di avere msoffice che spinge/spingeva a metter win sul proprio pc, forse era anche quella una motivazione forte indipendente dalla qualità dell'os, ma in un mondo che funziona secondo le leggi di mercato e con ms come tutte le altre realtà aziendali, credo, che esiste per generare profitto, non penso si possa dire a qualcuno "sei un infame perchè non compili pachettizzi e vendi la tua migliore app anche per i s.o. concorrenti"...

cdimauro
24-11-2005, 07:18
Perfettamente d'accordo con MenageZero. :p

Aggiungo soltanto che non considererei della partita s.o. come NeXTStep e BeOS nella discussione relativa al periodo 1995: il primo perché disponibile soltanto per la piattaforma hardware NeXT (che non girava su x86, se non ricordo male), e il secondo perché all'epoca era disponibile soltanto per PowerPC (per x86 arriverà soltanto qualche anno dopo).

jo.li.
24-11-2005, 09:29
Perfettamente d'accordo con MenageZero. :p

Aggiungo soltanto che non considererei della partita s.o. come NeXTStep e BeOS nella discussione relativa al periodo 1995: il primo perché disponibile soltanto per la piattaforma hardware NeXT (che non girava su x86, se non ricordo male), e il secondo perché all'epoca era disponibile soltanto per PowerPC (per x86 arriverà soltanto qualche anno dopo).

Il NextStep girava su hardware completamente diversi già nel 1994:

Until 1993, NEXTSTEP would only work on 68030s and 68040s. But the high prices of these machines ($8,000-$20,000) didn't encourage sales. Instead, NeXT went multi-platform: they first supported Intel 486s by porting their OS to x86, and then it was HP PA-Risc and SPARC machines. The day that they announced that the NeXT hardware was dead became known as "Black Tuesday". The new multi-platform idea sounded great at first, but problem was, NeXT was too late to release their OS for the x86 CPUs, as Windows 3.1 was already there. One or two years earlier might have had a different outcome for NeXT (plus some DOS compatibility via SoftPC or an API layer). At least, as interoperability goes, NeXT introduced the "fat binaries" feature, which were specially compiled binaries that could run on all supported platforms (NeXT, Intel and Sparc or HP-PA)

Cavolo fare un confronto tra windows 3.1 e il Nextstep è ridicolo, il primo era semplicemente un front-end appiccicato sull'MSDOS, il secondo era troppo avanti per quegli anni, "forse troppo" :D

Il beOs venne portato su piattaforma x86 intorno al 96-97 ma era qualcosa di fenomenale ai tempi e non vedo perché escuderlo come potenziale concorrente di windows 95:


The Be Operating System, or BeOS, was first written in 1991 to run on BeBox hardware. Unlike other operating systems of the time, BeOS was written to function as a GUI-based operating system. Optimized for digital media work, BeOS makes full use of multiprocessor systems by utilizing modular I/O bandwidth, pervasive multithreading, preemptive multitasking and a custom 64-bit journaled file system known as BFS. The BeOS GUI was developed on the principles of clarity and a clean, uncluttered design. The interface API was written in C++ for ease-of-programming. It has POSIX compatibility and access to a command line interface through the Bash shell, although internally is not a Unix-derived operating system.

Initially designed to run on custom BeBox hardware, BeOS was later extended to run on PowerPC-based processors with the hope that Apple Computer would purchase or license BeOS as a replacement for its then aging Mac OS. However, instead of BeOS, Apple's board of directors decided NeXTSTEP was a better choice and purchased NeXT in 1996, which also brought Apple co-founder Steve Jobs back into the fold. To further complicate matters for Be, Apple refused to disclose architectural information about its G3 line of computers—information critical to making BeOS work on the latest hardware from Apple.
Due to Apple's aggressive moves and the mounting debt of Be Inc, BeOS was soon ported to the x86 platform with its R3 release.

xeal
24-11-2005, 19:28
Ma fek non diceva di aver partecipato alla realizzazione di una versione di BeOS (supporto OpenGL?)? O era un altro OS?

cdimauro
25-11-2005, 09:06
Il NextStep girava su hardware completamente diversi già nel 1994:
Ricordavo male, allora. :p
Cavolo fare un confronto tra windows 3.1 e il Nextstep è ridicolo, il primo era semplicemente un front-end appiccicato sull'MSDOS, il secondo era troppo avanti per quegli anni, "forse troppo" :D
Infatti richieda hardware molto pompato e, con tutto ciò, non è che brillasse in velocità... ;)
Il beOs venne portato su piattaforma x86 intorno al 96-97 ma era qualcosa di fenomenale ai tempi e non vedo perché escuderlo come potenziale concorrente di windows 95:
Quando arrivò BeOS per x86 il mercato era già stato invaso e conquistato da Windows 95, che vantava ovviamente anche un enorme supporto non solo a livello software, ma anche di driver. Arrivò troppo tardi, IMHO.

x xeal: sempre se non ricordo male :p, fek dovrebbe aver lavorato al kernel di OpenBeOS.

jo.li.
25-11-2005, 14:15
Infatti richieda hardware molto pompato e, con tutto ciò, non è che brillasse in velocità... ;)

Era la GUI che era piuttosto pesante perché basata sul "Display Postscript", lo stesso delle stampanti.


Quando arrivò BeOS per x86 il mercato era già stato invaso e conquistato da Windows 95, che vantava ovviamente anche un enorme supporto non solo a livello software, ma anche di driver. Arrivò troppo tardi, IMHO.


Io sono convinto che se fosse stato portato su x86 anche un anno prima del 1995 non sarebbe cambiato molto, perché il "supporto" che avrebbe avuto W95 sarebbe stato lo stesso troppo forte per poter competere sul mercato dei PC.

xeal
26-11-2005, 00:47
x xeal: sempre se non ricordo male :p, fek dovrebbe aver lavorato al kernel di OpenBeOS.

Probabile, devo aver fatto confusione :p


Io sono convinto che se fosse stato portato su x86 anche un anno prima del 1995 non sarebbe cambiato molto, perché il "supporto" che avrebbe avuto W95 sarebbe stato lo stesso troppo forte per poter competere sul mercato dei PC.

Può darsi; presumibilmente però avrebbe avuto qualche chance in più in un mercato (sulla carta, potenzialmente) ancora da definire che in uno già consolidato. Comunque non lo sapremo mai...