Posted by
michael
on from the double-the-pleasure-double-the-fun dept.
msolnik writes: "Over at RealWorldTech they've published an article on the future of 64-bit performance. This article covers the different technology from Sparc to Hammer. Its a great read if you are looking for information on up-and-coming products from Intel, AMD, Sun, and Compaq."
Might have 64-bit computing very soon.
by
x136
·
· Score: 3, Interesting
If the Power Mac G5 is introduced at Macworld on Monday*, you can all have your 64-bit goodness by the months end!
*I'm not really expecting it to be released this soon, maybe later this year. But who knows? It could happen.
-- SIGFEH
link to Full article
by
mESSDan
·
· Score: 5, Interesting
is here: That way you only have to wait a longass time for it to load once, instead of a longass time for each of the 5 or 6 pages.
--
-- Dan
Compaq and Alphacide
by
Anonymous Coward
·
· Score: 4, Interesting
There is an interesting discussion over in comp.arch on Usenet about
Compaq, Alpha, and the Itanium. The thread is called
Alphacide. Interesting stuff. It appears
that Compaq drank the Koolade.
By the way, Pricewatch is quoting about $3K for the lowend Itaniums running at about 700 Mhz.
No thanks.
Re:So why do I need 64bits?
by
4im
·
· Score: 5, Interesting
One word: addressing. With those 32 bits,
you can
typically address up to 2 gig files on your
machine - which is a limit easily encountered when
you start working with video, for instance.
It took hacks to get 4 gig of RAM working on x86
with the linux kernel.
Go 64 bit, and that limit vanishes. You keep your
linear addressing, none of those ugly segments like
in the unfamous real-mode of PC-XT times.
I don't see what's really new about it all though,
we've had 64 bit since Alpha, and there's several
64 bit architectures around. It may not be
mainstream yet, but will IA 64 or Hammer really
change that (soon)? Allow me to have doubts.
Now we can wait for software support...
by
green+pizza
·
· Score: 5, Interesting
Once we get the 64-bit hardware, we still have the MMOS (minor matter of software) to worry about.
Cases in point:
Silicon Graphics machines with MIPS R4400 (and up) CPUs were 64-bit, but the additional address and pointer space wern't utilized until IRIX 6.0 in 1994 -- over 18 months later. (And, of course, certain SGIs still run in 32-bit mode due to RAM concerns -- 64-bit requires more RAM -- all Indys, all Indigos, all O2s, and R4400 Indigo2s).
Sun machines with UltraSPARC CPUs were 64-bit, but again, the additional address and pointer space had to wait for software support. (Multi-stage transition to 64-bit, starting with Solaris 2.5 and finally complete with Solaris 7 in 1998).
Then there's application optimization. Many apps can get slight speedups by processing data in larger (say, 38-bit or even 64-bit chunks). Sometimes the difference is huge, many times it's small. But, lots of little speedups can add up across an entire system. Still, someone has to make these changes to apps and compilers. It takes time, testing, and adoption. In better times, SGI did several such overhauls... they got some insane speed out of Netscape Enterprise and Netscape FastTrack web servers during the Everest project. One of their engineers also did some cool (but nonstandard) hacks to Apache, including the very first pure, clean 64-bit port/mod.
Newer, faster, wider, more-torque hardware is always great. But don't forget the software.
Re:AMD is deceiving you
by
statusbar
·
· Score: 3, Interesting
And unfortunately it will be a LONG TIME before good non-buggy optimizing compilers will be available for such a complex architecture.
software pipelining and parallel instructions give you a real complex monster cpu. Languages like C and C++ make it extremely hard to optimize for a cpu like this since C and C++ were never designed for fine-grained parallelism and software pipelining. So it results is a lot of wasted clock cycles.
What I'd LOVE to see is a statically typed pure functional language that could be used to generate the code for IA64. Then it would be feasable to fully take advantage of the IA64's features!
In the meantime, people compiling IA64 C code with GCC will be extremely disappointed. People compiling IA64 C code with Intel's optimizing compiler will be happier but will only be mildly impressed.
I've worked with VLIW (256 bit instructions) software pipelined DSP's before and learned very quickly that the C and C++ language standards are fundamentally limited for these things. I also learned very quickly that writing assembly language directly for them is an easy way to gain a special invitation to a padded room!!! I shudder to think what the compiler writers have to go through!
--jeff
-- ipv6 is my vpn
Re:Shrinkage
by
CaptainAlbert
·
· Score: 5, Interesting
> Perhaps your 486 MB was the first of its kind,
> but modern motherboards with integrated devices
> have the ability to disable them so that can be
> replaced by cards in slots.
True, but that presupposes the existence of spare slots;-)
I hear what you're saying about trashable chips, but I think the real phenomenon is the "trashable board". Think about it - if your mobo dies and your warrantee has run out, you go buy a replacement and ditch the old board. If it happens still to be under its manufacturer's warrantee, most likely you just take it back to the shop and swap it for a working one. What happens to the old one? Most likely, they throw it away. The cost of postage, packing, an engineer's time to find the problem, repairs, parts... it's more than the damn thing retails for anyway.
I think this is missing the point anyway. The integration idea goes like this: with today's technology, you could put the equivalent of an early Pentium processor, plus hard disk and graphics controllers, BIOS chipset, etc. onto a single piece of silicon. Pretty much all you'd be left with off-chip would be (a) RAM and (b) I/O circuitry, because they're both harder to integrate. So your computer is about four or five chips. This is approximately the case in palm-tops now.
The point is that you've lost all ability to choose your own components. That graphics block/macrocell has probably been chosen by the manufacturer becuase it was the best value for money (i.e. the cheapest they could find). If you're lucky, they will give you expansion ports so you can plug your own stuff in. But that costs money, and if they think you'll pay for the lesser product then they'll make that instead.
Does it matter? Probably not to the average user. But I think it would matter to the industry. The whole point of having standard architectures like PCI, SCSI, EIDE (and before them, ISA et al.) is that many vendors can compete to produce compatible products, which drives innovation and generally provides a good deal for the consumer.
But if the minimisation continues and the busses become subsumed into the very chips themselves, then the chances are the manufacturers will cut corners. They won't wait for the not-quite-standard-yet SuperBus2005 architecture... they'll design their own and make you buy their proprietary upgrades. Again, the economics work out such that you the consumer probably get a good deal. But trading off good deals today against innovation tomorrow is dangerous.
So, it would be much better to keep all those busses outside the individual components, right? But that's exactly what is keeping the PC architecture slow at the moment (which was the point of my previous post. I think.).
Re:AMD's gonna win
by
tap
·
· Score: 3, Interesting
Furthermore, the actual drive mechanics are the same for both
SCSI and IDE versions of a drive
Why do people keep repeating this myth? If you look at the physical parameters for any SCSI and IDE drive made in the last 5 years, you will see that they are completely different. I dare anyone to find a SCSI and IDE drive from the same manufacture produced since 1998 that has the same number of heads, spins at the same speed, and has the same capacity. You won't find any.
Re:What's the point?
by
DrSpin
·
· Score: 2, Interesting
And the answer is BLOATWARE (tm)
MS need all that extra space for for their forthcoming operating systems, which will be more bloated than ever.
Linux will never be able to bloat as fast as MS, so MS will finally and inevitably win!
All your BSOD are belong to us!
Re:AMD's gonna win
by
ergo98
·
· Score: 2, Interesting
Both SCSI and IDE are communications mechanisms, with SCSI winning out as being more intelligent (due to a variety of factors). Having said that therefore it's merely a function of the circuitry stuck on the back of the drive: Why in the world would any drive manufacturer manufacture completely different drives for SCSI or IDE? Seriously, I personally have never looked at the stats, but that seems absurd: It seems brutally obvious that they'd just pull them off the end of the line and stick on the SCSI board, or the IDE board, of course sticking a 200% premium on the SCSI equipped version as a sucker tax.
I find it interesting that you mentioned "since 1998", and it is perhaps true given that condition: IDE has permeated the market, and the only area where SCSI still has a presence is high end servers, so given that it is possible that they only even both sticking SCSI boards on the 15,000RPM monsters anymore. However, I still disagree with your assertion that it's a "myth", as back in the day (when even desktops came with SCSI if you wanted "multitasking") every SCSI versus IDE review started off with a disclaimer that the drives were physically exactly the same, and only the communications mechanism differed.
Slashdot Mirror
If the Power Mac G5 is introduced at Macworld on Monday*, you can all have your 64-bit goodness by the months end! *I'm not really expecting it to be released this soon, maybe later this year. But who knows? It could happen.
SIGFEH
is here: That way you only have to wait a longass time for it to load once, instead of a longass time for each of the 5 or 6 pages.
-- Dan
By the way, Pricewatch is quoting about $3K for the lowend Itaniums running at about 700 Mhz. No thanks.
One word: addressing. With those 32 bits, you can typically address up to 2 gig files on your machine - which is a limit easily encountered when you start working with video, for instance.
It took hacks to get 4 gig of RAM working on x86 with the linux kernel.
Go 64 bit, and that limit vanishes. You keep your linear addressing, none of those ugly segments like in the unfamous real-mode of PC-XT times.
I don't see what's really new about it all though, we've had 64 bit since Alpha, and there's several 64 bit architectures around. It may not be mainstream yet, but will IA 64 or Hammer really change that (soon)? Allow me to have doubts.
Once we get the 64-bit hardware, we still have the MMOS (minor matter of software) to worry about.
Cases in point:
Silicon Graphics machines with MIPS R4400 (and up) CPUs were 64-bit, but the additional address and pointer space wern't utilized until IRIX 6.0 in 1994 -- over 18 months later. (And, of course, certain SGIs still run in 32-bit mode due to RAM concerns -- 64-bit requires more RAM -- all Indys, all Indigos, all O2s, and R4400 Indigo2s).
Sun machines with UltraSPARC CPUs were 64-bit, but again, the additional address and pointer space had to wait for software support. (Multi-stage transition to 64-bit, starting with Solaris 2.5 and finally complete with Solaris 7 in 1998).
Then there's application optimization. Many apps can get slight speedups by processing data in larger (say, 38-bit or even 64-bit chunks). Sometimes the difference is huge, many times it's small. But, lots of little speedups can add up across an entire system. Still, someone has to make these changes to apps and compilers. It takes time, testing, and adoption. In better times, SGI did several such overhauls... they got some insane speed out of Netscape Enterprise and Netscape FastTrack web servers during the Everest project. One of their engineers also did some cool (but nonstandard) hacks to Apache, including the very first pure, clean 64-bit port/mod.
Newer, faster, wider, more-torque hardware is always great. But don't forget the software.
And unfortunately it will be a LONG TIME before good non-buggy optimizing compilers will be available for such a complex architecture.
software pipelining and parallel instructions give you a real complex monster cpu. Languages like C and C++ make it extremely hard to optimize for a cpu like this since C and C++ were never designed for fine-grained parallelism and software pipelining. So it results is a lot of wasted clock cycles.
What I'd LOVE to see is a statically typed pure functional language that could be used to generate the code for IA64. Then it would be feasable to fully take advantage of the IA64's features!
In the meantime, people compiling IA64 C code with GCC will be extremely disappointed. People compiling IA64 C code with Intel's optimizing compiler will be happier but will only be mildly impressed.
I've worked with VLIW (256 bit instructions) software pipelined DSP's before and learned very quickly that the C and C++ language standards are fundamentally limited for these things. I also learned very quickly that writing assembly language directly for them is an easy way to gain a special invitation to a padded room!!! I shudder to think what the compiler writers have to go through!
--jeff
ipv6 is my vpn
> Perhaps your 486 MB was the first of its kind,
;-)
> but modern motherboards with integrated devices
> have the ability to disable them so that can be
> replaced by cards in slots.
True, but that presupposes the existence of spare slots
I hear what you're saying about trashable chips, but I think the real phenomenon is the "trashable board". Think about it - if your mobo dies and your warrantee has run out, you go buy a replacement and ditch the old board. If it happens still to be under its manufacturer's warrantee, most likely you just take it back to the shop and swap it for a working one. What happens to the old one? Most likely, they throw it away. The cost of postage, packing, an engineer's time to find the problem, repairs, parts... it's more than the damn thing retails for anyway.
I think this is missing the point anyway. The integration idea goes like this: with today's technology, you could put the equivalent of an early Pentium processor, plus hard disk and graphics controllers, BIOS chipset, etc. onto a single piece of silicon. Pretty much all you'd be left with off-chip would be (a) RAM and (b) I/O circuitry, because they're both harder to integrate. So your computer is about four or five chips. This is approximately the case in palm-tops now.
The point is that you've lost all ability to choose your own components. That graphics block/macrocell has probably been chosen by the manufacturer becuase it was the best value for money (i.e. the cheapest they could find). If you're lucky, they will give you expansion ports so you can plug your own stuff in. But that costs money, and if they think you'll pay for the lesser product then they'll make that instead.
Does it matter? Probably not to the average user. But I think it would matter to the industry. The whole point of having standard architectures like PCI, SCSI, EIDE (and before them, ISA et al.) is that many vendors can compete to produce compatible products, which drives innovation and generally provides a good deal for the consumer.
But if the minimisation continues and the busses become subsumed into the very chips themselves, then the chances are the manufacturers will cut corners. They won't wait for the not-quite-standard-yet SuperBus2005 architecture... they'll design their own and make you buy their proprietary upgrades. Again, the economics work out such that you the consumer probably get a good deal. But trading off good deals today against innovation tomorrow is dangerous.
So, it would be much better to keep all those busses outside the individual components, right? But that's exactly what is keeping the PC architecture slow at the moment (which was the point of my previous post. I think.).
I could go on and on... <looks up> oh, wait...
These sigs are more interesting tha
MS need all that extra space for for their forthcoming operating systems, which will be more bloated than ever.
Linux will never be able to bloat as fast as MS, so MS will finally and inevitably win!
All your BSOD are belong to us!
Both SCSI and IDE are communications mechanisms, with SCSI winning out as being more intelligent (due to a variety of factors). Having said that therefore it's merely a function of the circuitry stuck on the back of the drive: Why in the world would any drive manufacturer manufacture completely different drives for SCSI or IDE? Seriously, I personally have never looked at the stats, but that seems absurd: It seems brutally obvious that they'd just pull them off the end of the line and stick on the SCSI board, or the IDE board, of course sticking a 200% premium on the SCSI equipped version as a sucker tax.
I find it interesting that you mentioned "since 1998", and it is perhaps true given that condition: IDE has permeated the market, and the only area where SCSI still has a presence is high end servers, so given that it is possible that they only even both sticking SCSI boards on the 15,000RPM monsters anymore. However, I still disagree with your assertion that it's a "myth", as back in the day (when even desktops came with SCSI if you wanted "multitasking") every SCSI versus IDE review started off with a disclaimer that the drives were physically exactly the same, and only the communications mechanism differed.