Intel Yonah: ecco i prezzi

shin.....
visto che non verrà fatto niente per impedire di installare win (e non sono parole mie) e le sk video saranno standard forse è meglio che sia tu a pensare prima di parlare.

e poi si sta solo discorrendo non c'è bisogno di aggredire.

Paisà che non sei altro

[color=red]Shinji wrote:[/color]
> [...] quello è un devkit c'entra una mazza con quelli che venderanno al
> pubblico tra un anno.

In realta', quel devkit e' finto!
Tutto quello che gli sviluppatori faranno non riuscira' mai a funzionare sulle piattaforme definitive perche' in realta' queste saranno totalmente diverse.

In pratica, e' uno degli scherzi piu' costosi oggi disponibili sul mercato!

Si ma è inutile ragionare in questo modo Se non si comprano le CPU a 64 nessuno farà codice a 64 e sempre meno se ne compreranno è un circolo vizioso. Se vogliamo che servano dobbiamo comprarle.

E' vero che hanno detto che non faranno niente per impedire l'installazione di Windows sui Mac ma non hanno detto che sara' possibile installare OS X su qualunque PC

64 bit e dual core

I 64 bit degli x86, meglio noti come x86-64 o amd64, o anche em64t, danno delle migliori prestazioni non perché i registri sono a 64 bit, ma perché l'architettura amd64 raddoppia il numero di registri disponibili al programmatore: da 8 a 16.
Tenendo presente che all'atto pratico i registri utilizzabili liberamente dai programmi sono solo 6, perché 2 vengono riservati per l'uso dello stack, si passa da 6 a 14 registri, più del doppio.
I processori G4 che si usano sui portatili Mac hanno 32 registri a 32 bit (come molti RISC), mentre i registri dei G5 sono 32 registri a 64 bit.
Tenendo presente che fare lo stesso calcolo a 64 bit è più oneroso per la cpu che farlo a 32 bit, all'atto pratico *sui mac* i 64 bit servono a poco.
Certo, con una cpu a 64 bit puoi indirizzare più di 4GB di ram, ma su un portatile a che serve?

Per giocarci a unrealturnement 2007???

peccato che mac os x sia ormai rimasto l'unico sistema operativo a non esserlo. tra il SUPPORTARE i 64 bit o ESSERE a 64 bit c'è un abisso, poi certo che i markettari di apple siano stati bravi a confondere le acque non c'è dubbio...

sui pc (parlo ovviamente di x86) il primo os interamente a 64 bit è stato ovviamente linux, da qualche mese è arrivato anche windows.

sui mac mac os x supporta oltre i 4 gb di ram (curiosità: sia windows che linux supportavano ben oltre anche sui pc a 32 bit... i limiti risiedevano altrove) grazie al supporto ai 64 bit, ma si ferma lì, per il resto è a 32 bit.

per quanto concerne il resto, l'intervento di matteo85 chiarisce un po' di cose... l'unica cosa è che non è detto che una cpu a 32 bit possa allocare solo 4 gb di ram, ad es. IBM ha server xeon a 32 bit che supportano 12 gb di ram (ovviamente monoprocessore)... tanto per dire

Questo è opinabile. Se raddoppi il numero di transistor, l'onerosità di un'operazione a 64 bit è uguale a quella a 32.

>peccato che mac os x sia ormai rimasto l'unico sistema operativo a non esserlo. tra il SUPPORTARE i 64 bit o ESSERE a 64 bit c'è un abisso, poi certo che i markettari di apple siano stati bravi a confondere le acque non c'è dubbio...<

http://developer.apple.com/document.../uid/TP40001064

Before we go further, it is important to dispel a few common misconceptions.

Myth #1:
Myth: My application has to be 64-bit (or run on a G5) to use 64-bit data or do 64-bit math.
Fact: 32-bit applications already have the long long data type, which is 64 bits.
Myth #2:
Myth: The kernel needs to be 64 bit in order to be fully G5-optimized.
Fact: The kernel never needs to directly address more than 4 GB of RAM at once. The kernel is able to make larger amounts of memory available to applications by simply using long long data types to keep track of mappings internally.
Myth #3:
Myth: All of the system calls have to change (or new ones have to be added) for 64-bit compatibility.
Fact: Most of the system call arguments changed to 64 bit many years ago. Functions like llseek64 are unnecessary because those functions are already 64 bit capable. The notable exceptions are those functions related to memory management, such as mmap, malloc, and so on. Those functions have changed in terms of the size of data passed (since the size of size_t changed), though this change should be largely transparent to you as a programmer.
Myth #4:
Myth: Every application needs the ability to work with more than 4 GB of RAM.
Fact: Most applications have relatively modest memory requirements (a gigabyte or less). Some applications need more. Many of these applications can do so without moving to a 64-bit address space. Generally speaking, only scientific applications have moved to 64-bit executables on other platforms. There are a few exceptions, though, such as large-scale 3D rendering applications.
Myth #5:
Myth: My application will have much faster performance if it is a “native” 64-bit application.
Fact: This is true for some other architectures because the number of registers and the width of registers changes between 32-bit and 64-bit mode. However, the PowerPC architecture does not have either of these limitations. It was designed for 64-bit computing from the beginning, and supports 64-bit arithmetic instructions in 32-bit mode. Thus, on PowerPC architectures, software does not generally become faster (and may actually slow down) when compiled as a 64-bit executable.