Intel Yonah: ecco i prezzi

[dvd100]

Originariamente inviato da LCol84

Che 2 @@...
Ancora niente 64bit...Allora salto ancora sto giro per il portatile...Ma quando cavolo escono i dual core 64bit per i notebook??

ad oggi gli unici 64bit x nb sono AMD che però nn sono dual core.. cmq x yonah si parla di 2006 penso che nel frattempo uscirà un turion X2

[Automator]

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

[DKDIB]

Shinji wrote:
> [...] 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!

[Caesar_091]

Originariamente inviato da DKDIB

Tutto quello che gli sviluppatori faranno non riuscira' mai a funzionare sulle piattaforme definitive perche' in realta' queste saranno totalmente diverse.

[magilvia]

Originariamente inviato da Mizar74

A chi servono oggi? Il dietro-front di Apple ha mostrato ancora una volta che attualmente non servono assolutamente a nulla a parte in ambito server.
E lo dico da possessore di una workstation Alpha della Digital, che già nel 1996 forniva un processore a 64 bit.

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.

[roby1483]

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

[matteo85]

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?

[Lestat.]

Per giocarci a unrealturnement 2007???

[Fx]

Originariamente inviato da tarek

ma supporteranno i 64 bit?
no xchè il mac è a 64 già da un pezzo...

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

[magilvia]

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.

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

[samslaves]

>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/documentation/Darwin/Conceptual/64bitPorting/index.html#//apple_ref/doc/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.

[samslaves]

>tra il SUPPORTARE i 64 bit o ESSERE a 64 bit<

cosa intendi per ESSERE? Ti rendi conto del lavoro necessario per riscrivere TUTTI i frameworks (Core Graphics, Core Data, Core Image, Quartz ecc...) a 64 bit? Non stiamo mica parlando di Win o Linux. KDE e' a 64 bit per caso?

Da Arstechnica:

It's clear that the road to "full 64-bit support" will be a long one. There are few benefits to being a 64-bit process for the vast majority of GUI applications. Nevertheless, it's safe to assume that, eventually, all Macs will include 64-bit CPUs. The introduction of 64-bit versions of all Mac OS X subsystems (Carbon, Cocoa, Core Foundation, QuickTime, Quartz, etc.) seems inevitable.

Panther introduced rudimentary 64-bit support to Mac OS X. It expanded the virtual address space (in the kernel, anyway) to 64 bits and allowed the use of 64-bit registers and the instructions that manipulate them (i.e., 64-bit math). But processes other than the kernel still saw a 32-bit address space. A single process could work with more than 4GB of memory (remember, the Power Mac G5 can hold up to 8GB RAM), but doing so required the programmer to manually juggle several 32-bit-addressable chunks of memory at once.

Tiger takes Mac OS X another small step in the 64-bit direction by allowing any process to see a 64-bit address space. Such a process must use 64-bit pointers in its code, of course, and that means that any libraries it uses must also be compiled to use 64-bit pointers.

In Tiger, the only 64-bit library is "libSystem," which is basically the BSD layer. A 32-bit version of libSystem is also included, of course (otherwise 32-bit applications would not run on Tiger).

A process can do a lot using only libSystem: file and network i/o, math, inter-process communication, er...more math. But the notable thing it can't do is any sort of GUI operation.



Dal link:

...

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

...

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.

[Fenomeno85]

io aspetto a comprare il portatile finche non sarà uscito sta cpu

ovvio i prezzi son alti ma dopo si abbasseranno


~§~ Sempre E Solo Lei ~§~

[cdimauro]

Originariamente inviato da samslaves

cosa intendi per ESSERE? Ti rendi conto del lavoro necessario per riscrivere TUTTI i frameworks (Core Graphics, Core Data, Core Image, Quartz ecc...) a 64 bit? Non stiamo mica parlando di Win o Linux. KDE e' a 64 bit per caso?

