Is Core Duo 64-Bit?

[MacRumors]

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com)

Hexus.net vaguely claimed (http://www.hexus.net/content/item.php?item=4604) that Intel's Core duo may have support for 64-bit processing. The report is poorly written so is difficult to gather much from it, however, several Mac websites have started reporting it, so it is now linked here for interest sake. It appears that even if the Core Duo had hidden 64-bit capabilities, it is not active on shipping models, making the point somewhat moot.

It appears the basis of this rumor is that Intel's upcoming Sossaman processor is 64-bit, however, a recent press release (http://www.supermicro.com/newsroom/pressreleases/2006/press020706.cfm) specifically notes that Sossaman is a 32-bit processor.

The new dual-core Intel Xeon processor LV, codenamed "Sossaman," is designed on Intel's 65-nanometer technology manufacturing process. Sossaman, based on the Intel's next-generation, power-optimized micro-architecture, will offer dramatically improved performance and greatly reduced power consumption. The brand new 32-bit dual-core Intel Xeon LV processor with 2MB of L2 cache running at 2 GHz is based on the existing Pentium M architecture and offered power-saving features with Demand Based Switching, and Enhanced Speedstep Technology (EIST).

[Eagon]

what would be the point of hiding these capabilities?

[Synapple]

what would be the point of hiding these capabilities?

Exactly... would be good but sounds weird

[ScottB]

Would raise a few questions if true, that's for sure.

[SiliconAddict]

what would be the point of hiding these capabilities?


It wasn't ready so instead of either pushing back the chip to a later release date or releasing a buggy chip they disabled the feature on chip. Or at least that is my guess. *shrugs*

PS- Someone might want to edit the title. I'm not a grammar Nazi or anything but "Is Core Duo is 64-Bit?" Sounds like someone hasn't had their 3AM caffeine fix. :)

[qubex]

Intel "hid" the 64-bit EM64T extensions to the Pentium4 for quite some time, mainly because they weren't yet ready for prime-time. It makes sense for them to integrate the capabilities into chips for testing and evaluation purposes prior to "rolling out" the feature officially.

[ezekielrage_99]

Kind of getting a flashback to 1999 when the Intel Celeron 300A and 400A chips were released rathery quickly.

The Celeron 300A and Celeron 400A could be clocked higher than most of the Pentium chips at the time, plus they had a whole heap of other cool little specs on the Processor which Intel didn't count on too many users knowing about.

I think the Duo and Solo has been rushed to be released and there will be quite a few nice little surprises found on both processors which Intel hasn't thought that users might find. The 64 Bit thing kind of makes sense because thats the way the industry in heading.

Only time will tell ;)

[thejadedmonkey]

yes.

http://www.gizmodo.com/gadgets/intel/intel-hiding-features-from-users-153822.php
http://web.mac.com/schappi/iWeb/Personal/Blog/0CEEE169-996E-44E2-92E7-FB2FAEF603F6.html

[qubex]

Hmm.

Both the iMac and MacBook Pro are physically limited to 2 GB of RAM, so even if the processors support 64-bit addressing, it doesn't make much difference. (64-bit arithmetic isn't very useful in everyday usage.)

[markiv810]

Hmm.

Both the iMac and MacBook Pro are physically limited to 2 GB of RAM, so even if the processors support 64-bit addressing, it doesn't make much difference. (64-bit arithmetic isn't very useful in everyday usage.)

Wouldn't 64 bit arithmetic be useful for gaming, playing videos, manipulating video data (Shake, Final Cut Pro, Ripping DVDs, Maya) or even photoshop, even handling the GUI candy, just asking, basically anything that's going to be processor intensive.

[shyataroo]

wait wait wait wait wait wait... hold the Fu-kuck up, if the new "core" chips are 32 bit processors, wouldn't that technically make them the same speed as the G5? (with the G5 having 64 bit omptimized OS and benchmarking) And thereby making Apple's Claim of the new chips being faster moot?

[Nonabelian]

Wouldn't 64 bit arithmetic be useful for gaming, playing videos, manipulating video data (Shake, Final Cut Pro, Ripping DVDs, Maya) or even photoshop, even handling the GUI candy, just asking, basically anything that's going to be processor intensive.

64-Bit means there are "64-bits" of address space. All modern processors can perform 64-bit arithmetic, even "32-bit" processors. Typically, 32-bit processors have a maximum of 2GB of addressable memory (or 4GB on some systems). All a 64-bit processor gets you is more addressable memory, beyond the 2GB limit. Some of the new Intel and AMD 64-bit processors also have more registers, which is helpful, but it really doesn't have anything to do with 64-bit address capability.

I agree that for video processing, it may be useful to have 64-bits of address space, but the application must be compiled for 64-bit as well. If you really have that much data to crunch through, you're also going to need a huge amount of processing power. This is where a quad G5 makes sense with 8-16GB of memory and 64-bit processors have a role.

[bigandy]

hmm, interesting :rolleyes:

[idea_hamster]

Hmm.

Both the iMac and MacBook Pro are physically limited to 2 GB of RAM, so even if the processors support 64-bit addressing, it doesn't make much difference. (64-bit arithmetic isn't very useful in everyday usage.)

Technically, I think that both the iMac and MacBook pro are physically limited to two RAM modules rather than 2GB.

With the largest modules currently offering only 2GB a piece (available for PMac), this could be a 4GB limit. That still doesn't make a difference, since a 32-bit register can address 4GB of RAM.

However, this will change in the future and who's to say it won't happen before these iMacs and MacBooks get retired?

[Waragainstsleep]

Ifthe core duo IS 64-bit, shouldn't that mean it will run XP? (XP-64 supports EFI doesn't it?

[steve_hill4]

Technically, I think that both the iMac and MacBook pro are physically limited to two RAM modules rather than 2GB.

With the largest modules currently offering only 2GB a piece (available for PMac), this could be a 4GB limit. That still doesn't make a difference, since a 32-bit register can address 4GB of RAM.

However, this will change in the future and who's to say it won't happen before these iMacs and MacBooks get retired?
I think the maximum you can get into a single slot is 1GB with 32-bit processors. The maximum that consumer computers can handle is 4GB, but spread across four ram slots. I amy be wrong, (as there would currently be no need for so many 2GB sticks of ram), but that's what I recall.

If you actually check the tech specs of both Core Duo offerings from Apple, they both state a maximum of 2GB in total anyway.

[hdasmith]

64-Bit means there are "64-bits" of address space. All modern processors can perform 64-bit arithmetic, even "32-bit" processors. Typically, 32-bit processors have a maximum of 2GB of addressable memory (or 4GB on some systems). All a 64-bit processor gets you is more addressable memory, beyond the 2GB limit. Some of the new Intel and AMD 64-bit processors also have more registers, which is helpful, but it really doesn't have anything to do with 64-bit address capability.


32-bit processors require more than twice the number of cycles and registers to perform 64-bit processing, therefore with larger equations, a 64-bit processor will easily outperform a 32-bit. This is part of the reason the G5's have less cache than the G4's.

32-bit processors can handle up to 4GB of RAM (2^32 B), 64-bit will handle 18*10^9 GB of RAM (2^64 B), if there was a motherboard that could also handle it.

Aqua, Quartz, core image, core video, etc. (slight assumption that they have been written for 64-bit processors along with Tiger) really gain from the extra maths capabilities a 64-bit processor has to offer (put the top G4 next to a 1.6GHz G5, and you'll see a difference in Finder).

[Bakafish]

So here's the deal guys. Even though there is little doubt in my mind that the core actually does have the 64-bit and VT extensions, Intel is very good about disabling them in the hardware itself. When they actually package the die, they are able to internally bridge various configuration jumpers (no pencil mods here :( ) Below is the actual sysctl output for the new Duo CPU on a iMac Duo:

machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Genuine Intel(R) CPU 1400 @ 1.83GHz
machdep.cpu.model_string: Unknown Intel P6 Family
machdep.cpu.family: 6
machdep.cpu.model: 14
machdep.cpu.extmodel: 0
machdep.cpu.extfamily: 0
machdep.cpu.feature_bits: -1075184641 49577
machdep.cpu.extfeature_bits: 1048576 0
machdep.cpu.stepping: 8
machdep.cpu.signature: 1768
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP
MTRR PGE MCA CMOV PAT CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM SSE3 MON VMX EST TM2 TPR
machdep.cpu.extfeatures: XD
machdep.cpu.logical_per_package: 2
machdep.cpu.cores_per_package: 2

The fact is that Intel could trivially enable these extensions, and they will. They will sell those chips under a different name for way more money though :D That's awfully clever of them, don't you think? Yeah, it's sad that all that potential is wasted. On bit of hopeful news though, when 64 bit and Virtual Machine support becomes a factor (say when Apple transitions the xServe to x86) there will be little stopping you from slapping in the faster/64bit enabled CPU's as they are not currently soldered to the motherboard.

Bakafish

[gnasher729]

Hmm.

Both the iMac and MacBook Pro are physically limited to 2 GB of RAM, so even if the processors support 64-bit addressing, it doesn't make much difference. (64-bit arithmetic isn't very useful in everyday usage.)

64 bit addressing is actually quite useful.

For example, many operating systems allow reading and writing of files on your harddisk through "memory mapping": A file is mapped to an area of memory, a program can manipulate the data in the file as if it was in memory. Instead of calling operating system functions to read and write data from the file, this is handled by virtual memory. The problem is: On a 32 bit system, the total size of all everything including memory mapped files must be less than 4 GB. There is no way that a ten GB digital video file could be memory mapped. On a 64 bit OS, no problem.

Also important: In 64 bit mode, Intel and AMD processors have 16 general purpose register and sixteen floating point/vector registers instead of 8.

[janstett]

Wouldn't 64 bit arithmetic be useful for gaming, playing videos, manipulating video data (Shake, Final Cut Pro, Ripping DVDs, Maya) or even photoshop, even handling the GUI candy, just asking, basically anything that's going to be processor intensive.

Not neccessarily. More bits isn't always better. First, for many applications like you mentioned (games, 3d modelling, etc) floating point operations are more useful.

In the Intel world, when they moved from 16-bit to 32-bit it was a big deal, mostly for the change from a segment-offset memory model to a flat 32-bit memory model. Here the ability to get access to > 4gb memory is the big deal, and they've been able to put in some hacks/shortcuts to work around this for several years.

Just to illustrate how 64-bit isn't always better, let's imagine doing an add for two 32-bit integers with the same values at the assembly (register) level:

00000000000000000000000000000001 +
00000000000000000000000000000010

versus 64-bit:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

For this simple add, the 64-bit int is more work and doesn't yield any benefit.

Microsoft learned this lesson with Windows 95. Remember, they started with 16-bit Windows 3.1 and added 32-bit extensions to it. But the fact was that in many cases the 16-bit code was faster (partly due to years of optimization) so key parts of Windows 95's subsystem stayed 16-bit internally and used 32-bit thunking to talk to their 32-bit "other halves".

[Bakafish]

That output I showed above clearly indicates that 64 bit and all of the new Virtual thread / Virtual machine extensions are disabled on these chips. So this is a non-story from a technical aspect.

[Anonymous Freak]

yes.

http://www.gizmodo.com/gadgets/intel/intel-hiding-features-from-users-153822.php
http://web.mac.com/schappi/iWeb/Personal/Blog/0CEEE169-996E-44E2-92E7-FB2FAEF603F6.html

No.

http://www.intel.com/pressroom/kits/events/idffall_2005/20050824gelsinger.pdf
http://www.supermicro.com/newsroom/pressreleases/2006/press020706.cfm

I trust the VP in charge of Intel's CPU division, and an official Press Release from a major Intel server motherboard producer a LOT more than a random rumor on Gizmodo, or a blog of unknown origin.

If you follow all of the 'proof' links out there, they all lead back to the same Hexus.net source. (Gizmodo and your blog both point to the same Hexus source, so they're not two sources, only one.) (And in all of The Register's info on Sossaman, even they never once mention 64-bit.)

I don't even know where Gizmodo got their info, as they say that "Intel openly admits that its Sossaman chips are 64-bit..." but there has been no such admission, and Hexus is their stated source. But Hexus just says "And it transpires that Sossaman supports iAMD64..." With no sourcing of any kind.

