Slashdot Mirror
Intel: No Rush to 64-bit Desktop
An anonymous reader writes "Advanced Micro Devices and Apple Computer will likely tout that they can deliver 64-bit computing to desktops this year, but Intel is in no hurry. Two of the company's top researchers said that a lack of applications, existing circumstances in the memory market, and the inherent challenges in getting the industry and consumers to migrate to new chips will likely keep Intel from coming out with a 64-bit chip--similar to those found in high-end servers and workstations--for PCs for years."
Right now 4 GB of memory might be enough. But switching to 64 bit when we are already hitting the wall is not an option. The point with going to 64 bits now is that we can add memory past 4 GB without the headaches of moving to a new platform, since the transition is already done.
If Intel keeps on braking a lot of people will get really disappointed when they realize they need more memory than their platform supports.
.: Max Romantschuk
They're hardly likely to talk up the benefits of 64-bits on the desktop when their current 64-bit chip is so unsuitable. As and when they have an equivalent to AMD/Apple on the desktop, you can be sure they'll be more than happy to sing its praises.
What's interesting is the "nobody really needs 4Gb this decade" line. Just about every Mac in this room has 1Gb in it, and even the crappy test PC has 768Mb. 4Gb will be here sooner rather than later...
the whole pc architecture should ideally be replaced. we're still using something designed in the 80's, with lil hacks here and there to make it work in this current day. unfortunatly, it would be incredibly difficult to do, as all software and hardware would have to be remade. backward compatibilty slows us down from moving forward. even if everything was replaced, how long till it would be obsolete and need a further replacement?
And as for the desktop? There's no need whatsoever,
In the beginning, no one really needed a PC either. It is not need that drives the tech market, its want.
There's a growing sense that even if The Future comes,
most of us won't be able to afford it.
-- Lemmy
Didn't Apple manage to get their (admittedly smaller) user base to switch to a better processor?
Yes. They did it gradually. The first PPC Macs ran a 68k emulator which provided backwards compatability for old Mac software. Intel are trying to do the same thing; you can run IA-32 software on IA-64.
The problem that Intel has, and that Apple didn't, is that the IA-32 mode on an Itanium is generally slower than a real IA-32. Many Mac users found that their old 68k code ran just the same, or in some cases faster on the new PPC's. Intel then, is at a disadvantage with the IA-64, speedwide. Why invest all that money in a new platform just to run your code slower?
Now, this might not be such a problem if people were busy porting their stuff and tuning it for the IA-64, but Intel have two problem there. The first if the chicken and egg; no one is buying IA-64, so no one is porting their applications, so no one is buying IA-64. The other problem is technical; the EPIC (VLIW) instruction set is a nightmare to understand and code. Only a handful of people trully understand the full IA-64 ISA, so compilers and Operating Systems are slow to suport it. If you don't have adequate tools, how can you do the job?
At the moment, it looks like Intel could be onto a looser with IA-64. Only time will tell.
64-bit CPUs are really an OS designer's wet dream. There are lots of things (bounce buffers, dynamic RAM map, prelinking headaches) that just go away with a 64-bit address space. You can just map all RAM permenently, prelink all binaries to a unique address, and move on with your life (or lack thereof). I was thinking the other day, that with the move to database oriented filesystems like Reiser4 and LonghornFS (for lack of a better name) that the time is ripe for some of that OO research from the 80's and 90's to kick in. The gist is that instead of the basic abstraction being files with a strict naming hierarchy, the basic abstraction is a set of objects with a very flexible database index. Throw in object persistence, and you've got yourself a very elegant setup, with basically and OODBMS at the core of the system. However, straightforward (fast) implementations of the scheme blow away a 4GB address space. For something like this, you really want to be able to mmap() a 120GB harddrive and remove a whole lot of intervening hacks.
A deep unwavering belief is a sure sign you're missing something...
3) Windows will finally release a 64 bit OS (also note: they could have done this YEARS ago under Alpha, but didn't - Windows NT under Alpha only could access a 32 bit address space.) Microsoft will hail this as a revolutionary breakthrough - "Windows AYCABTU is the first 64 bit OS for the home user!" *nix and Apple users will scratch their heads in puzzlement.
We know that Microsoft actually bothered to write an Itanium-native 64-bit version of Windows XP Professional; it doesn't take much to figure out that Microsoft is right now coding an Athlon 64/Opteron 64-bit native version of Windows XP. My guess is that Windows XP for the Athlon 64 will be released commercially about the same time as the Athlon 64 is released (circa September 2003).
- RISC simply means that an operation instruction is embedded with both the opcode and the operands.
No, RISC means "Reduced Instruction Set Computer".- A CISC chip is one in which the opcode tends to be the first instruction processed and the operands are the next couple of instructions inputted.
No, CISC is a name made up by the people who invented the name RISC as is applied in a derrogatory manner to x86. Note that nearly all "RISC" chips in use today also need to pre-process instructions before they are executed as well. This is because of state machine instructions (like DIV) multiple actions instructions (test-and-set) and just plain weirdo instruction ideas (ARMs embed optional shift in all ALU instructions, PPCs have a multiple store instructions, etc.) You can see this in their pipelines -- they all have stages like "decode" or "crack" where things like this are figured out.The real difference between x86's and RISC's are that the x86 ISA was designed without consideration for contemporary CPU design technology (that is/was available at the time), while RISCs supposedly are. But anyone who has looked under the hood of these CPUs will see that this has not impeded the modern x86s. x86s are more complicated (and therefore in theory should probably be either a bit larger or slower) but as time shown, instruction set complications are not the only consideration for CPU design.
All x86's are pipelined, and in fact use the absolute latest CPU design techniques. The Pentium 4, in fact, has pseudo-double clocked integer ALUs and hyper-threading. Neither of these are available in any other RISC CPU.
...is that their 64-bit solution requires a completely different instruction set. It's painful to switch to an Itanium from an x86 platform. On the other hand, AMD's 64-bit solution(x86-64) should be about as painless a transition as the move from 16-bit to 32-bit processors.
Of *course* Intel is going to argue that 64bit isn't required for desktop computers. If users make the leap to AMD's x86-64, Intel will have to scramble to build a chip of their own to support it. Also, if you start getting $100, $200, $300 64-bit chips out there, I'm sure the server market's gonna stop and ask "why the hell are we spending $10k per Itanium?"
Intel stands to lose if we move to 64-bit on desktops.
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
Intel's claims are wholly out of touch with reality.
On a daily basis we're running into the Windows 2GB barrier with our next-generation content development and preprocessing tools.
If cost-effective, backwards-compatible 64-bit CPU's were available today, we'd buy them today. We need them today. It looks like we'll get them in April.
Any claim that "4GB is enough" or that address windowing extensions are a viable solution are just plain nuts. Do people really think programmers will re-adopt early 1990's bank-swapping technology?
Many of these upcoming Opteron motherboards have 16 DIMM slots; you can fill them with 8GB of RAM for $800 at today's pricewatch.com prices. This platform is going to be a godsend for anybody running serious workstation apps. It will beat other 64-bit workstation platforms (SPARC/PA-RISC/Itanium) in price/performance by a factor of 4X or more. The days of $4000 workstation and server CPU's are over, and those of $1000 CPU's are numbered.
Regarding this "far off" application compatibility, we've been running the 64-bit SuSE Linux distribution on Hammer for over 3 months. We're going to ship the 64-bit version of UT2003 at or before the consumer Athlon64 launch. And our next-generation engine won't just support 64-bit, but will basically REQUIRE it on the content-authoring side.
We tell Intel this all the time, begging and pleading for a cost-effective 64-bit desktop solution. Intel should be listening to customers and taking the leadership role on the 64-bit desktop transition, not making these ridiculous "end of the decade" statements to the press.
If the aim of this PR strategy is to protect the non-existant market for $4000 Itaniums from the soon-to-be massive market for cost-effective desktop 64-bit, it will fail very quickly.
-Tim Sweeney, Epic Games