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...
Well if there is no hardware, how can there be 64 bit apps?
But the gaming market is going to drive this and the hardcore gamers already build their systems (with AMD?). Intel will lose nothing at first.
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?
They would say that there's no hurry to the 64-bit desktop beacause they are not in a position to provide one. They have the expensive, specialised itanic for the high-end and HP have told them to be quiet about Yamhill, their Hammer equivalent. Apple and AMD are on to a winner. Personally, I can't wait to get a 64-bit home machine. That's why I haven't upgraded for over 3 years. Intel is advocating hacks to get around the 4GB limit just like the old LIM (Lotus intel Microsoft) Expanded Memory boards for the old IBM PCs of yore : basically segmentation and paging. Anyone who can remember those days will concur. I'm afraid intel will need to pull a rabbit out of its hat very soon. Expect to see Yamhill processors announced later this year (Pentiums, Xeons?, with "64-bit extensions").
Stick Men
Yes but some of us would actually stand to benefit from a commodity 64 bit proc. Those of us (like my Physics teach with a Phd in Biomolecular Physics) do active research and number crunching on molecular designs. People such as me need the boost to video/3d modelling apps where hitting 4gb memory limits is common. True that 64 bit solutions exist, but the problem is making them affordable. (And at 5k each, Sun Workstations and SGI boxen are not to the average college student).
There is nothing wrong with being gay. It's getting caught where the trouble lies.
There exist two versions of the PowerPC instruction set, one 32-bit and one 64-bit. The processors currently in use are all 32-bit, and the new 64-bit ones will be a superset of the 32-bit ones (and can execute 32-bit code natively).
Wouldn't it make more sense to put that 64 on the server, with XXGB of RAM, and push the display to the clients? X-terms, Terminal Services, whatever? Then, what, you've got 64 bit apps on the server, and a 32 bit clients, and no worry about memory usage.
Put identity in the browser.
Translation: We aren't done yet.
Didn't Apple manage to get their (admittedly smaller) user base to switch to a better processor?
Intel's argument against 64-bit computing seems to be an advertisement for the x86-64 concept. The article didn't mention gaming, but surely the gamer market will be a major early-adopter base. It sounds like preemptive marketing to me.
As for memory, the article, and presumably intel, don't seem to account for the ever-increasing memory footprint of Microsoft's operating system (or for the GNOME stuff on our favorite OS), and so are perhaps too dismissive of the need for a >4GB desktop. As we all know all too well, one can never have too much memory or disk space, and applications and data will always grow to expand to the limits of both.
Personally, I'm holding off on any new hardware for my endeavors until I see what AMD releases, though I would settle for a Power5-based desktop...
Intel still wants to keep rediculous margins for their products. AMD's approach brings everything closer together. The fastest computers are being built out of cheap consumer level processors, so why have incredibly expensive "server" processors?
Separation of consumer and "server" processors is just marketing, which is Intel's strongest talent (like Microsoft).
This is my sig. The post is over.
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
What's the big difference between 32-bit processors and 64-bit processors?
A 64-bit machine can address more than 4 GB of memory without funky segmented addressing kludges. This has applications in scientific simulation and database managers.
A 64-bit machine can also handle 64-bit integers as a native data type. This is important for encryption, number theory, financial applications dealing with money over $40 million, etc.
Will I retire or break 10K?
The Intel answer allows for a chip to have more than 4G of physical memory in much the same way the old LIM EMS boards allowed a 8086 to have more than 1M of memory - it is a form of bank switching.
True, you could have a PIII with 10G of memory on it (in theory, anyway), but this would not help you for the common applications for which you need these quantities of memory - databases, video editing and so on.
In those tasks, you have ONE program that needs lots of memory. You ideally want to be able to take a multi-gigabyte file, and mmap() it so that it appears to your program to be just a stretch of memory. Then you can access the file with a simple pointer, and moving within the file is nothing more than pointer manipulation. You don't have to worry about paging the file in and out - that is the OS's virtual memory manager's problem.
PAE won't help you in those cases. At best, you can back some of the buffer cache with the PAE memory, creating in effect a glorified RAM disk.
PAE is great if you have a machine running hundreds of processes, each of which takes 100M of space. But this usually is NOT the case.
Just as machines with more than 1M of memory started out the providence of the high-end user and slowly moved down, 64 bit address space on the desktop will start out the providence of the high-end folks first, then will move down as it becomes more common.
I would guess the likely sequence will be something like:
1) We *nix folks had it first - I was running 64 bits on my Alpha years ago. But we are not "the masses", and so will be ignored by the mainstream.
2) The Macs will be next - Apple will port MacOS X to the newer 64 bit Power chips. This will greatly simplify video editing - one of Apples favorite areas to compete in. 64 bit Apple will make the Mac the chosen platform for video editing of large files (NOTE: a 40 minute capture from my Firewire camcorder is a couple of gig - so already the home consumer is getting close to needing this.)
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.
www.eFax.com are spammers
I think Intel is currently dismissing 64-bit computing except for specialized needs because the vast majority of current mainstream software doesn't support 64-bit operations.
But I think that will change almost overnight once operating software that supports the Athlon 64/Opteron becomes widely available. We know that Linux is being ported to run in native Athlon 64/Opteron mode as I type this; I also believe that Microsoft is working on an Athlon 64/Opteron compatible version of Windows XP that will be available by time the Athlon 64 is released in circa September 2003 (we won't see the production version of Windows Longhorn until at least the late spring of 2004 (IMHO), well after the new AMD CPU's become widely available).
In case you're wondering about constants: the PPC only supports loads of 16bit immediate values (both in the lower and upper 16bits of the lower 32bits of a register), so to load a 64bit value you may have to perform up to 5 operations (two loads, a shift and two more loads). So a PPC requires up to 64bits for a 32bit immediate load and up to 160bits to load a 64bit value (unless you store such a value in a memory location that can be addressed in a faster way). These are worst cases however, and in a lot of cases 1 or maybe two instructions is enough.
The main downside of 64bit code is that all pointers become 64bit, so all pointer loads and stores indeed require twice as much storage and bandwidth.
Donate free food here
Little late asking that question.
I've heard that Microsoft is developing an Athlon 64/Opteron native version of Windows XP; if that is true then gaming companies involved with PC-based games may be already creating games that run in native Athlon 64/Opteron 64-bit mode under Windows XP as I type this.
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...
A little bit of computer engineering here for you...
RISC and CISC are the two main forms of processors out there these days. RISC simply means that an operation instruction is embedded with both the opcode and the operands. 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.
My CMPT 150 course (introduction to Computer Design) was done entirely with a Motorola HC11 Processor emulator, which is a CISC processor.
The advantage to RISC processing is that you can put in "Pipelining", which basically means a buffer for all data throughout the CPU at different levels. Now, this means that a single chunk of opcode/operand takes x clock cycles to process (x being the number of levels you have to your pipeline), but it also allows the processor to do multiple things at once, so that after the first instruction goes through to the last buffer, there's one waiting right after it for the next clock cycle, so a RISC processor can give a new CPU instruction with every single clock cycle.
Confused yet? Let me put it this way...
Pretend that your CPU is a plumbing system, with water streaming through hot and cold pipes to deliver a prefered temperature for the water. Now, the water temperatures are your CPU data (signals, bits, whatever...) and your pipes are your cpu circuitry.
Now, you want to send a big chunk of hot water down to the bottom of your pipe system using a bunch of intermediary valves (or/and/not/xor gates) and a specific pathway (Let's not ask why, let's just assume you want to do that). Now, say right after that you want to send a bunch of cold water down a similar path, but not necessarily the same path, however you will want to use some of the same pipes.
Now, with a CISC processor, what you would do is you would send down the hot water, occasionally storing it in some pipes whilst you send down the cold water, and the sheer design of the system would keep the Hot and Cold waters seperate and you would be able to output your hot water, and then output your cold water, once they have gone through their systematic storages and movements around.
The annoying thing about this is you need a sophisticated CPU to do it. And you need a bunch of clock cycles to open and close the valves and whatnot and finally get your desired output.
Now, a RISC processor does something a bit smarter.... It throws your hot water in (First clock cycle) and just lets the valves automatically trickle to the bottom, and then, on the second clock cycle, send the cold water down. The downside of this is the fact that your single clock cycle is going really slow, which means you have a big lineup of people requesting hot and cold water and they have to wait for it to come out (Lag, for those taking notes in computer-world).
So, we instate pipelining.
Pipelining is a bunch of basins (let's say 4) that appear at different levels of the pipe system.
So, you dump your hot water in the top basin. (First clock cycle)
Then, you unlock the basin and let it dump into the second basin. Once it's done that, once again, seal the basin and dump your cold water in. Now, (second clock cycle) open the plugs for both basins, and your hot water goes down the tubes (magically) before the cold water shows up and you can re-plug your basin. Now you have room for more water in the top basin.
Every move into a new basin is a clock cycle, so It takes 4 clock cycles for it to finally reach the bottom so you can do whatever the hell it is you would want to do with hot or cold water. However, these are relatively quick clock cycles compared to the clock cycle you had in your non-pipelined RISC architecture. And, ultimately, once the first output reaches the bottom, you only have to wait a single clock cycle for the input right after it, rather than waiting another oh-so-many amounts of clock cycles that you would've in your CISC architecture.
Did that make sense to anybody? I hope it did.
Karma: Non-Heinous
Intel didn't want to make the jump to 32 bit, so they introduced "segment registers". They tried to convince people that this was actually a good thing, that it would make software better. Of course, we know better: segment registers were a mess. Software is complex enough than to have to deal with that. That's why we ended up with 32 bit flat address spaces.
64 bit address spaces are as radical a change from 32 bit as 32 bit was from 16 bit. Right now, we can't reliably memory map files anymore because many files are bigger than 2 or 4 Gbytes. Kernel developers are furiously moving around chunks of address space in order to squeeze out another hundred megabytes here or there.
With flat 64 bit address spaces, we can finally address all disk space on a machine uniformly. We can memory map files. We don't have to worry about our stack running into our heap anymore. Yes, many of those 64 bit words will only be filled "up to" 32 bits. But that's a small price to pay for a greatly simplified software architecture; it simply isn't worth it repeating the same mistake Intel made with the x86 series by trying to actually use segment registers. And code that actually works with a lot of data can do what we already do with 16 bit data on 32 bit processors: pack it.
Even if having 4G of memory standard is a few years off yet, we need 64 bit address spaces. If AMD manages to release the Athlon 64 at prices comparable to 32 bit chips, they will sell like hotcakes because they are fast; but even more worrisome for Intel, an entirely new generation of software may be built on the Athlon 64, and Intel will have no chips to run it on. If AMD wins this gamble, the payoff is potentially huge.
Intel is behaving a bit like IBM when the PC was invented. IBM had all the pieces and managed to lose their position as a market leader in no time, mostly because they didn't understand the market they were in.
Intel currently owns the market for low end workstations and servers. If you need a web server or a cad station you get a nice P4 with some memory. This is also the market where the need for 64 bit will first come. At some point in time some people will want to put 8 GB of memory in their machine. AMD will be able to deliver that in a few months, Intel won't.
My guess is that Intel is really not that stupid (if they are, sell your intel shares) and has a product anyway but wants to recover their investment on their 32 bit architecture before they introduce the 64 bit enhanced version of their P4. The current P4 compares quite favorably to AMDs products and AMD has had quite a bit of trouble keeping pace with Intel. AMD needs to expand their market whereas Intel needs to focus on making as much money as they can while AMD is struggling. This allows them to do R&D and optimize their products and ensure that they have good enough yields when the market for 64 bit processors has some volume. Then suddenly you need 64 bit to read your email and surf the web and Intel just happens to have this P5 with some 64 bit support. In the end, Intel will as usual be considered a safe choice.
Jilles
The whole Linux architecture should ideally be replaced. We're still using something designed in the 70s, with lil hacks here and there to make it halfway usable in the current day. Unfortunately, it would be incredibly difficult to do, as the macrokernel system and crusty old ASCII-pipe-based GNU tools would have to be remade. Unix compatibility slows us down from moving forward. Even if everything was replaced, how long till RMS decided it was the work of Satan and began on a further replacement?
Whence? Hence. Whither? Thither.
Bill Gates claims that he never said 640K was enough memory. His denial appeared in an interview in the New York Review of Books. In fact, he says that he believed the opposite. (The slashdot audience can decide on his veracity.) Below is a quote from the article "He's Got Mail" by James Fallows:
One quote from Gates became infamous as a symbol of the company's arrogant attitude about such limits. It concerned how much memory, measured in kilobytes or "K," should be built into a personal computer. Gates is supposed to have said, "640K should be enough for anyone." The remark became the industry's equivalent of "Let them eat cake" because it seemed to combine lordly condescension with a lack of interest in operational details. After all, today's ordinary home computers have one hundred times as much memory as the industry's leader was calling "enough."
It appears that it was Marie Thérèse, not Marie Antoinette, who greeted news that the people lacked bread with qu'ils mangent de la brioche. (The phrase was cited in Rousseau's Confessions, published when Marie Antoinette was thirteen years old and still living in Austria.) And it now appears that Bill Gates never said anything about getting along with 640K. One Sunday afternoon I asked a friend in Seattle who knows Gates whether the quote was accurate or apocryphal. Late that night, to my amazement, I found a long e-mail from Gates in my inbox, laying out painstakingly the reasons why he had always believed the opposite of what the notorious quote implied. His main point was that the 640K limit in early PCs was imposed by the design of processing chips, not Gates's software, and he'd been pushing to raise the limit as hard and as often as he could. Yet despite Gates's convincing denial, the quote is unlikely to die. It's too convenient an expression of the computer industry's sense that no one can be sure what will happen next.
Click here to read the full article.
If Intel isn't spreading FUD about its 64 bit strategy, then this will be a turning point for AMD we will look back on in the future and say: "Wow Intel really screwed the pooch on that one".
;)
Fairly typical for ZDNet, Linux is either downplayed; or, as is the case in this article, ignored totally:
Currently, Itanium chips do not run regular Windows code well.
Windows software is designed to run on 32-bit systems.
'There hasn't been much OS support'.
Forget the number of years Linux has been running on a variety of 64 bit chips for years.
Articles like these are way too biased towards the Intel/Microsoft duopoly. I say go for it Intel, AMD can produce stable quality CPUs and you and Microsoft can say to each other: "No one will ever need more than 4GB of memory."
But not in a single contiguous chunk. You get to page in 4GB chunks (and this only works on Xeons).
...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."
Um, Hi... this is Intel. We know you *WANT* 64 bit but, um, you dont NEED it. Really, you dont. You believe that? Great! Basically guys, this is the problem, we *screwed the pooch* on this processor. We've spent 10's of billions of dollars on development, it's years behind schedule, it ain't that fast, and the whole thing just sucks right now. So here's what we're gonna do, We're gonna hold back this technology for like ehh, 6, 7, maybe 8 years SO WE HAVE TIME TO RECOUP THE MONEY WE WASTED by selling the chip as an expensive "workstation" CPU. So, expensive high-profit workstations for now, then you can have it later once it sucks (well it already does, but once it sucks more). Other platforms have had 64 processors for a decade now you say? You want mid 90's processor technology in 2003? FUCK YOU, you can't have it, end of discussion!
OH, and expect some dirty tricks, we know AMD is gonna be ready to sell you 64 bit way before us, so, well ... you'll just see ;)
Thanks, Intel
Religion is a gateway psychosis. -- Dave Foley
Apple:
- Well, now that they're most recently Going out of business, in steps IBM to save the day for them... a new line of iMacs is going to do insanely well, considering it's going to be the only fully-functional line of 64-bit personal computing, because I can pretty much guarantee Apple's going to have full-fledged 64-bit standardizing before anybody else. Apple's going to have an insane surge in users, a lot of the multimedia software that's been migrating to PCs is going to be happy with the better, faster and more powerful 64-bit hardware support and go back to developing for Macs... basically, Macs regain a lot of the status they've been falling behind in quickly.
AMD:
- Hammer sales go up! If they're really lucky, Intel will either do a harsh (and hopefully inferior) yet still more expensive knock-off of Hammer, or they're going to release Itanium in a hurry because they realize businesses like the idea of progress so they're starting to hop over to 64-bit architectures. So AMD will reclaim its status it lost about a year and a bit ago when the P4 got the title of "Best x86 on the market". Good on them.
Linux:
- Business as usual. Increased PPC support. Cool new Hammer patches, as well as the usual suspects (i386 still harshly dominating)
Microsoft:
- Well, maybe not everybody's jumping for joy... A lot of migration to PPC. But otherwise, they're still busy saying that "The Next New Windows Will Be Secure, And This Time We Mean It!" (tm).
That about it?
Karma: Non-Heinous
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