The Register reports "Sossaman takes Yonah and adds dual-processor support, along with a 36-bit physical address bus to allow the chip to handle up to 64GB of physical memory..." I'm guessing someone saw 'non-32-bit', and '64 GB', and inferred 64-bit, which is wrong. It's a 32-bit chip, which processes data in 32-bit chunks, that happens to have a 36-bit memory address space. (In fact, the original Pentium II Xeon could address 36-bits of memory, so this isn't even new to the P6 line, of which Yonah and Sossaman are a part of.)

[idea_hamster]

I think the maximum you can get into a single slot is 1GB with 32-bit processors. The maximum that consumer computers can handle is 4GB, but spread across four ram slots. I amy be wrong, (as there would currently be no need for so many 2GB sticks of ram), but that's what I recall.

If you actually check the tech specs of both Core Duo offerings from Apple, they both state a maximum of 2GB in total anyway.

Hmmm. Perhaps, but the tech specs of the Quad PowerMac says it has a 16GB RAM limit, when we know that it is much more. Theoretically it is 2^64 or 16 exabytes, but in practice I recall that RAM is handled by a 43-bit register, so currently it could only address 2^43 or 8.8 terabytes.

I'd be interested to see an explanation of why there is a 1GB-per-module limit associated with 32-bit processors -- but my suspicion is that this is really about what is commercially available. I don't ever recall hearing that there is something about the slot that limits the RAM amount.

When Apple says that a computer has a "max RAM amount," it really means that this is the most RAM that you can get installed through them. Since they only sell 1GB modules for the Core Duo Macs and each has two slots, the official Apple math is simple -- a max of 2GB.

Of course, without the expansion slots, it's all just hot air.... :)

[TangoCharlie]

what would be the point of hiding these capabilities?

Intel do this all the time. They have two (or more) products all based on the
same processor core. However they cripple one so that it can sell at a competitive price while leaving the uncrippled version at full-price.

There really isn't much difference between Celeron,P4 and Xeon... howver intel can charge alot more for the xeon's and P4's because the Celerons are lame.

So, Intel will sell Core Duo (Yonar) for one price and an identical (or near idential) chip as a Xeon at a much higher price.

As a side note, The Sossaman based CPU's would seem an obvious choise for XServes. Anyone want to start a rumor about when the "iServe" will ship?

[shamino]

wait wait wait wait wait wait... hold the Fu-kuck up, if the new "core" chips are 32 bit processors, wouldn't that technically make them the same speed as the G5? (with the G5 having 64 bit omptimized OS and benchmarking) And thereby making Apple's Claim of the new chips being faster moot?
64-bit does not mean "faster". It's just a marketing term to mean some key parts of the chip (typically address busses and general-purpose registers) are 64-bits wide.

As others have already said, this doesn't mean very much for most programs. If your application has no need for more than 4G of RAM or wide registers, 64-bit code can actually run slower than 32-bit code (because memory pointers are larger, meaning apps use more memory and consume more cache.)

The reasoon 64-bit chips historically run faster than 32-bit chips is because they usually have higher clock speeds, faster busses, or larger caches. Applying those same factors to a 32-bit chip will speed them up just as much.

Taking a CoreDuo and flipping some internal bit to activate 64-bit features will not speed it up. It will have the same size and speed cache. It will have the same bus. It will have the same clocking.

This might be useful if you have some application that requires a 64-bit processor (like some Photoshop plugins that can take advantage of huge memory sizes), but that won't mean anything to an iMac owner, since the hardware can't support more than 2G of RAM anyway.

[shamino]

Technically, I think that both the iMac and MacBook pro are physically limited to two RAM modules rather than 2GB.
They have two slots. But Apple also advertises a 2GB memory limit, despite the existence of 2G modules.

The core-logic chipset (that controls the busses) is as much responsible for memory capacity as the physical number of sockets.

Apple does have a history of under-documenting memory capacities. (e.g. the Bondi iMac, advertised with a 64M capacity per slot, but can actually accept 256M in each slot.) But this doesn't mean it will accept the largest modules that can physically fit in the slot (those same iMacs can not accept 512M or 1G SO-DIMMs.)

Right now, Apple is advertising a 2G memory limit. Until people install larger modules and demonstrate a larger actual capacity, one should assume that this is the real limit.

[shamino]

I think the maximum you can get into a single slot is 1GB with 32-bit processors.
Not at all true. The bit-width of a processor has nothing all to do with this. It is entirely a function of the memory controller chip (typically part of the core-logic chipset.)

If current 32-bit core-logic chipsets won't accept more than 1G per slot (and I don't know if this is actually true), it does not mean nobody can make such a chipset.
The maximum that consumer computers can handle is 4GB, but spread across four ram slots. I amy be wrong, (as there would currently be no need for so many 2GB sticks of ram), but that's what I recall.
This is also a function of design decisions by motherboard makers and chipset makers. It has nothing to do with the bit-width of the CPU.

As a matter of fact, 32-bit CPUs can support more than 4G of RAM. Intel Xeons have been doing this for a while (using a 36-bit address bus.) With a traditional operating system, each process is limited to 4G of virtual memory out of the 64GB total system capacity.

It should also be noted that Intel CPUs all support a segmented-addressing model that allows for a 48-bit virtual address space (16-bit segment, 32-bit offset - 256TB) Very few operating systems make use of this mode, because it is difficult to use efficiently, but the chip still supports it. On a chip that has more than 32 address lines (like a Xeon), this mode can allow single processes to have much more than 4GB of RAM.
If you actually check the tech specs of both Core Duo offerings from Apple, they both state a maximum of 2GB in total anyway.
True. But this isn't because the CPU is 32-bit. This is because of the number of memory slots, capacities of currently-shipping memory modules, and the core-logic chipset.

[jhu]

Not neccessarily. More bits isn't always better. First, for many applications like you mentioned (games, 3d modelling, etc) floating point operations are more useful.

In the Intel world, when they moved from 16-bit to 32-bit it was a big deal, mostly for the change from a segment-offset memory model to a flat 32-bit memory model. Here the ability to get access to > 4gb memory is the big deal, and they've been able to put in some hacks/shortcuts to work around this for several years.

Just to illustrate how 64-bit isn't always better, let's imagine doing an add for two 32-bit integers with the same values at the assembly (register) level:

00000000000000000000000000000001 +
00000000000000000000000000000010

versus 64-bit:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

For this simple add, the 64-bit int is more work and doesn't yield any benefit.



for other architectures this is true. on x86-64, however, things are never so simple. in 64-bit mode, the original 8 gp registers are accessed as 32-bit registers by default with zeroing of the upper 32-bits. however, the additional 8 gp registers can only be accessed as 64-bit registers. also, there are an additional 8 xmm registers in 64-bit mode.

[bigandy]

XP-64 supports EFI doesn't it?


no.

vista will have limited support, but no previous, or current, windows versions, have.

[Anonymous Freak]