Hai ragione, il problema è proprio quello, ma non è un il s.o., sia esso Windows o Linux, a fare la differenza, ma il processore: per passare da x86 a x86-64 per lo più è sufficiente una ricompilazione. Cosa che con OS X non è possibile fare RIMANENDO COI G5.

Quando Apple passerà a x86, vedrai che non avrà molte difficoltà a presentare librerie a 32 e 64, come ha fatto Windows con XP / 64 e la comunità open source con Linux a 64 bit.
Idem per le applicazioni: basterà per lo più una semplice ricompilazione.

Ricompilazione che permette di sfruttare dati a 64 bit e quantità di memoria oltre i 4GB generalmente senza che il programmatore debba mettere mani al codice, come invece attualmente avviene con OS X.

Riscrivere tutti i framework è, quindi, una necessità, ma soltanto per l'attuale piattaforma a 64 bit usata dai Mac.

[Mietzsche]

E la profezia si avverò! l'avevo sospettato subito che Apple, se fosse passata a x86 avrebbe scelto PentiumM e derivati (alla fine è l'unico procio decente Intel). i 64bit ci dovrebbero essere in Yohna (EMT64) e dell'HiperTreding non ce ne dovrebbe essere bisogno (2 core fisici!). Se tutto va bebe inoltre il 65nm dovrebbe riallineare i consumi coi single core 90nm. Bon Bon!

[idt_winchip]

Originariamente inviato da samslaves

KDE e' a 64 bit per caso?

[BaronRobot]

Ragazzi, aprite gli occhi: i prezzi sono all'ingrosso per forniture di lotti da 1000
unità, quindi per processore vanno da 0.209 a 0.637 dollari. I ricarichi successivi
(per trasporto, progettazione, montaggio, programmazione, garanzia etc.) fanno
schizzare i costi alle stelle. Ma alla fonte costano poco: per pazzesco che possa
sembrare è così...

[samslaves]

x idt_winchip

>KDE e' a 64 bit per caso?

Intendevo sul atto di essere o non essere, riferendomi anche alla GUI a 64 bit.

[sirus]

Originariamente inviato da tarek

ma supporteranno i 64 bit?
no xchè il mac è a 64 già da un pezzo...

si ma se il SO non li usa che te ne fai ??? l'unica parte di MacOSX a 64bit è quella che si occupa di gestire la RAM. interfaccia grafica (e quello che sta dietro), applicazioni varie ecc... sono tutte a 32bit perchè non c'è vantaggio nel ricompilarle per i 64bit

Originariamente inviato da ShinjiIkari

ma quali overclock quale bios fenix... ma per piacere, quello è un devkit c'entra una mazza con quelli che venderanno al pubblico tra un anno. Vedrai che mo fanno i mac col bios, che magari premi canc e overclocchi no? Magari con tutti i limiti delle partizioni e non fa neanche il boot da firewire, pensate prima di parlare.

ma che pensi che il tanto decantato "openfirmware" di apple non sia un bios ?! tutti i computer hanno un bios altrimenti come si fa a gestire le periferiche??? che si chiami bios che si chiami openfirmware è semrpe quella roba
e comunque è molto probabile che apple per i prossimi Mac utilizzerà mobo intel (oltre a proci e chipset)...quindi fai i conti.

tornando in topic direi che è meglio il dual core dei 64bit, e poi fare un procio 64bit voleva dire rivedere l'architettura attualmente vincente del PM invece mettere assieme due core è più semplice, redditizio e veloce
per chi dice che la prossima generazione di differenete avrà solo il supporto 64bit attivato si sbaglia. semplicemente perchè il dothan è un 32bit e basta, il prossimo core invece sarà rivisto e saranno implementate le istruzioni x86-64 e i registri di dimensione superiore ecc...

ad ogni modo che vi frega dei 64bit??? browser, mailer, (molto probabilmente) office e molto altro rimarrà ancora per un po' a 32bit dato che ha 64bit avrebbe prestazioni inferiori quindi...

[sirus]

cmq ottimi i prezzi mi sembrano concorrenziali