The core-logic chipset (that controls the busses) is as much responsible for memory capacity as the physical number of sockets.
Indeed. And the 845PM chipset (http://developer.intel.com/products/chipsets/945pm/index.htm), as found in the iMac Core Duo (http://mactree.sannet.ne.jp/~kodawarisan/imac_intel/imac_intel01.html), supports up to 4 GB, and does support 512 mbit modules, which would be the common way to get 2 GB per module. (SO-DIMM anyway; you can squeeze 2 GB onto a desktop module with 256 mbit modules.)

Apple does have a history of under-documenting memory capacities. (e.g. the Bondi iMac, advertised with a 64M capacity per slot, but can actually accept 256M in each slot.) But this doesn't mean it will accept the largest modules that can physically fit in the slot (those same iMacs can not accept 512M or 1G SO-DIMMs.)
Very much so. SOME Bondi iMacs can support 512 MB modules, some can't. Reminds me of the SE/30, which supports 16 MB modules, even though that size wasn't even under development yet, so thinking of it supporting 128 MB of total memory wasn't even a thought in the engineers heads. (Yet I have 128 MB in my SE/30, which came out in 1989. And my iMac that came out in 1999 only came with 64 MB of RAM!)

[jhu]

no.

vista will have limited support, but no previous, or current, windows versions, have.

xp64 (http://www.microsoft.com/whdc/system/platform/64bit/64bitsystems.mspx#E6C) does support efi, otherwise itanium systems wouldn't be able to boot into windows.

[Anonymous Freak]

xp64 (http://www.microsoft.com/whdc/system/platform/64bit/64bitsystems.mspx#E6C) does support efi, otherwise itanium systems wouldn't be able to boot into windows.

Unfortunately, 'Windows XP 64-bit Edition' for Itanium systems is an absolutely different beast than 'Windows XP Professional x64 Edition', the AMD64/EM64T version.

It has been stated that the x64 Edition can boot on EFI systems, but the only systems that I have personally seen it on all use the BIOS Compatibilty Module, which makes an EFI system pretend it has a BIOS. This is because the system pretty much has to be compatible with the 32-bit version of XP, too, since not enough people are using x64 as their primary OS to warrant making a computer that is only compatible with the x64 version.

So while it is POSSIBLE that x64 is EFI compatible, I haven't yet seen proof of it.

[five minutes of Googling later...]

Well, after a bit of inspired Google-fu, I found the following MS TechNet article (http://technet2.microsoft.com/WindowsServer/en/Library/4b35160a-4e27-4258-9e8b-e2088f8a757a1033.mspx). In it, it has a grid of supported disk formats. MBR is what is used by BIOS systems, GPT is used by EFI systems. It shows that only Itanium systems can boot off GPT disks, but that any processor architecture running Windows Server 2003 SP1, and XP Pro x64 can use a GPT disk as a data disk. This means that an EFI-only (no BIOS Compatibility Module) x64 system cannot boot any current version of Windows. That means that even if Apple released an x64 Intel Mac (or if people were right, which they're not, about Core Duo being 64-bit,) you STILL couldn't boot Windows.

And here is a second article (http://technet2.microsoft.com/WindowsServer/en/Library/4b35160a-4e27-4258-9e8b-e2088f8a757a1033.mspx) specifically detailing that x64 systems can mount (in Server 2003 SP1 or XP x64,) but not boot from, GPT disks. Just as Itanium systems cannot boot from an MBR disk, but can use it as a data disk.

What is the point of being able to use a GPT disk as a data disk? Well, if you format a disk on an Itanium system, it would be nice to be able to read it on an x86 or x64 system. So they've implemented that in Pro x64 and Server 2003 SP1.

[shamino]

... TechNet article (http://technet2.microsoft.com/WindowsServer/en/Library/4b35160a-4e27-4258-9e8b-e2088f8a757a1033.mspx). ...
It shows that only Itanium systems can boot off GPT disks, but that any processor architecture running Windows Server 2003 SP1, and XP Pro x64 can use a GPT disk as a data disk. This means that an EFI-only (no BIOS Compatibility Module) x64 system cannot boot any current version of Windows. That means that even if Apple released an x64 Intel Mac (or if people were right, which they're not, about Core Duo being 64-bit,) you STILL couldn't boot Windows.
It means more than that. It also means that the OS doesn't have a problem with GPT, only the bootloader. And a GPT compatible bootloader has already been developed (for Itanium).

So although no currently-shipping distributions will boot on EFI, it would appear that all the hard work has already been done. Unless the code is really messed up (or written in assembly language), they should be able to just port the boot loader from Itanium to x64.

In other words, all it takes is some managers in MS to make a business decision to start supporting EFI boxes, and the developers should be able to get it up and running.

Of course, making that business decision may not be simple. Given the fact that most EFI PC's have a BIOS-compatible mode, there isn't a very compelling reason to develop a native EFI bootloader. Perhaps the desire to run on Mac hardware will be a reason. Or maybe not, if they decide porting VPC makes better business sense. (After all, a VPC customer buys a Windows license and a VPC license - meaning two sales instead of one.)

As for third parties doing the work, I don't know. Have any third parties made a bootloader (GRUB?) that can boot Windows without MS's OS Loader program? If such a program exists, then it should be modifiable to work with EFI, in much the same way that GRUB can boot Linux on EFI boxes.

I don't know of any such program. It may not exist, since (until now) there hasn't been any good reason for someone to develop a third-party OS Loader replacement.
And here is a second article (http://technet2.microsoft.com/WindowsServer/en/Library/4b35160a-4e27-4258-9e8b-e2088f8a757a1033.mspx) specifically detailing that x64 systems can mount (in Server 2003 SP1 or XP x64,) but not boot from, GPT disks. Just as Itanium systems cannot boot from an MBR disk, but can use it as a data disk.
See also this article (http://docs.info.apple.com/article.html?artnum=303220) and this article. (http://developer.apple.com/documentation/MacOSX/Conceptual/universal_binary/universal_binary_tips/chapter_5_section_10.html) Macs have the same issue. Intel Macs can mount, but not boot, APM-partitioned discs. And PPC Macs can not boot GPT disks. (I think PPC Macs running the latest Mac OS can mount GPT disks, but I'm not certain of that.)

[ChrisA]

32-bit processors require more than twice the number of cycles and registers to perform 64-bit processing, therefore with larger equations, a 64-bit processor will easily outperform a 32-bit. This is part of the reason the G5's have less cache than the G4's.

Question: How many bits wide was the floating point unit in the old Intel 386? How about in the 486 and in all the Pentiums and in the new Core Duo?

Answer 80 bits.

Intel has been doing 64-bit math from the beginning days of the PC era.

What defines a 64-bit processor is that this code (written
in C) will print the number "64";

void* foobar;
printf( sizeof(foobar) );

[Flynnstone]

There are (at least) three sizes of floating point ,32 bit, 64 bit and 80 bit.

A 64 bit processor would generally have 64 bit data and address paths.
It will have 64 bit address registers and 64 bit data registers.
Large data sets (>32bit) work well with 64 bit processors. Others have described this well.
If you are doing heavy Integer math (not floating point). Then the register size can matter.
If you are doing 32 bit integer math on a 64 bitter in 64 bit mode, then the 64 bitter will be slower because it has to move twice as much data around.
If you are doing 64 bit integer math, the 64 bitter can do this in (typically) one clock cycle. A 32 bitter needs to emulate to do 64 bit math. Adds, subtracts and multiplies I believe take 4 operations on 32 bitter versus 1 on a 64 bitter. This is the reason a 64 bitter is faster at 64 bit integer math.

[jhu]

There are (at least) three sizes of floating point ,32 bit, 64 bit and 80 bit.

A 64 bit processor would generally have 64 bit data and address paths.
It will have 64 bit address registers and 64 bit data registers.
Large data sets (>32bit) work well with 64 bit processors. Others have described this well.
If you are doing heavy Integer math (not floating point). Then the register size can matter.
If you are doing 32 bit integer math on a 64 bitter in 64 bit mode, then the 64 bitter will be slower because it has to move twice as much data around.
If you are doing 64 bit integer math, the 64 bitter can do this in (typically) one clock cycle. A 32 bitter needs to emulate to do 64 bit math. Adds, subtracts and multiplies I believe take 4 operations on 32 bitter versus 1 on a 64 bitter. This is the reason a 64 bitter is faster at 64 bit integer math.

almost. at least the above is true on practically every other 64-bit architecture. on x86-64, the default size for the original 8 registers is 32-bit. so that means 32-bit integer math is as fast in 64-bit mode as 32-bit mode. eg:

add eax,1 ; 32-bit operation which also zeroes out the upper 32-bits of rax
add rax,1 ; 64-bit operation

[shamino]

What defines a 64-bit processor is that this code (written
in C) will print the number "64";

void* foobar;
printf( sizeof(foobar) );
Actually, it will print "8".

[shamino]

A 64 bit processor would generally have 64 bit data and address paths.
Lots of 32-bit processors have this as well. The Pentium (and all its successors) have 64-bit data paths. The Xeon series has a 36-bit address path.
If you are doing 32 bit integer math on a 64 bitter in 64 bit mode, then the 64 bitter will be slower because it has to move twice as much data around.
Maybe, maybe not. The chip might perform 32-bit mov operations by transferring 64 bits and discarding half. Or it might have microcode to transfer only 32 bits. Depending on the architecture, either way might be faster.
If you are doing 64 bit integer math, the 64 bitter can do this in (typically) one clock cycle. A 32 bitter needs to emulate to do 64 bit math. Adds, subtracts and multiplies I believe take 4 operations on 32 bitter versus 1 on a 64 bitter. This is the reason a 64 bitter is faster at 64 bit integer math.
Again, this depends on the implementation. There's no reason why a chip can't have single operations that act on two registers. This was done in the 8-bit days on chips like the 6809 to allow 16-bit operations. There is no reason why a 32-bit chip can't do the same thing to allow 64-bit operations.

The real problem is that there is no clear definition of what it means to be a "64 bit processor". There are so many different aspects of this, and there are plenty of chips that implement some of these aspects without implementing others. Ultimately, the term is little more than marketing lingo.

There is no reason why a 32-bit chip can't access more than 4G of RAM (the Xeon does). There is no reason why a 32-bit chip can't do 64-bit math. There is no reason why a future 32-bit x86 chip can't increase the number of registers (one of the key reasons why AMD-64 chips can run apps faster in 64-bit mode) without going 64-bit. There is no reason why a 32-bit chip can't run with faster clocks, faster busses and larger caches (the key reason why a G5 is faster than a G4 for most applications.)

[drewd]

I think the maximum you can get into a single slot is 1GB with 32-bit processors. The maximum that consumer computers can handle is 4GB, but spread across four ram slots. I amy be wrong, (as there would currently be no need for so many 2GB sticks of ram), but that's what I recall.

If you actually check the tech specs of both Core Duo offerings from Apple, they both state a maximum of 2GB in total anyway.

A single slot can handle up to 2GB, assuming that enough address control lines are routed. It's not related to the bus width of the CPU. In fact, DDR and DDR2 both provide 64 bit data paths to and from the memory controller which, for 32 bit processors, eases the data bus bottleneck somewhat.

The 1GB per slot limit is almost always imposed by the memory controller not having enough address lines routed to support more than that amount. Besides, 2GB modules are pretty fabulously expensive right now. It's probably a purely economic thing.

[Flynnstone]

add eax,1 ; 32-bit operation which also zeroes out the upper 32-bits of rax
add rax,1 ; 64-bit operation

That's not 32/64 bit math. That incrementing.

On a 64 bitter, incrementing a 32 bit or 64 bit integer, the assembler is like:
add rax,1 ;same speed

On a 32 bitter, incrementing a 32 bit integer :
add eax,1 ; same speed
incrementing a 32 bit integer:
add eax,1
addc eax,1 ; or something like that (add with carry)

that is two instructions or have the speed.
This is all disregarding system issues like bus speed ...

[Mr. Mister]

I personally think it'll be quite a while before Apple starts offering 64-bit Intel Macs. I think they'll start with the Xserve, since those were where performance was particularly weak with the G5 procs (performance went down to a fourth of Dell servers when running Apache with high requests)

[jhu]

That's not 32/64 bit math. That incrementing.

On a 64 bitter, incrementing a 32 bit or 64 bit integer, the assembler is like:
add rax,1 ;same speed

On a 32 bitter, incrementing a 32 bit integer :
add eax,1 ; same speed
incrementing a 32 bit integer:
add eax,1
addc eax,1 ; or something like that (add with carry)

that is two instructions or have the speed.
This is all disregarding system issues like bus speed ...

i was referring to your statement:
If you are doing 32 bit integer math on a 64 bitter in 64 bit mode, then the 64 bitter will be slower because it has to move twice as much data around.

which is not true on x86-64 because in 64-bit mode instructions operate on the lower 32-bits of the original 8 general purpose registers unless explicitly appended (instructions involving the new registers always need to be appended). example in 64-bit long mode:

mov eax, 0 ;encodes to b8 00 00 00 00 - a 5 byte instruction
mov rax, 0 ;encodes to 48 b8 00 00 00 00 00 00 00 00 - a 10 byte instruction

so even on 32-bit instructions, the encoding is still smaller. additionally, the first instruction zeroes out the top 32-bits of rax (although a simple "xor rax,rax" (encodes 48 31 c0) is more efficient at only 3 bytes)

[shamino]

I personally think it'll be quite a while before Apple starts offering 64-bit Intel Macs. I think they'll start with the Xserve, since those were where performance was particularly weak with the G5 procs (performance went down to a fourth of Dell servers when running Apache with high requests)
If you're referring to the benchmarks I think you're referring to, then you are drawing incorrect conclusions. Those tests, when run on an Xserve running Linux, outperformed the Dells, indicating a problem with Mac OS, not the hardware.

Based on this, moving to Intel probably won't solve the problem.

[jhu]

If you're referring to the benchmarks I think you're referring to, then you are drawing incorrect conclusions. Those tests, when run on an Xserve running Linux, outperformed the Dells, indicating a problem with Mac OS, not the hardware.

Based on this, moving to Intel probably won't solve the problem.

actually the g5 still loses (http://anandtech.com/mac/showdoc.aspx?i=2520), but not as much as with os x.

[stefan15]

http://en.wikipedia.org/wiki/Intel_Core

Core Duo does not have native 64 bit nor EM64T in YONAH.

[twoodcc]

the question is, who is going to try to put a 2gb stick of ram in the new imac?

[Anonymous Freak]

the question is, who is going to try to put a 2gb stick of ram in the new imac?

I would, but I can't find any for less than 4 times the price of a 1 GB module. Sorry, I'm not willing to pay 16 times the cost for double the memory. (I'm getting 1 GB with my MacBook, and just bought a 1 GB module for $135 locally; if I was to upgrade to 2 GB modules, I would get two to keep dual-channel working. Two 2 GB modules would cost $2000, based on desktop prices.)

In fact, I can't even find 2 GB DDR2 SO-DIMMs, at any speed; much less the brand-new PC2-5300 (a.k.a. DDR2 667.) Not even DDR1. Desktop full-size DIMMs, yes, but not notebook SO-DIMMs. And the only desktop 2 GB PC2-5300 DIMMs I can find are server-quality, ECC modules, for $1000 each!

So, sorry; not any time soon.

[frazed]

Not neccessarily. More bits isn't always better. First, for many applications like you mentioned (games, 3d modelling, etc) floating point operations are more useful.

In the Intel world, when they moved from 16-bit to 32-bit it was a big deal, mostly for the change from a segment-offset memory model to a flat 32-bit memory model. Here the ability to get access to > 4gb memory is the big deal, and they've been able to put in some hacks/shortcuts to work around this for several years.

Just to illustrate how 64-bit isn't always better, let's imagine doing an add for two 32-bit integers with the same values at the assembly (register) level:

00000000000000000000000000000001 +
00000000000000000000000000000010

versus 64-bit:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

For this simple add, the 64-bit int is more work and doesn't yield any benefit.

Microsoft learned this lesson with Windows 95. Remember, they started with 16-bit Windows 3.1 and added 32-bit extensions to it. But the fact was that in many cases the 16-bit code was faster (partly due to years of optimization) so key parts of Windows 95's subsystem stayed 16-bit internally and used 32-bit thunking to talk to their 32-bit "other halves".


Given: 2 RISC CPUs of similar spec (Speed, Bus Speed, Cache Mode, Cache Speed etc..) One isa 32bit and the other 64bit.

Following on from the above, the 32Bit instruction (Op Code, Operand) Vs 64Bit instruction would essential execute with similar number of fetch-execute cycles if they where run on 32 Bit and 64 Bit CPUs respectively. However, as already pointed out Addressing More Memory (Operand) would be greater using 64 bit instructions. But when it comes to Floating Point Precision calculations (as in 3D rendering etc..) 64 Bit processors will out-perform there 32 bit CPUs on the fact that the CPU will compute 64 bit (quadword) in one+ cycle, whereas 32 bit CPUs would have to perform it in two+ more cycles...

***Note: the Intel x86 family are CISC and PowerPC are RISC. A True benchmark comparison is very difficult. If you have a certain application in mind such as Vector Processing, 3D rendering, Audio Synthesis. Then as was the case with the G5 CPU, the compiler optimisation would allow you to harness the chips best potential. At the moment if you are stuck with the Universal Binaires Nonsense, it's best to stick to a application that will harness one of the current cpus. So you might have to wait a for the Software companies to optimise there applications to run on Intel CPUs.

In my opinion there was nothing wrong with applications written on PowerPC cpus as they took advantage of the fact they where RISC processors and used them well (for vector based processing).

My benchmark is to see how long the phase the Power Mac G5 desktop!!!!

They won't rush on that one...

[mjstew33]

I personally think it'll be quite a while before Apple starts offering 64-bit Intel Macs. I think they'll start with the Xserve, since those were where performance was particularly weak with the G5 procs (performance went down to a fourth of Dell servers when running Apache with high requests)
I don't think so. I think it will be 4-5 months. Not quite a while. :rolleyes:

[Will : Hi !]

I just want to add something about the 2 GB limit (actually, the 1 GB limit per slot). It's obviously not due to 32-bit processors, and the chipsets used in the new Macintels seem to support up to 4 GB of memory, according to some posts.

Last time I wondered about putting 2 GB of RAM in Mac mini, all 2 GB sticks were ECC. That was a few months ago, but even now I can't seem to find 2 GB non-ECC modules on Crucial, which makes me believe that such RAM sticks still aren't available. <b>Edit :</b> I've found one when checking their advisor tool for the Quad G5 ... $1664 though :-)

Not so long ago, PowerMac G5s also had a limit of 1 GB per slot. Support for 2 GB modules came along with support for ECC modules. As far as I know, no PowerPC Macs except the Dual-core G5 towers and the Xserve support ECC RAM. It is possible that these Intel chipsets do not support ECC RAM ...

[Anonymous Freak]

Not so long ago, PowerMac G5s also had a limit of 1 GB per slot. Support for 2 GB modules came along with support for ECC modules. As far as I know, no PowerPC Macs except the Dual-core G5 towers and the Xserve support ECC RAM. It is possible that these Intel chipsets do not support ECC RAM ...

For some time, Intel's chipsets have ALLOWED ECC RAM, even if they didn't SUPPORT it. This means that you can put ECC RAM into an Intel board, and it will function just fine; although with ECC disabled.

The 2 GB limit on current Intel Macs stems from the fact that there are *ZERO* 2 GB DDR2-667 SO-DIMMs available right now. I found ONE 2 GB DDR-2 'full-size' DIMM, for $2000. That's it. (Hey, double-checking, it appears to be more popular now, I found THREE, the cheapest at $1000 per stick. Still no SO-DIMMs, though.)

Somewhere, in one of these threads, I link to an Intel document that shows that the chipset does have support for 2 GB DIMMs, we just need to wait for them to actually make it to the market.

[slooksterPSV]

Given: 2 RISC CPUs of similar spec (Speed, Bus Speed, Cache Mode, Cache Speed etc..) One isa 32bit and the other 64bit.

Following on from the above, the 32Bit instruction (Op Code, Operand) Vs 64Bit instruction would essential execute with similar number of fetch-execute cycles if they where run on 32 Bit and 64 Bit CPUs respectively. However, as already pointed out Addressing More Memory (Operand) would be greater using 64 bit instructions. But when it comes to Floating Point Precision calculations (as in 3D rendering etc..) 64 Bit processors will out-perform there 32 bit CPUs on the fact that the CPU will compute 64 bit (quadword) in one+ cycle, whereas 32 bit CPUs would have to perform it in two+ more cycles...

***Note: the Intel x86 family are CISC and PowerPC are RISC. A True benchmark comparison is very difficult. If you have a certain application in mind such as Vector Processing, 3D rendering, Audio Synthesis. Then as was the case with the G5 CPU, the compiler optimisation would allow you to harness the chips best potential. At the moment if you are stuck with the Universal Binaires Nonsense, it's best to stick to a application that will harness one of the current cpus. So you might have to wait a for the Software companies to optimise there applications to run on Intel CPUs.

In my opinion there was nothing wrong with applications written on PowerPC cpus as they took advantage of the fact they where RISC processors and used them well (for vector based processing).

My benchmark is to see how long the phase the Power Mac G5 desktop!!!!

They won't rush on that one...
Ooo, I forgot PPC is RISC while Intel is CISC, that explains why the Dual-Core Pentium 4's that my school got, doesn't do very well with Illustrator (even with 2GB memory, 256MB Video card), I swear a lot of functions are actually faster on my PPC computer than the Intel PC's. Yeah, I mean seriously you try them out and the PowerMacs and my iBook seem faster than the Dual-Core Pentium 4, 2.8GHz 2GB DDR400 SDRAM, 160GB, WinXP Pro. computers, seriously. Anyways:

32-bit vs 64-bit
Size addressment:
32-bit is a Postcard in Manhattan (64-bit). I think that was the analysis. 4GB vs. 16EB (exa-bytes) for memory addressing? something like that.

[Dominatus]

Ooo, I forgot PPC is RISC while Intel is CISC, that explains why the Dual-Core Pentium 4's that my school got, doesn't do very well with Illustrator (even with 2GB memory, 256MB Video card), I swear a lot of functions are actually faster on my PPC computer than the Intel PC's. Yeah, I mean seriously you try them out and the PowerMacs and my iBook seem faster than the Dual-Core Pentium 4, 2.8GHz 2GB DDR400 SDRAM, 160GB, WinXP Pro. computers, seriously. Anyways:

32-bit vs 64-bit
Size addressment:
32-bit is a Postcard in Manhattan (64-bit). I think that was the analysis. 4GB vs. 16EB (exa-bytes) for memory addressing? something like that.


The x86s CPUs themselves arent really CISC anymore. The instruction set itself is from the days of when they were CISC processors and that hasnt changed, but now adays the intructions are immediately decoded into small RISC like statements in the CPU before anything else. The CPU then executes those broken down instructions, not the original instruction like a CISC machine would do. This brings the modern x86 very close to RISC like performance.

[jhu]

***Note: the Intel x86 family are CISC and PowerPC are RISC. A True benchmark comparison is very difficult. If you have a certain application in mind such as Vector Processing, 3D rendering, Audio Synthesis. Then as was the case with the G5 CPU, the compiler optimisation would allow you to harness the chips best potential. At the moment if you are stuck with the Universal Binaires Nonsense, it's best to stick to a application that will harness one of the current cpus. So you might have to wait a for the Software companies to optimise there applications to run on Intel CPUs.

if all you want to do is test raw processing power, it's not that difficult. you can write, for example, a small program that calculates a slew of fast fourier transforms to test the fpu. as long as the source code is available, performance tests between architectures is feasible. just take a look at the specint or specfp tests.


In my opinion there was nothing wrong with applications written on PowerPC cpus as they took advantage of the fact they where RISC processors and used them well (for vector based processing).


the only problem with altivec is that it only does single-precision floating point, unlike sse2 which can do double-precision floating point.

[wms121]

..for those who think Sun has everything:

http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/3BBB27E5BCC165BA87256A2B0064FFB4/$file/128bitPlbBus.pdf

..YES Solaris 10 is FREE!!!.

But so are Cell Processor emulators* IF you register at IBM as a biz customer.

MacOSX 10.3 and 1.41 GHz chip clock speed with a minimum of 1 GB RAM required to run the simulator.

*(search IBM.com for "cell simulator"..lots of links..including the "custom supercomputing software..YES they have ppc versions..!!")

Mercury Computer has "Infiniband modules" with the first Cell plugins:

http://www.mc.com

YES this is why I post on the "64-bit who really cares pages?"...because Intel
can't do these "Next Gen" steps all by themselves. We will need ALL the computer companies working in unison..including Apple and Mr. Steve Jobs..to
stay competitive beyond 2010.

Hyperspace Drives are coming:

http://www.defensetech.org/archives/002065.html

WW

(moto we still luv you...get us a 128 bit chip and we will talk to Steve ; )

[jhu]

..for those who think Sun has everything:

http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/3BBB27E5BCC165BA87256A2B0064FFB4/$file/128bitPlbBus.pdf

..YES Solaris 10 is FREE!!!.

But so are Cell Processor emulators* IF you register at IBM as a biz customer.

MacOSX 10.3 and 1.41 GHz chip clock speed with a minimum of 1 GB RAM required to run the simulator.

*(search IBM.com for "cell simulator"..lots of links..including the "custom supercomputing software..YES they have ppc versions..!!")

Mercury Computer has "Infiniband modules" with the first Cell plugins:

http://www.mc.com

YES this is why I post on the "64-bit who really cares pages?"...because Intel
can't do these "Next Gen" steps all by themselves. We will need ALL the computer companies working in unison..including Apple and Mr. Steve Jobs..to
stay competitive beyond 2010.

Hyperspace Drives are coming:

http://www.defensetech.org/archives/002065.html

WW

(moto we still luv you...get us a 128 bit chip and we will talk to Steve ; )

OMG!!! Ponies!!!

[slooksterPSV]

The x86s CPUs themselves arent really CISC anymore. The instruction set itself is from the days of when they were CISC processors and that hasnt changed, but now adays the intructions are immediately decoded into small RISC like statements in the CPU before anything else. The CPU then executes those broken down instructions, not the original instruction like a CISC machine would do. This brings the modern x86 very close to RISC like performance.
Not good enough for me. When performance is everything, Mac wins. A compressed version of RISC, or minor-risc of cisc isn't good enough for me. CISC is CISC even if its 99.999% RISC IMO, still, I wonder how much faster any of the computers would be if they had RISC instead of CISC w/RISC Chopped down Instructions. - -sorry can't think of a better way to phrase that.

[slooksterPSV]

..for those who think Sun has everything:

http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/3BBB27E5BCC165BA87256A2B0064FFB4/$file/128bitPlbBus.pdf

..YES Solaris 10 is FREE!!!.

But so are Cell Processor emulators* IF you register at IBM as a biz customer.

MacOSX 10.3 and 1.41 GHz chip clock speed with a minimum of 1 GB RAM required to run the simulator.

*(search IBM.com for "cell simulator"..lots of links..including the "custom supercomputing software..YES they have ppc versions..!!")

Mercury Computer has "Infiniband modules" with the first Cell plugins:

http://www.mc.com

YES this is why I post on the "64-bit who really cares pages?"...because Intel
can't do these "Next Gen" steps all by themselves. We will need ALL the computer companies working in unison..including Apple and Mr. Steve Jobs..to
stay competitive beyond 2010.

Hyperspace Drives are coming:

http://www.defensetech.org/archives/002065.html

WW

(moto we still luv you...get us a 128 bit chip and we will talk to Steve ; )
So is Apple going to use this technology, provided IBM let them, to enable virtualization such as Xen virtualization with Linux? That'd be awesome if this was the technology to do so.

[dr_lha]

... the compiler optimisation would allow you to harness the chips best potential. At the moment if you are stuck with the Universal Binaires Nonsense, it's best to stick to a application that will harness one of the current cpus...
I fail to see how Universal Binaries has any affect here on optimisation, or why its "Nonsense". I really think you have no idea what Universal Binaries are.

[jhu]

Not good enough for me. When performance is everything, Mac wins. A compressed version of RISC, or minor-risc of cisc isn't good enough for me. CISC is CISC even if its 99.999% RISC IMO, still, I wonder how much faster any of the computers would be if they had RISC instead of CISC w/RISC Chopped down Instructions. - -sorry can't think of a better way to phrase that.

hmmm... you really don't know what you're talking about. that's why apple stayed with powerpc, right? additionally, cisc and risc are now out-dated terms whereby current processors, be it x86, powerpc, sparc, etc transcend the original cisc/risc definitions.

[notjustjay]

CISC is CISC even if its 99.999% RISC IMO, still, I wonder how much faster any of the computers would be if they had RISC instead of CISC w/RISC Chopped down Instructions.

This makes no sense, particularly if you've studied (a) how CPUs work, (b) assembly language, and (c) how compilers work.

Just because a native Spanish speaking person happens to have a translator friend help you translate your English into Spanish doesn't make her any less fluent in Spanish than any other Spanish speaker.

[wms121]

http://www.mc.com/products/view/index.cfm?id=96&type=boards

..THIS is why we need Intel.

The support chips for manufacturing something like this type of server
for Apple are almost entirely Intel based...at least for mass production.

Apple could always do a "micro-custom" shop version of things..but Steve
won't let them..his industry partners..the 'nice little companies' who help out
Apple and several other major computer manufacturers from time to time
(ahem..LIKE IBM)..need to allow the "little guys" their wiggle room.

More reasons to watch the Intel what is what isn't 64 bit discussing paradigm..the SUPPORT CHIPS ..are what drive these industries..and pays
off the bottom lines..for various industries..gamers..support the MIL-SPEC
crowd ALL THE TIME.

What ponies?

Just saw one little girl in pink shorts...she was from marketing.

WW

[chatin]

http://www.mc.com/products/view/index.cfm?id=96&type=boards

..THIS is why we need Intel.

Just saw one little girl in pink shorts...she was from marketing.


Does this person work for Apple? The current crop of chips are essentially two Pentium III's squeezed together on the same die.

AMD set the way 64-bit will be implemented (MS backed the AMD64 standard. much to Intel's shock and horror) back in 2003, so it's no wonder Intel is struggling.

The 65nm process will help, but there seems to be a problem here.

;)

[MacCoaster]

Question: How many bits wide was the floating point unit in the old Intel 386? How about in the 486 and in all the Pentiums and in the new Core Duo?

Answer 80 bits.

Intel has been doing 64-bit math from the beginning days of the PC era.

What defines a 64-bit processor is that this code (written
in C) will print the number "64";

void* foobar;
printf( sizeof(foobar) );
Eh? That's just a void pointer. Meaningless. A ppc64 binary on Mac OS X will print "4" for this. C does not define the length of a pointer (or an integer, etc.) so doing this is pointless to 'find out' the bits of a processor.

[slooksterPSV]

This makes no sense, particularly if you've studied (a) how CPUs work, (b) assembly language, and (c) how compilers work.

Just because a native Spanish speaking person happens to have a translator friend help you translate your English into Spanish doesn't make her any less fluent in Spanish than any other Spanish speaker.
True; types CISC and RISC are long gone, its now about speed, core, motherboard, chipset, bridges, etc. AMD is still better though. Hehe.

[wmmk]

sometimes computer companies just dont wanna overwhelm us

[Eniregnat]

what would be the point of hiding these capabilities?

Not hiding, just not enabling. If the chip doesn’t reliably work at 64bit, then it would make sense not to enable it to do so. Likely the structures needed to support 64bit, if present, need refined.

[generik]

Not good enough for me. When performance is everything, Mac wins. A compressed version of RISC, or minor-risc of cisc isn't good enough for me. CISC is CISC even if its 99.999% RISC IMO,

Do you even understand what your statement means?

Instead of buying into the petard hoisted by Apple's marketing department do you seriously have the slightest understanding of these buzzwords you just quoted?

[XFce]

Apple is starting to act a lot like like Microsoft.
Spend three grand on a brand new Apple I Mac Intel core duo loaded with all the latest and greatest technology. Then three months down the road, Apple announces that they are in the process of releasing a brand New Apple computer that supports 64 bit technology, plays games etc etc. The Macintels we have right now will depreciate in value anywhere from one thousand dollars on up if Apple continuities to compete with Microsoft windblows.

[milo]

Apple is starting to act a lot like like Microsoft.
Spend three grand on a brand new Apple I Mac Intel core duo loaded with all the latest and greatest technology. Then three months down the road, Apple announces that they are in the process of releasing a brand New Apple computer that supports 64 bit technology, plays games etc etc. The Macintels we have right now will depreciate in value anywhere from one thousand dollars on up if Apple continuities to compete with Microsoft windblows.

A new computer being outdated by newer models? Egads, such a thing is unheard of in the computer industry!

[Anonymous Freak]

Apple is starting to act a lot like like Microsoft.
Spend three grand on a brand new Apple I Mac Intel core duo loaded with all the latest and greatest technology. Then three months down the road, Apple announces that they are in the process of releasing a brand New Apple computer that supports 64 bit technology, plays games etc etc. The Macintels we have right now will depreciate in value anywhere from one thousand dollars on up if Apple continuities to compete with Microsoft windblows.

First, even COMPLETELY decked out, with pre-installed iWork, and AppleCare, the iMac (not I Mac) onlly comes to $2700. If you leave off AppleCare, and the non-internal-hardware upgrades, you're only at $2400.

Second, Intel's new chips are at least 5 months away, probably 6.

Third, I can play games just peachy on my MacBook Pro. I don't need the new chips for that. LEGO Star Wars, World of Warcraft, DooM 3 in Mac OS; Half-Life 2, Dungeons & Dragons Online, and Quake 4 in Windows. (Yeah, I bought the Windows one first, I wasn't about to shell out for the Mac one, too.)

Fourth, EVERY computer depreciates $1000 or more 9 months after its release. Apple's have held their resale value significantly better than the majority of PCs. (A $1299 iMac from 1998 still sells for $100+. Show me one desktop PC, of any initial price, from 1998 that would sell for more than $50. And G4 Mac mini's, which are now, by your definition, completely obsolete, sell for only $100 less than the Intel minis.)

[jhu]

Fourth, EVERY computer depreciates $1000 or more 9 months after its release. Apple's have held their resale value significantly better than the majority of PCs. (A $1299 iMac from 1998 still sells for $100+. Show me one desktop PC, of any initial price, from 1998 that would sell for more than $50. And G4 Mac mini's, which are now, by your definition, completely obsolete, sell for only $100 less than the Intel minis.)

that has more to do with supply and demand, but mostly supply. you can say the same thing about dec multias, sun ultrasparc workstations, sgi irix workstations, etc.

[ReanimationLP]

No, there is NO 64-bit in the Core Duo.

Besides, Intel doesnt have 64-bit technology.

Their EM64T is really actually AMD64 tech.

[jhu]

No, there is NO 64-bit in the Core Duo.

Besides, Intel doesnt have 64-bit technology.

Their EM64T is really actually AMD64 tech.

intel has ia64 which no one is really using. they also have alpha, which they bought just kill. then theres emt64, which although it is just rebadged amd64, is still a 64-bit architecture.

[wms121]

http://search.motorola.com/query.html?col=corp&col=pcs&qt=%2264+bit+processor%22&charset=iso-8859-1&Submit.x=4&Submit.y=7


...any questions?

WW

(..ahem my apologies, IBM...gee ask Marketing what happened..your
note is on the 20th page:

http://www.motorola.com/mot/doc/1/1448_MotDoc.pdf )

[Catfish_Man]

Their EM64T is really actually AMD64 tech.

It's a specification, not a technology. The tech is involved in the implementation of the instruction set, which is most certainly specific to the chip and the manufacturer, not shared between companies. AMD did a great job in creating the x86-64 spec, making the first implementation, and making it a success, though.

Hysteria, FUD, Misinformation, and lack of common sense, with the occasional attempt to set things right

Let's see, we've had
"The magic powers of RISC will overcome any other disadvantage",
"64 bit makes things way faster",
"Apple should make computers that never become obsolete",
"Intel stole AMD's tech",
"CoreDuo is just a Pentium 3",
"Companies are hiding secret features from us because they hate us",
and one I'd never heard before "Universal binaries can't be optimized"....

Congrats, people. That's actually quite a good percentage of the incorrect* whining about the Intel switch I've heard on the net, compressed into one thread, and even a new addition!


*there's been some correct whining as well, but I didn't see much of it here.

[localnet]

I don't even know of any software that is even 64 bit native, at least nothing I use now.

Mike

[chatin]

64-bit does make things run much faster, and core duo is definitly not 64-bit.

I just replaced a mac mini 1.4 (with 1GB RAM) with a core duo mini (512MB). The core duo seemed to boot and run slower. Possibly, because of Rosetta emulation.

$800 wasted on an upgrade. (For now, until I get 2GB 667mhz memory!) No real world performance boost. (For now, until everything goes universal!)

:)

[Catfish_Man]

I don't even know of any software that is even 64 bit native, at least nothing I use now.

Mike

Mathematica is. OSX doesn't support 64 bit software with a GUI though, so it has to run as two separate programs; a 32 bit GUI and a 64 bit core.

[Anonymous Freak]

64-bit does make things run much faster, and core duo is definitly not 64-bit.

I just replaced a mac mini 1.4 (with 1GB RAM) with a core duo mini (512MB). The core duo seemed to boot and run slower. Possibly, because of Rosetta emulation.

$800 wasted on an upgrade. (For now, until I get 2GB 667mhz memory!) No real world performance boost. (For now, until everything goes universal!)

:)

Well, G4 in your previous mini wasn't 64-bit, either. And the entire OS, plus every single Apple program, are 100% native, no Rosetta involved. Now, if you're talking about games, or Photoshop, then correct, Rosetta would be involved (plus the graphics chip being a little slower,) would make the Intel mini slower than a PPC mini. But only for non-native apps! (Heck, my MacBook Pro is faster through Rosetta than my 1.25 GHz eMac native.)

As for 64-bit automatically making things run 'much faster'. Bollocks. In PPC, the mere addition of 64-bitness doesn't do squat. What makes the G5 way faster than G4 is the vastly superior PLATFORM. If a dual, 2.5 GHz dual-core G4 were placed on a 1/2 speed system bus (1.25 GHz,) rather than the 166MHz it topped out at, and with a dual-channel DDR2 memory controller, it would be just as fast as a G5. The ONLY thing 64-bit adds in PPC is the ability to address more than 4 GB of memory per process. (The technology already exists to have the whole SYSTEM address over 4 GB, even on a 32-bit system, so the only benefit of 64-bit now is for more than 4 GB to an individual process.)

Now, on x86, on the other hand... There is a tangible, but slight, benefit to moving to 64-bit. This comes from the fact that the x86-64 architecture (or AMD64, or EM64T, if you prefer; they all mean the same thing,) has more registers than the 32-bit x86 architecture. This can give a small but measurable speed boost. (We're talking 5%, tops.) And this only applies for 64-bit applications. Unlike PPC's 64-bit implementation, which allows 32-bit applications to run side-by-side with 64-bit with ZERO performance hit, x86 processors must be running entirely in 64-bit mode, or entirely in 32-bit mode. This means that if you are running in 64-bit mode, software has to translate your older 32-bit apps into 64-bit datastreams and instructions. It's not MUCH of a hit, but there is a hit. (Again, about 5%.) This means that running a 64-bit OS, you GAIN up to 5% running 64-bit apps, but LOSE up to 5% running 32-bit apps.

And note that on both of these, 5% appears to be the MAX performance difference (aside from badly written 32-bit programs in 64-bit OS, which lose more.) So even on x86, adding 64-bit won't make that big a difference. (I have a 64-bit Windows machine, and dual boot 32-bit and 64-bit Windows, mostly for testing purposes. I have yet to 'feel' any difference in speed, even doing processor intensive things.)

We might see more of a performance boost in Mac OS, simply because of refinements to the OS since Apple can write to a specific set of hardware, but I have a feeling that the 'desktop' Mac OS will stay 32-bit for the forseeable future, simply because they can't alienate all the Yonah purchasers. (Again, unlike PPC, where you can have both 32-bit and 64-bit compatibility side by side easily, on x86, it's an either/or thing, and takes a bit of work to compile for both.)

[jhu]

Now, on x86, on the other hand... There is a tangible, but slight, benefit to moving to 64-bit. This comes from the fact that the x86-64 architecture (or AMD64, or EM64T, if you prefer; they all mean the same thing,) has more registers than the 32-bit x86 architecture. This can give a small but measurable speed boost. (We're talking 5%, tops.) And this only applies for 64-bit applications. Unlike PPC's 64-bit implementation, which allows 32-bit applications to run side-by-side with 64-bit with ZERO performance hit, x86 processors must be running entirely in 64-bit mode, or entirely in 32-bit mode. This means that if you are running in 64-bit mode, software has to translate your older 32-bit apps into 64-bit datastreams and instructions. It's not MUCH of a hit, but there is a hit. (Again, about 5%.) This means that running a 64-bit OS, you GAIN up to 5% running 64-bit apps, but LOSE up to 5% running 32-bit apps.

And note that on both of these, 5% appears to be the MAX performance difference (aside from badly written 32-bit programs in 64-bit OS, which lose more.) So even on x86, adding 64-bit won't make that big a difference. (I have a 64-bit Windows machine, and dual boot 32-bit and 64-bit Windows, mostly for testing purposes. I have yet to 'feel' any difference in speed, even doing processor intensive things.)



i'm going to take issue with the "5% at most" performance boost. i compiled povray (http://www.povray.org) for a few of my computers and ran the benchmark.pov scene. the compiler used was gcc 3.4. here are the results:

duron 1.6 ghz:
Time For Parse: 0 hours 0 minutes 3.0 seconds (3 seconds)
Time For Photon: 0 hours 0 minutes 60.0 seconds (60 seconds)
Time For Trace: 0 hours 39 minutes 43.0 seconds (2383 seconds)
Total Time: 0 hours 40 minutes 46.0 seconds (2446 seconds)

sempron 1.6 ghz, 32-bit kernel, 32-bit program
Time For Parse: 0 hours 0 minutes 3.0 seconds (3 seconds)
Time For Photon: 0 hours 0 minutes 53.0 seconds (53 seconds)
Time For Trace: 0 hours 33 minutes 45.0 seconds (2025 seconds)
Total Time: 0 hours 34 minutes 41.0 seconds (2081 seconds)

sempron 1.6 ghz, 64-bit kernel, 32-bit program
Parse Time: 0 hours 0 minutes 2 seconds (2 seconds)
Photon Time: 0 hours 0 minutes 49 seconds (49 seconds)
Render Time: 0 hours 35 minutes 50 seconds (2150 seconds)
Total Time: 0 hours 36 minutes 41 seconds (2201 seconds)

sempron 1.6 ghz, 64-bit kernel, 64-bit program
Parse Time: 0 hours 0 minutes 1 seconds (1 seconds)
Photon Time: 0 hours 0 minutes 41 seconds (41 seconds)
Render Time: 0 hours 28 minutes 45 seconds (1725 seconds)
Total Time: 0 hours 29 minutes 27 seconds (1767 seconds)

as you can see, the difference between the decrease in render time between 64-bit and 32-bit povray is ~15%

[Anonymous Freak]

i'm going to take issue with the "5% at most" performance boost. i compiled povray (http://www.povray.org) for a few of my computers and ran the benchmark.pov scene. the compiler used was gcc 3.4. here are the results:

Hrm, interesting... I had seen a few benchmarks once upon a time that only showed 5%. Doing some further searching does, indeed reveal 15-20% speed boosts in limited, processor-only tasks. (Rendering was one, like yours, that benefits the most; media encoding also has a 10-15% increase. Others had 5% tops increase, and one even had a decrease.)

So I stand corrected. It appears that some tasks DO benefit more than 5%. BUT, it still won't give you a 'much faster' experience. The core OS, and 'general responsiveness' are improved sigificantly more by moving to dual processors (or dual core,) than by moving to 64-bit. (Compare an old dual G4 500MHz to a 1.25 GHz G4, and you'll find the dual 'feels' faster in everyday use, even though the faster single will finish many processor intensive tasks faster.)

[wms121]

...Core Duo? Nahh..keep 'em guessin' Intel...but how 'bout this thing?

http://www.isi.edu/~draper/papers/esscirc02.pdf

They say it is "Ultra Wide Word" addressable...not sure I want to be the
consultant who has to "sell one" when they ask* you 'IS IT OR ISN'T IT'?

I guess you could "make it one"..lessee..you order from Intel's custom ASIC
shop..then..you ask Motorola for one of their memory controller packages..then,

...hmmm.

Come one Intel..fess up on the chip...let's let Arn shut this thread down.

Anyone out there have Andy Grove's personal email address?

WW

*(..okokok a "256-bit processor"..no ponies..just bytes)

[WeeManDan]

As a side note, The Sossaman based CPU's would seem an obvious choise for XServes. Anyone want to start a rumor about when the "iServe" will ship?

Lol, wouldn't it be a MacServe though lol :p

[jhu]

Hrm, interesting... I had seen a few benchmarks once upon a time that only showed 5%. Doing some further searching does, indeed reveal 15-20% speed boosts in limited, processor-only tasks. (Rendering was one, like yours, that benefits the most; media encoding also has a 10-15% increase. Others had 5% tops increase, and one even had a decrease.)


do you have any links? at least for amd64 processors, i can't really imagine how there could be a decrease in performance unless the code is just large enough not to fit into the l1/l2 caches versus their 32-bit counterpart, or they're running a 32-bit program with a 64-bit kernel.

btw, added results for 64-bit kernel and 32-bit povray program in my prior post. indeed there is a measurable performance loss (although i don't notice a thing playing doom 3).

[Anonymous Freak]

do you have any links? at least for amd64 processors, i can't really imagine how there could be a decrease in performance unless the code is just large enough not to fit into the l1/l2 caches versus their 32-bit counterpart, or they're running a 32-bit program with a 64-bit kernel.

btw, added results for 64-bit kernel and 32-bit povray program in my prior post. indeed there is a measurable performance loss (although i don't notice a thing playing doom 3).

Yeah, povray was the main decrease. It's mostly from the overhead of 'padding' 32-bit to fit in the 64-bit registers. Not a huge hit, but measurable. (Unlike PPC, which can effortlessly switch between 32-bit and 64-bit data and instructions.) And, yes, the performance hit was only 32-bit apps in 64-bit OSes. The hit was over both 32-bit/32-bit and 64-bit/64-bit.

[wms121]

http://www.cs.utexas.edu/~trips/quad_charts/quad2005.pdf

..maybe Intel has other options they can't tell Steve about.

Like a "Infiniband Server onna chip" Steve?

Anyone know the real reason Avie left?

Can't be "lack of technology" capabilities.

Maybe they were going to make anal cell chips..for mobile medical needs..
..and wanted early adopter volunteers?

<--is going home now

[evangelion-01]

were ppc 64bit?

[Eidorian]

were ppc 64bit?Yeah, the 970 (G5) series was.

[slooksterPSV]

were ppc 64bit?
Worlds first 64-bit personal computer was a Mac.

[Anonymous Freak]

Worlds first 64-bit personal computer was a Mac.

Or so Apple claimed...

They claimed first because while AMD had their 64-bit Opteron out already, AMD advertised it as a server and workstation chip. It did end up in what were very much 'desktop personal computers' rather than 'workstations', and those same people claimed that Apple's Power Macs were advertised and targeted as 'workstations' rather than 'desktop personal computers'.

I think the whole claim is pointless, since there is no truly 'useful' purpose for 64-bit on a 'personal computer' at the moment. (If you really do need more than 4 GB of RAM, or process 64-bit data, then you need a computer more appropriately classified as a 'workstation', anyway.)

Of course, at the time of both the G5 and the Opteron's releases, Linux was the only OS that could properly take advantage of either one's 64-bit-ness. (Apple released a 64-bit-happy version of OS X sooner than Microsoft released 'Windows XP Professional for 64-bit Extended Systems', at least.)

[deadkenny]

When I boot into Windows XP on my MacBook it sais "Intel 2500 something" with "Physical Adress Enhacement" (roughly translated from german) - so I guess it can adress 64bit adresses. To bad that there aren't SO-DIMMS larger than 2GB each - so no way to test wether the MacBook actually can be run with more than 4GB (which is the 32bit limit).
The handbook sais that the MacBook is limited to 2GB anyway.

[Shadow]

There are 2GB RAM modules for MacBook (ie they could work), but they arnt supported because of the firmware. Also they are really really expensive.

[janstett]

Worlds first 64-bit personal computer was a Mac.

Technically, in addition to AMD beating it to the punch as someone else pointed out, the DEC Alpha was Waaaaaaaaay ahead of the PPC. Of course, you can argue pro and con on whether the Alpha qualifies as a "Personal Computer". It wasn't average consumer fare but it was supported by a major company, cost less than $10k, and ran Windows NT.

[netdog]

the Alpha...ran Windows NT.

...sort of.

[dernhelm]

...sort of.

... and NT was not marketed as a desktop operating system. It was for the server room back in the day.

Alpha chips also run Dec UNIX quite well in fact - and were amazingly fast in their heyday.

[wms121]

..recent papers:


http://www.cs.ubc.ca/~kevinlb/teaching/cs532a%20-%202006/Projects/SaraForghanizadeh.pdf

http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15740-f03/public/doc/discussions/multiprocessors/parprocs/grid.pdf

http://domino.research.ibm.com/acas/w3www_acas.nsf/images/proposals_01.02/$FILE/keckler.pdf

..okokok..what does this mean?

Means..Intel be draggin' the waggin'...they gonna repeat what MOTO did
unless IBM helps them out..

...now you know why "IBM said 'ok mr. steve..you go play with the nice
Intel boyz...'".

There are no conspiracy theories for processor decisions..just advance
avatar marketing judgements.

Someone please tell the shareholders.

WW

<--will meet you at the Apple Store for a Haagen Daz cone

[Anonymous Freak]

When I boot into Windows XP on my MacBook it sais "Intel 2500 something" with "Physical Adress Enhacement" (roughly translated from german) - so I guess it can adress 64bit adresses. To bad that there aren't SO-DIMMS larger than 2GB each - so no way to test wether the MacBook actually can be run with more than 4GB (which is the 32bit limit).
The handbook sais that the MacBook is limited to 2GB anyway.

The 2.0 GHz Core Duo is referred to by Intel as the "Intel Core Duo processor T2500", and 'Physical Address Extension' is a trick for making 32-bit processors capable of addressing more than 4 GB of RAM. It is slow, and it is done with processor/chipset trickery. And even then, a single process can only address 4 GB of RAM. It has been in use in x86 servers for years. (I worked for Intel's server division in '99-2000, and we had a 8-way Pentium III Xeon system that supported up to 32 GB of RAM using this technology.)

Intel calls native 64-bit processors as having 'EM64T' (Extended Memory 64-bit Technology)

And as for:
and NT was not marketed as a desktop operating system. It was for the server room back in the day.
NT had a 'Workstation' version that the Alpha was marketed toward. However, even when run on Alpha or MIPS 64-bit processors, NT was still only 32-bit. (There was even a PowerPC version of NT for a while.) Alpha had the longest life of any of these alternate platforms, lasting all the way through NT 4.0's run. (The MIPS and PowerPC versions were canned before NT 4.0 finished it's run; Alpha and x86 are the only two platforms that made it all the way to Service Pack 6a.)

[Mac Rules]

So will Merom, Conroe and Woodcrest be 64-bit? Also will leopard support 64-bit processing like Windows XP 64 for example. I'm really looking fo rthe new MBP to be 64-bit, it should increase the speed quite dramatically right?

Cheers:cool:

EDIT: Will the new MBP be able to take 4Gb of RAM?

[Silentwave]

So will Merom, Conroe and Woodcrest be 64-bit? Also will leopard support 64-bit processing like Windows XP 64 for example. I'm really looking fo rthe new MBP to be 64-bit, it should increase the speed quite dramatically right?

Cheers:cool:

EDIT: Will the new MBP be able to take 4Gb of RAM?

ok: MCW 64 bit? YES
Leopard? unknown
dramatic speed boost? I think it depends on your apps among other things, but don't quote me. In real terms expect 20% more performance from merom versus core duo Yonah.

and for the edit question about MBP ram, unknown, but all it depends on is whether or not they can get cheap 2GB DIMMs or have space for more RAM slots.

[Catfish_Man]

Leopard will be 64 bit, judging by recent entries on the WebKit changelog (fixes for building with 64 bit AGL, etc...)

[janstett]

NT had a 'Workstation' version that the Alpha was marketed toward. However, even when run on Alpha or MIPS 64-bit processors, NT was still only 32-bit. (There was even a PowerPC version of NT for a while.) Alpha had the longest life of any of these alternate platforms, lasting all the way through NT 4.0's run. (The MIPS and PowerPC versions were canned before NT 4.0 finished it's run; Alpha and x86 are the only two platforms that made it all the way to Service Pack 6a.)

Yep... But don't forget new versions did come around to today's XP -- 64 bit versions for Itanium and EMT64.

and NT was not marketed as a desktop operating system. It was for the server room back in the day.


Not really. NT Workstation was meant for the power users, NT Server was for the backroom. NT became Win2K which became XP which becomes Vista. I used Windows NT 3.1 back in 1992.

[wms121]

..from the Register last year:

http://www.theregister.co.uk/2005/02/03/cell_analysis_part_two/

Has any of this changed?

Sun is waiting for a "software paradigm shift"..and is using AMD 64's in the
new "Web Servers" (or whatever those boxes are).

Why don't they use the Intel Itaniums?

Why doesn't Apple use an "Itanium" (gee..Steve..where is my iToaster?)

Why does this site argue about whether or not something is "really 64 bit"?

Don't they want to tell us?

Gee..wonder why.

WW

<---ok 2 cones..and a trip the Dallas West End

[Catfish_Man]

..from the Register last year:

http://www.theregister.co.uk/2005/02/03/cell_analysis_part_two/

Has any of this changed?

Sun is waiting for a "software paradigm shift"..and is using AMD 64's in the
new "Web Servers" (or whatever those boxes are).

Sun has its new massively multithreaded Niagara chip on the market now, and it's kicking butt in some markets.


Why don't they use the Intel Itaniums?

Because Intel is their competitor.


Why doesn't Apple use an "Itanium" (gee..Steve..where is my iToaster?)

Because that would be retarded. Itanium chips cost as much as entire Macs do, or more.


Why does this site argue about whether or not something is "really 64 bit"?

Because it's relatively complex, and many people have no idea what they're talking about.


Don't they want to tell us?

Who is they? What is it that they supposedly want to tell us?


Overall, your post was remarkably incoherent.

[janstett]

Why don't they use the Intel Itaniums?

Why doesn't Apple use an "Itanium" (gee..Steve..where is my iToaster?)


Itanium is proving to be a dead end. Intel launched it years ago (IIRC around 98-2000) and it was so different from the existing architecture that you might as well treat it like an entirely different chip from X86 like a DEC Alpha, and as a result expensive, and nobody wants to adopt it. The AMD and Intel X64/EMT64 chips are different in 64-bit mode but can still work with 32-bit operating systems, that's not the case with Itanium. So it's a hard-switch to adopt Itanium. I think it will die and the X64 chips will live on. Like the 286->386 transition, the 386 could still just be used as a fast 286 until the 386-aware operating systems were ready for prime time. Similar with the X64 chips, there is a 64-bit XP but it's painful to use because there aren't any 64-bit apps and you need brand new 64-bit drivers... Thus 64-bit XP is an interesting experiement but not ready for prime time yet. So you use your X64 chip to run good old 32-bit OS's.

[wms121]

http://www.sun.com/servers/coolthreads/overview/docs/Gartner_report.pdf

..they are T1 based thread switching systems.

Apple knows something.

WW

<--don't wake up again

[Anonymous Freak]

Because that would be retarded. Itanium chips cost as much as entire Macs do, or more.

The cheapest of the new dual-core Itanium 2 9000-series chips is only $696 (even this 'cheap' model has 6 MB of cache,) compared to the Core-based Xeon 5100 series' cheapest $256, and Core 2 Duo's $183. (For comparison, the upcoming NetBurst-based Xeon 7100 series' cheapest is $856.) Compare the MOST expensive chips in each line: Itanium 2: $3692 (this one has a whopping 24MB of cache!) Core Xeon 5100 series: $851, Core 2 Extreme: $999, Netburst Xeon 7100 series: $3157 (With only 16 MB of cahce.)

So you can see that Itanium 2 is reasonably priced in comparison to Intel's own Xeon 7100 series. (Both are targeted at similar markets.) And you can even get an Itanium 2 cheaper than the highest end Xeon 5100 series, and noticeably cheaper than the Core 2 Extreme. (Which I find ironic, since Core 2 Extreme is SLOWER than the fastest Xeon 5100 series processor.)

[Anonymous Freak]

Itanium is proving to be a dead end. Intel launched it years ago (IIRC around 98-2000) and it was so different from the existing architecture that you might as well treat it like an entirely different chip from X86 like a DEC Alpha, and as a result expensive, and nobody wants to adopt it.

Itanium actually launched in 2001. It was SCHEDULED to launch in '98-'99, but was delayed. The new dual-core Itanium 2's are the fastest chips available for floating point, though, and very competitive on Integer. For 'big iron', they are a reasonable competitor to RISC chips like Sun's chips and IBM's POWER series.

Intel's biggest problem is that people assume it is meant to be an x86 replacement. (Back in the mid '90s, Intel did have that as a goal, but have since dropped it. They now wholeheartedly embrace EM64T as the future of x86.) It's not. It's a competitor to other 'big iron' chips from Sun, IBM, et al. It had been used as a 'workstation' processor for a while, but now it's purely a server processor.

[wms121]

..in production, and announced today:

http://www.xbitlabs.com/news/cpu/display/20060720235512.html

...could Apple possibly* use this chip?

WW

*(hint hint class..which type of processing is BEST for Optical Chips?)

[See:

http://www.intel.com/technology/computing/mi05041.htm

..multi-threading..and CISC go together...like RISC and Cell arch. ]

[wms121]

DARPA policy statement:

http://www.darpa.mil/mto/3dcircuits/

Intel Vision Statement:

http://www.intel.com/technology/magazine/silicon/moores-law-0405.pdf

..closing into the "2012" chips DOD wants...Steve "might have seen" some
interesting stuff in various labs. IBM stuff, Motorola stuff, and whatever
Andy Grove might have had in his back pocket at the time. The POWER
Architecture is still useful, but projects like "full 64-bit Core Duo" prove
Intel can catch up much faster than MOTO ever could.

That will be needed for either "arrayed optical with mixed CISC" or "radical
3D stacked IC" type chips.

Like the ones they showed you for the SkyNET System in Terminator II.

WW

<--resets the alarm again

[madmaxmedia]

Not good enough for me. When performance is everything, Mac wins. A compressed version of RISC, or minor-risc of cisc isn't good enough for me. CISC is CISC even if its 99.999% RISC IMO, still, I wonder how much faster any of the computers would be if they had RISC instead of CISC w/RISC Chopped down Instructions. - -sorry can't think of a better way to phrase that.

This has been replied to plenty of times already, but wanted to point out a good link-

http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html

[JackSYi]

I think the Merom is Intel's first 64 bit mobile processor.

[Catfish_Man]

The cheapest of the new dual-core Itanium 2 9000-series chips is only $696 (even this 'cheap' model has 6 MB of cache,) compared to the Core-based Xeon 5100 series' cheapest $256, and Core 2 Duo's $183. (For comparison, the upcoming NetBurst-based Xeon 7100 series' cheapest is $856.) Compare the MOST expensive chips in each line: Itanium 2: $3692 (this one has a whopping 24MB of cache!) Core Xeon 5100 series: $851, Core 2 Extreme: $999, Netburst Xeon 7100 series: $3157 (With only 16 MB of cahce.)

So you can see that Itanium 2 is reasonably priced in comparison to Intel's own Xeon 7100 series. (Both are targeted at similar markets.) And you can even get an Itanium 2 cheaper than the highest end Xeon 5100 series, and noticeably cheaper than the Core 2 Extreme. (Which I find ironic, since Core 2 Extreme is SLOWER than the fastest Xeon 5100 series processor.)

Yeah, I exaggerated somewhat, but if you want even vaguely competitive integer performance you'll need the higher end ones. Core 2 is coming around 3k SPECint at the high end, and even the really expensive I2s only get just over 1600.

[Anonymous Freak]

I think the Merom is Intel's first 64 bit mobile processor.

Indeed it is. Although AMD has had 64-bit versions of their mobile chip for a year now. (And Sun for a while crammed their 64-bit chip into a notebook.)

[wms121]

http://science.nasa.gov/headlines/y2000/ast28apr_1m.htm

..one more reason to watch both IBM and Intel.

Jobs made several decisions during the NeXT-Apple transistion he may
regret now.

Using the Power architecture at the time..led to direct IBM involvement.

Moving away from it leads right to Intel.

Motorola dropped out long ago..even before the PPC issues had come up.

Ars Technica is bereft of any "optical chip" news because the Industry.."doesn't think it needs another technology transistion" at this time.

BlueRay IS a transistion.

Optical Computers 'could follow' BlueRay patents.

Intel is a leading OC chip maker.

Any other "core-duo" conversations? You could probably argue there is a 128-bit or even a 256-bit Core Duo "lab chip somewhere" (remember Transmeta uses several of Intel's patents).

How much of "core-duo" is 128 bit is also a good question. Like the PPC, extended buses and AltiVec...the greater the bus bandwidth the better the performance metrics.

Arn...you posted the question, did you get your answer?

WW

[jhu]

Yeah, I exaggerated somewhat, but if you want even vaguely competitive integer performance you'll need the higher end ones. Core 2 is coming around 3k SPECint at the high end, and even the really expensive I2s only get just over 1600.

true, but the itanium is a floating point monster. power5 beats it, and that's partially because it has a higher clock.

[jhu]

Indeed it is. Although AMD has had 64-bit versions of their mobile chip for a year now. (And Sun for a while crammed their 64-bit chip into a notebook.)

actually they still do (http://store.sun.com/CMTemplate/CEServlet?process=SunStore&cmdViewProduct_CP&catid=132680). although if i wanted to run solaris that badly, i'd get an x86 laptop and put solaris on it...

[maxvamp]

Lessee...

32X2=64..Twice as fast

With a Merom, I am waiting for....

- My games to run twice
- Oracle to run twice as fast
- Render / compile times to be twice as fast
- Safari to be twice as fast
- Rosetta to be twice as fast
- DVD burning to be twice as fast
- Productivity to be twice as fast
- Floppy / USB drives to be twice as fast
- love making to be ...no wait....:eek:


Max. :D

[poppe]

Lessee...

32X2=64..Twice as fast

With a Merom, I am waiting for....

- My games to run twice
- Oracle to run twice as fast
- Render / compile times to be twice as fast
- Safari to be twice as fast
- Rosetta to be twice as fast
- DVD burning to be twice as fast
- Productivity to be twice as fast
- Floppy / USB drives to be twice as fast
- love making to be ...no wait....:eek:


Max. :D

Excuse my ignorance, but I didn't think Bit Rate ( is that what its called) worked that way? Does it really make programs run Twice as fast?

[maxvamp]

Excuse my ignorance, but I didn't think Bit Rate ( is that what its called) worked that way? Does it really make programs run Twice as fast?


If it were bit-rate, it probably would work that way, but here we are talking register size.

No, it would not work that way, and judging by the last bullet point, that is probably a good thing.

Max.

[deadkenny]

So will Merom, Conroe and Woodcrest be 64-bit? Also will leopard support 64-bit processing like Windows XP 64 for example. I'm really looking fo rthe new MBP to be 64-bit, it should increase the speed quite dramatically right?


When adressing more than 4GB of RAM it should increase the speed dramaticall yes. Otherwise a longer pathway trough the chip will increase the delay and therefore it will slow down the CPU in theory. Practically it might increase the speed because a 64bit ALU (with some tricks) is capable of calculating two 32bit numbers at once.
Honestly: Despite the advantage of having more than 4GB of RAM you won't have any benefit of a 64bit CPU on a notebook computer!

I even think that 64bit will be the end of the bus width discussion for quite some while. There might be 128bit CPUs one day (the same reason as today, no real need for it but maybe 64bit isn't enough to adress all memory and a 128bit can do two 64bit numbers, otherwise 65bit or 80bit or something like that would increase the memory quite significantly) but I'm quite sure that we'll never see 256bit. At least no one will ever find the need to adress 2^256bit of RAM ;-)

[janstett]

Lessee...

32X2=64..Twice as fast


Wrong wrong wrong, it doesn't work that way. In fact, being 64-bit just for the sake of being 64-bit can make things SLOWER.

If I ask you to add these two numbers:

000000000000000000000000000000001 +
000000000000000000000000000000010

It will take you less time than to add these two numbers:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

The result is the same; which one can you add together faster?

Now, having said that, a switch to a 64-bit architecture usually also includes other generational improvements in design that will help cover that up and make it a positive experience but they have nothing to do with being 64-bit.

Worse, now you need an operating system that is 64-bit capable, and then that requires all new applications compiled for 64-bit mode and new drivers written in 64-bit mode, and then there's the problem of how do you run 32-bit applications?

The Windows world has been struggling with this for a few years now... The end result is that 64-bit XP is a toy that isn't ready for a mass market switch and people use their 64-bit chips to run the old 32-bit OS and apps.

[janstett]

but I'm quite sure that we'll never see 256bit. At least no one will ever find the need to adress 2^256bit of RAM ;-)

"Nobody will ever need more than 640k RAM!" -- Bill Gates, 1981

So, you never know. :)

[maxvamp]

Wrong wrong wrong, it doesn't work that way. In fact, being 64-bit just for the sake of being 64-bit can make things SLOWER.

If I ask you to add these two numbers:

000000000000000000000000000000001 +
000000000000000000000000000000010

It will take you less time than to add these two numbers:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

The result is the same; which one can you add together faster?

Now, having said that, a switch to a 64-bit architecture usually also includes other generational improvements in design that will help cover that up and make it a positive experience but they have nothing to do with being 64-bit.

Worse, now you need an operating system that is 64-bit capable, and then that requires all new applications compiled for 64-bit mode and new drivers written in 64-bit mode, and then there's the problem of how do you run 32-bit applications?

The Windows world has been struggling with this for a few years now... The end result is that 64-bit XP is a toy that isn't ready for a mass market switch and people use their 64-bit chips to run the old 32-bit OS and apps.


You did read my entire post.... right?

Max.

[poppe]

Wrong wrong wrong, it doesn't work that way. In fact, being 64-bit just for the sake of being 64-bit can make things SLOWER.

If I ask you to add these two numbers:

000000000000000000000000000000001 +
000000000000000000000000000000010

It will take you less time than to add these two numbers:

0000000000000000000000000000000000000000000000000000000000000001 +
0000000000000000000000000000000000000000000000000000000000000010

The result is the same; which one can you add together faster?

Now, having said that, a switch to a 64-bit architecture usually also includes other generational improvements in design that will help cover that up and make it a positive experience but they have nothing to do with being 64-bit.

Worse, now you need an operating system that is 64-bit capable, and then that requires all new applications compiled for 64-bit mode and new drivers written in 64-bit mode, and then there's the problem of how do you run 32-bit applications?

The Windows world has been struggling with this for a few years now... The end result is that 64-bit XP is a toy that isn't ready for a mass market switch and people use their 64-bit chips to run the old 32-bit OS and apps.

OS X, since the G5 (i think) were 64 Bit, should be ready for 64 bit yes? Or was OS X never made 64 bit?

[maxvamp]

OS X, since the G5 (i think) were 64 Bit, should be ready for 64 bit yes? Or was OS X never made 64 bit?


Only some core components of OSX are / were 64-bit for the G5. For the most part, nothing UI, Cocoa, or carbon based was 64-bit. This encompasses about 98% of the apps out there, which leads to 100% of the consumer apps.

Motion might have been the only application released for the general market that was a 64-bit app.

Max.

[maxvamp]

In order to further increase performance, should I be coding in 16-bit ? What about 8-bit?

Max.

[Anonymous Freak]

In order to further increase performance, should I be coding in 16-bit ? What about 8-bit?

Max.

If you're using an OS that can natively run 16-bit or 8-bit data on a processor that has a 16-bit or 8-bit operating mode, sure! (For example, the AltiVec instruction set CAN run on 8-bit data. If you want to do vector manipulation on a set of data, and 8 bits is enough, you can run 16 operations at once, since the AltiVec unit is 128 bits wide, and can be split into smaller segments.)

Unfortunately, to run native 16-bit instructions without 'padding' on a modern Intel processor requires dropping it into 16-bit 'Real' mode. No current OS will do that. (But if you want to install Windows 3.1 on your iMac Core Duo; go for it!) The PowerPC has no native 16-bit instruction set, so sorry, you're out of luck there.

[jhu]

OS X, since the G5 (i think) were 64 Bit, should be ready for 64 bit yes? Or was OS X never made 64 bit?

10.3 and 10.4 have partial 64-bit support.

[janstett]

In order to further increase performance, should I be coding in 16-bit ? What about 8-bit?

Max.

IBM and Microsoft used to write OS/2 together (versions 1.x). When they moved to OS/2 2.0, they wanted to make it pure 32-bit but instead kept key components 16-bit. Why? They performed better. It was faster having core components in split personalities with a 16-bit half and a 32-bit half and thunking between them, than writing new pure 32-bit code. OS/2 3.0 became pure 32-bit... and also became Windows NT when IBM and Microsoft split ways. It took many years for NT (2000/XP) to become acceptable in terms of performance and frugality and one could argue this was moore's law of increasing horsepower more than code optimization.

Microsoft did the same thing again with Windows 95. They could have gone completely 32-bit, and initially planned to. But they found that the pure 32-bit code was slower, and it was faster to keep the important components (kernel/gdi/user) 16-bit and give them a 32-bit thunking layer.

Now, how much of either case is the inefficiency of moving to a larger word size, and how much is that the 16-bit code was hand-tweaked assembly code that had been through years of refinement, who knows.

So, I know you're trying to be sarcastic, but increasing word size does not mean faster performance.

[Eidorian]

10.3 and 10.4 have partial 64-bit support.Yeah, 64-bit libraries for large addressing but they're not pure 64-bit operating systems. Like Windows XP x64....then again we don't want to talk about THAT one do we? :rolleyes:

[Anonymous Freak]

IBM and Microsoft used to write OS/2 together (versions 1.x). When they moved to OS/2 2.0, they wanted to make it pure 32-bit but instead kept key components 16-bit. Why? They performed better. It was faster having core components in split personalities with a 16-bit half and a 32-bit half and thunking between them, than writing new pure 32-bit code. OS/2 3.0 became pure 32-bit... and also became Windows NT when IBM and Microsoft split ways. It took many years for NT (2000/XP) to become acceptable in terms of performance and frugality and one could argue this was moore's law of increasing horsepower more than code optimization.

Microsoft did the same thing again with Windows 95. They could have gone completely 32-bit, and initially planned to. But they found that the pure 32-bit code was slower, and it was faster to keep the important components (kernel/gdi/user) 16-bit and give them a 32-bit thunking layer.

Now, how much of either case is the inefficiency of moving to a larger word size, and how much is that the 16-bit code was hand-tweaked assembly code that had been through years of refinement, who knows.

So, I know you're trying to be sarcastic, but increasing word size does not mean faster performance.

Although, my previous comment about running a current Intel chip in 16-bit mode WOULD make it slower. I had forgotten my history. (Which your post reminded me of.)

When Windows NT first came out, it made 486 and Pentium processors faster than when run on Windows 3.1, or even (upon its release,) Windows 95. Because NT was 'pure' 32-bit, while even Windows 95 retained 16-bit code in parts of its core. (Requiring 'thunking'.)

Upon the release of the Pentium Pro processor, speed freaks were dismayed. It performed WORSE in Windows 3.1 and DOS than the previous Pentium Processor, at faster speeds. (a.k.a. a 200 MHz Pentium Pro was outrun by a 166 MHz Pentium.) This defied logic! The Pentium Pro was a significantly better architecture, with its own on-package, full-speed L2 cache! (A first, at the time.) Why? Because, Intel had abandoned 16-bit computing. The Pentium Pro architecture (a.k.a. 'P6',) was designed from the ground up for 32-bit computing. While a 166 MHz Pentium may have beat a 200 Mhz Pentium Pro in 16-bit operations; a 166 Mhz Pentium Pro beat even a 200 MHz Pentium MMX in 32-bit operations.

That helped propel sales of both the Pentium Pro, and Windows NT, to the corporate market.

The Pentium Pro begat the Pentium II, which begat the Celeron, Pentium II Xeon, Pentium II, Pentium III Xeon, and Pentium-M. Then Intel abandoned this ground-breaking architecture for another new architecture, which they dubbed 'NetBurst'. Tuned for pure MHz speed, NetBurst became the Pentium 4, Xeon, (new) Celeron, and Pentium D. When Intel realized that this tuning for pure MHz actually made a more inefficient processor, and more power-hungry, they went back to the drawing board. Reviving the core ideals of the more-than-10-year-old P6 architecture, and adding the best parts of NetBurst, to come up with the 'Core' architecture at the heart of the latest, incredibly fast chips.

[slooksterPSV]

Yeah, 64-bit libraries for large addressing but they're not pure 64-bit operating systems. Like Windows XP x64....then again we don't want to talk about THAT one do we? :rolleyes:
Let's see, at my school, the video card driver would drop out every other reboot, if not every reboot. (Yes I'm talking about the x64 bit version). Hmm what else, software wouldn't work (does x64 have a 32-bit thunk layer or compatibility layer?). Anyways x64 isn't the best place to go. Now FreeDOS has a 2nd project where they're trying to bump it up to 32-bit bc hence forth (previous paragraph) 32-bit is now offically faster than 16-bit. What about 64-bit? The architecture and the OS must meet each other's requirements.

[coffey7]

I run 64 bit linux. It still doesn't have full support, which stinks. I guess linux was the first to offer os's when the first 64bit processors came out. I think that was 2002.

[poppe]

I don't know if this was said, but I would put alot of money on 10.5 being 64 bit. Or better at what ever it does. and make the 64 bit computers work faster.

Or am i wrong?

[Anonymous Freak]

I don't know if this was said, but I would put alot of money on 10.5 being 64 bit. Or better at what ever it does. and make the 64 bit computers work faster.

Or am i wrong?

On PowerPC systems, merely running in 64-bit mode doesn't make it any faster. In fact, for some activities, it could make it marginally slower (because it has to process 64-bits of data instead of 32, more data means more going through memory and the front side bus, effectively making the caches half as big.) If you actually want to work on 64-bit datasets, obviously working in 64-bit mode is faster, since it only takes one clock cycle instead of two. (Yes, 32-bit processors can work on 64-bit data, the just chop the data in two.)

On Intel systems, merely running in 64-bit mode will make for a slight increase in performance. The caveats regarding PowerPC above still apply; but when an x86 processor runs in 64-bit mode, it gains 50% more registers, and THAT adds speed. (Maybe 10-15% improvement over running the exact same processor-intensive task in 32-bit mode.) Yet again, obviously, working on 64-bit datasets is faster as well.

However, the BIG advantage of 64-bit modes (at least for now,) is the ability to address more than 4 GB of memory. Intel x86 systems can do this in 32-bit mode through trickery (called 'Physical Address Extension',) for the OS as a whole,but an individual process can still only use 4 GB. (So if you happened to work on truly humongous Photoshop files, they would work MUCH faster in 64-bit mode since Photoshop could then use more than 4 GB of RAM.) On 32-bit x86 systems, if you had 32 GB of RAM, it would basically mean that you could have 8 tasks using a full 4 GB of RAM (minus the small OS overhead,) but no one task could access, say, 8 GB. That's actually one of the main reasons enterprise-quality database apps and similar were multi-threaded years ago. Not so much to take advantage of multiple processors (but it helps,) but so that the app could use more than the 32-bit cap of 4 GB of RAM. It would just have each thread use 4 GB.

[jhu]

I run 64 bit linux. It still doesn't have full support, which stinks. I guess linux was the first to offer os's when the first 64bit processors came out. I think that was 2002.

linux has had 64-bit support since 1995 for the alpha and ultrasparc processors. btw, i run debian 3.1 on my amd64 machine without problems. the only issue i have is openoffice and doom3 being 32-bit only

[Anonymous Freak]

linux has had 64-bit support since 1995 for the alpha and ultrasparc processors.

Yeah, nowadays people seem to forget that there were other 64-bit architectures before AMD. Heck, MICROSOFT supported 64-bit architectures as early as 1993. (The same two you list.)

[jhu]

Yeah, nowadays people seem to forget that there were other 64-bit architectures before AMD. Heck, MICROSOFT supported 64-bit architectures as early as 1993. (The same two you list.)

actually, i don't think ms really supported 64-bit computing until itanium since their non-x86 versions of windows prior to itanium still ran in 32-bit mode.

[Anonymous Freak]

actually, i don't think ms really supported 64-bit computing until itanium since their non-x86 versions of windows prior to itanium still ran in 32-bit mode.

Yeah, I was being a little deceptive there. :-P I did only say that they supported those 64-bit architectures. :-D

[poppe]

So from my stand point (knows little about 64 bit stuff): Lets say Merom MBP's come out this August. How are they gonna perform to an equivalant 32Bit MBP? Same, Worse, Better?

I'm getting Merom just because I dont need a MBP yet, and I was hoping if I got 64 bit eventually it would bennifit me. (I'll be doing Avid, and FCP work).

[Anonymous Freak]

So from my stand point (knows little about 64 bit stuff): Lets say Merom MBP's come out this August. How are they gonna perform to an equivalant 32Bit MBP? Same, Worse, Better?

I'm getting Merom just because I dont need a MBP yet, and I was hoping if I got 64 bit eventually it would bennifit me. (I'll be doing Avid, and FCP work).

Well, if you compare a 2.16 GHz Core Duo (current chip/Yonah,) to a 2.16 GHz Core 2 Duo (new chip/Merom,) in the current Mac OS, you will probably see about a 5-10% improvement in performance. If Leopard supports 64-bit Intel processors, then running a 32-bit app in Leopard would see about a 10-15% improvement in speed. (Again, comparing a Core 2 Duo in 64-bit mode to a Core Duo in 32-bit mode.) Running a 64-bit app (that only really NEEDS 32-bit data, so there isn't an inherent disadvantage,) would see a 15-20% improvement; and running a 64-bit app that really needs 64-bit data would see an improvement somewhere in the 40-50% range.

This is based on similar comparisons on Windows.

[maxvamp]

IBM and Microsoft used to write OS/2 together (versions 1.x). When they moved to OS/2 2.0, they wanted to make it pure 32-bit but instead kept key components 16-bit. Why? They performed better. It was faster having core components in split personalities with a 16-bit half and a 32-bit half and thunking between them, than writing new pure 32-bit code. OS/2 3.0 became pure 32-bit... and also became Windows NT when IBM and Microsoft split ways. It took many years for NT (2000/XP) to become acceptable in terms of performance and frugality and one could argue this was moore's law of increasing horsepower more than code optimization.

Microsoft did the same thing again with Windows 95. They could have gone completely 32-bit, and initially planned to. But they found that the pure 32-bit code was slower, and it was faster to keep the important components (kernel/gdi/user) 16-bit and give them a 32-bit thunking layer.

Now, how much of either case is the inefficiency of moving to a larger word size, and how much is that the 16-bit code was hand-tweaked assembly code that had been through years of refinement, who knows.

So, I know you're trying to be sarcastic, but increasing word size does not mean faster performance.


Ahhh OS/2...

I was an OS/2 programmer once... Just one note... NT ( MS-OS/2 3.0 ) was pure 32-bit, but in the IBM lineage, there was actually still 16-bit code, and thunking still happened.

Still, performance wise, you ware right. No where was this more apparent than on the 386 SX, especially the earlier ones....

Max.

[poppe]

Well, if you compare a 2.16 GHz Core Duo (current chip/Yonah,) to a 2.16 GHz Core 2 Duo (new chip/Merom,) in the current Mac OS, you will probably see about a 5-10% improvement in performance. If Leopard supports 64-bit Intel processors, then running a 32-bit app in Leopard would see about a 10-15% improvement in speed. (Again, comparing a Core 2 Duo in 64-bit mode to a Core Duo in 32-bit mode.) Running a 64-bit app (that only really NEEDS 32-bit data, so there isn't an inherent disadvantage,) would see a 15-20% improvement; and running a 64-bit app that really needs 64-bit data would see an improvement somewhere in the 40-50% range.

This is based on similar comparisons on Windows.

Ok thanks. Good then I feel confident about my future purchase

[maxvamp]

I don't know if this was said, but I would put alot of money on 10.5 being 64 bit. Or better at what ever it does. and make the 64 bit computers work faster.

Or am i wrong?

First all,

Most things I say are tongue in cheek. Enjoy.. BUT!!

I am not sure if Apple will immediately adopt all 64-bit leopard. This is almost a cart before the horse situation.. 64-Bit Intel needs to be throw in 64-bit mode. To run 32-bit code, there needs to be a compatibility layer. This would be something like WOW-64.

Since Apple has released 32-Bit Intel machines, the introduction would require OS-X to be released in three flavors (PPC, IA32, IA64 ).This also means really fat binaries.

This would mean Ultra Binaries.... hmmm sounds like a lot of testing to me....

Max.

[Catfish_Man]

There is very strong evidence that even the GUI frameworks in 10.5 will have 64 bit versions (as opposed to just the non-gui ones in 10.4).

[maxvamp]

There is very strong evidence that even the GUI frameworks in 10.5 will have 64 bit versions (as opposed to just the non-gui ones in 10.4).

I am curious what 64-bit GUI controls would bring to the table? The only thing I could possibly see would be just interoperability with 64-bit code, but as for being 64-bit... NADA.

I might need a little help wrapping my brain around this one...

Max.

[gnasher729]

I am curious what 64-bit GUI controls would bring to the table? The only thing I could possibly see would be just interoperability with 64-bit code,

Exactly.

64 bit code that cannot access the GUI is a bit sad.

[Catfish_Man]

To elaborate on gnasher's answer: Currently the only way to make a 64 bit app is to have a 32 bit GUI program that communicates with a separate 64 bit core. Mathematica is a good example of this; Mathematica.app is 32 bit, but MathCore is 64 bit. Unfortunately, this divided process setup is poorly suited to apps that require realtime response, so things like Photoshop or Final Cut couldn't effectively be designed that way (and therefore can't use >4GB of ram).

[ChrisA]

Yeah, nowadays people seem to forget that there were other 64-bit architectures before AMD. Heck, MICROSOFT supported 64-bit architectures as early as 1993. (The same two you list.)

Not 64 bits but 60. What's four bits? I was a system programmer on a CDC 6600 which I think was the first 60 bit machine introduced in the 1960's It had some very advanced features even by today's standards. For example almost 100% of the operating system and I/O processing was off loaded from the CPU(s) to a set of 10 or 20 smaller "peripheral processors". Using modern terminology the machine had up to 24 "cores" but they were specialized, up to 20 for the OS and I/O and up to 4 for number crunching.

[wms121]

..this link is for those people who are going crazy attempting to make up
their mind on what system to buy.

It don't matter anymore.

The bus architectures, cpu architectures and memory bottlenecks since
processing broke into 64bitness are going by the wayside..you can now
buy cheap (under 800 bucks) 64-bit processing at Walmart.

Application speed?

What are you attempting to do..run games? Or compute scientific problems
that have never been solved?

Here is an interim solution, the TopSpin Infiniband cards and their support
for 64X Infiniband access:

http://www.topspin.com/solutions/pdf/HPApplicationNote.pdf

All the processing chips I mentioned earlier, (coreduo issues not withstanding)
will eventually wash out. The Cell Processor is JUST NOT READY FOR PRIMETIME YET. Jobs realized this...and got us something to replace the
notebooks Moto screwed up.

What are we then waiting for?

NEW OS research, higher resource hardware/software combos..perhaps even
some "optical computing chips" (for threadswitched systems right Scott McNeally?). Along with Sun's 128-bit server OS (or the AIX one right IBM?)..
we may yet see Apple turn the industry around. Some are predicting IBM is
going to change everything again with the Cell. Others hope for Sun, or the
"return of one of the seven dwarfs"?

Gee..maybe thats Disney ..right Steve?

Sony needs an optical chip..so does Samsung. The overseas people could
step forward with good Linux boxes and new technology..IF they have their
confidence back...BeOS came up too short too quick.

Gee..maybe Core Duo is actually 128-bit..just runs 16-bit for Mr. Gates.

WW

<--no don't touch that

[Letni]

Intel "hid" the 64-bit EM64T extensions to the Pentium4 for quite some time, mainly because they weren't yet ready for prime-time. It makes sense for them to integrate the capabilities into chips for testing and evaluation purposes prior to "rolling out" the feature officially.

Sorry, you are confusing this with Hyperthreading. Intel didn't actually integrate EMT64 (AMD64) into their CPU's until the 2mb prescott (revision E) and the Nocona Xeon about two years ago.. There was no implemention of this in any of their cpu's (disabled or enabled) Prior

[Anonymous Freak]

Gee..maybe Core Duo is actually 128-bit..just runs 16-bit for Mr. Gates.

It is. At least, the SSE3 vector engine is... (And in Core 2 Duos, it even processes an entire 128-bit chunk of data in one clock cycle, where in previous processors, it took two or more.)

[jhu]

It is. At least, the SSE3 vector engine is... (And in Core 2 Duos, it even processes an entire 128-bit chunk of data in one clock cycle, where in previous processors, it took two or more.)

except that it can't process 128-bit data as a discrete entity. it is at least two 64-bit pieces of data.

[jhu]

Not 64 bits but 60. What's four bits? I was a system programmer on a CDC 6600 which I think was the first 60 bit machine introduced in the 1960's It had some very advanced features even by today's standards. For example almost 100% of the operating system and I/O processing was off loaded from the CPU(s) to a set of 10 or 20 smaller "peripheral processors". Using modern terminology the machine had up to 24 "cores" but they were specialized, up to 20 for the OS and I/O and up to 4 for number crunching.

well, people back then used some weird architectures. 60-bit gp registers, 18-bit scratch-pad registers? who comes up with these bit sizes?

[wms121]

..this is scary:

http://en.wikipedia.org/wiki/The_Twonky
http://www.rottentomatoes.com/click/movie-10003407/reviews.php?critic=all&sortby=default&page=1&rid=1210903
http://www.imdb.com/title/tt0046475/
http://movies2.nytimes.com/gst/movies/movie.html?v_id=114914
http://www.neetstuff.com/TwonkyVideo/TwonkyHome.asp

..and this is the current enabler:

http://www.apple.com/macosx/features/voiceover/

Gee..if Core-Duo IS 128-bit..then maybe we need Solaris with ZFS.

Java IDE's can emulate 128/256 bit chips right?

Anyone run advanced Java (custom Sun modified stuff) on Darwin since
the early releases? Some of that stuff crashes bad..but most of the Darwin
patches (according to many un-dead Bothans..ahem..Unix Gurus) can be
worked around in Objective C using custom assembly for .s code.

WW

<--not my TWONKY

[wms121]

..here is an update:

http://www.columbia.edu/cu/news/media/03/steveObrien/index.html

Columbia showed how to assemble a 3D opti-chip using nano-technology.

Might be awhile before Steve Jobs (Intel or IBM for that matter) get to
purchase a "quantum dot total opti-path chip" using "positronic biasing"
(gee....just like Mr. Data)..but as Shatner sez.."I am working on that".

WW

<--knows PCman

[wms121]

http://www.photonicsonline.com/content/news/article.asp?docid=53e16920-d4a3-4fb8-9151-ef39a40737de&atc~c=771+s=773+r=001+l=a&VNETCOOKIE=NO

..add this to the "eight-way" quads..and you see where Intel is going.

They must want Apple to compete directly in Sun's server market ..WITH
IBM.

Optical Apples anyone?

WW

<--no, I don't lady

[wms121]

http://www.theregister.co.uk/2008/01/10/power7_optical_ibm/

...more DARPA money* for Steve.

From my previous posts..(on optical processing chips at Intel)..you now
know "the rest of the story".

Avie Tevanian..pls come back and be president of Apple...SJ is so thin now
his neck has almost disappeared.

Oracle ate Sun...Balmer might eat Apple.

WW

* (POWER7 poop:

http://en.wikipedia.org/wiki/POWER7

http://www.engadget.com/2009/08/26/ibm-brings-the-ruckus-and-new-power7-processor/

http://www.pclaunches.com/processors/ibm_power7_processor_unveiled.php

http://www.maximumpc.com/article/news/ibm_gives_details_octocore_power7_processor

)

[Wotan31]

POWER7 is sexy. I mean POWER6 is pretty damn sexy, but POWER7 is just I.want.you.now kind of sexy.

[Detrius]

The POWER7 is nice and all, but remember that THERE WAS NEVER A G5 POWERBOOK. I'm happy with my dual-core 64-bit laptop capable of running both OS X and Windows at native speeds.


That being said, being able to run 32 threads simultaneously on a single chip is DAMN SEXY. :D

[MLS]

It would be absolutely AWESOME if the Core Duo was 64-bit capable. I've been holding off on getting Snow Leopard because I have a Core Duo processor, and it would be pointless to get Snow Leopard if my computer didn't support 64-bit. If the Core Duo's do support 64-bit then I'll be upgrading.

[electroshock]

It would be absolutely AWESOME if the Core Duo was 64-bit capable. I've been holding off on getting Snow Leopard because I have a Core Duo processor, and it would be pointless to get Snow Leopard if my computer didn't support 64-bit. If the Core Duo's do support 64-bit then I'll be upgrading.

Unfortunately, you'd need the Core 2 Duo to gain a 64-bit processor. The original Core Duo was 32-bit.

[MLS]

Unfortunately, you'd need the Core 2 Duo to gain a 64-bit processor. The original Core Duo was 32-bit.

Ah I see. Well I've been planning on upgrading my iMac, so I'll wait until Apple releases a new batch and then buy one of those.

[munkees]

Ah I see. Well I've been planning on upgrading my iMac, so I'll wait until Apple releases a new batch and then buy one of those.

I just upgrade my core duo to core 2 duo. big notice in performance, also the 2mb L2 cache is not 4mb L2 cache.

[dukebound85]

I just upgrade my core duo to core 2 duo. big notice in performance, also the 2mb L2 cache is not 4mb L2 cache.

really?

i have a core duo and a core 2 quad and in day to day stuff, i cant tell a difference

[darbyclash34]

Ok, I've read all 7 pages of this thread today, and what the hell are you talking about wms121? Just in general, what is the point that you are trying to make?

[Anonymous Freak]

Ah I see. Well I've been planning on upgrading my iMac, so I'll wait until Apple releases a new batch and then buy one of those.

If you can find one on eBay or somewhere similar, a first-generation mobile Core 2 Duo (aka "Merom") chip will work just fine in your iMac. The CPU on the MacBook (including Pro and Air) line may be soldered down, but on the first Intel-generation iMacs, it used Intel's standard "mPGA 479" mobile socket. Any "T5000" or "T7000" series Core 2 Duo with a 667 MHz front side bus should work just fine. (See Intel's Processor Spec Finder (http://processorfinder.intel.com/List.aspx?ProcFam=2643), then change the "Bus Speed" dropdown to "667 MHz", and click "Filter On Selections".) A quick search on eBay shows the top-of-the-line T7600 for $250; or the next-down T7400 for $150-ish.

iFixit (http://www.ifixit.com/Guide/Browse/iMac) even has repair guides that will show you how to do it yourself, step by step.