2)Do you really think the consumer-level D-VHS "VCRs" are going to have recording ability?
Well, this one does. Debatable whether US$2k is consumer level, though. There's another model selling for $949, but it doesn't appear to have HDTV support.
What they *should* do is produce 12" DVDs. That would give them around 100GB to play with (double-sided, double layer) with current technology.
You can't tell from the article, but a look at JVC's web site shows that it's a recorder, not just a player. It's still very expensive, sure, but how many options are available *now* for HDTV recording and playback?
Oh, and it works out around 12GB per hour in HS mode and half that in STD mode.
Latency is the key factor in cache design, yes, but the extra bandwidth still helps. And 4ns access/2ns cycle DDR SRAM is a lot cheaper than 2ns access SRAM. I think loads from L3 are 4-word bursts on the G4, so the improved bandwidth does matter.
With two 1GHz G4s, I would expect the PC-133 memory is getting to be a bottleneck. Unfortunately, the G4's bus is stuck at 133MHz (and is shared between the two CPUs) so DDR RAM wouldn't help much. On some applications, though, the 2MB of cache per CPU will make this box a winner. Remember the days when 2MB of memory was a lot? Well, write your apps like you did then and they'll fly!
Price is AUS$6,995 here. Poor doomed Aussie dollar:( Still, I'm told that the decline in our dollar is a major factor in the fact the the Australian economy has been going strong the last couple of years. (Recession? There's supposed to be a recession?)
I've found that the high-end multi-channel IDE controllers (such as 3Ware's Escalade line) work well in small database servers. They get around IDE's shortcomings by devoting a separate channel to each drive. Mind you, cabling up 8 drives is a b*tch.
Of course, the drives are still lower performance, but with a healthy amount of RAM I get good results at a reasonable price.
AMD has stated *explicitly* that the Hammer is an evolutionary rather than revolutionary design. They've said all along that it is an Athlon with 64-bit extensions and some minor tweaks (SSE2, extended pipeline). They haven't deceived anyone.
Now, as to the relative performance of the two architectures (x86-64 vs. IA-64): the Athlon XP 1900+ achieves a SpecInt2000 score of 701 (peak) while the 800MHz Itanium manages... 314. On floating point the Itanium does rather better: 645 vs. 634 for the Athlon. (The current leader is the IBM Power4, which gets 814 SpecInt and 1169 SpecFP.)
Having 128 64-bit registers is good, but remember that the Athlon and Hammer have far more physical registers than are presented in the programming model, and automatically map them according to the requirements of instructions in the pipeline. And the predicates and wide issue of the Itanium are balanced against the ability of the Athlon to *automatically* issue instructions speculatively and re-order the instruction queue to improve ILP.
And on the subject of manipulating multiple values with a single instruction: ever heard of MMX? 3DNow? SSE? Athlon has all of these, and Hammer will add SSE2. What do you think these are for?
As to the value of 64-bit addressing: I've programmed for machines (Suns and Compaq Alphas) with as much as 64GB of memory. While you *can* address that much with a 32-bit CPU, it means that you have to constantly re-map your view of memory, which is a royal pain. Moving to 64 bit addressing makes the problem disappear. And with current memory prices, even small commodity servers could make good use of more than 4GB of memory.
And 64-bit integer registers are good for a lot of things, and while you can certainly use 64-bit integers on a 32-bit CPU, making them faster won't hurt.
So, Athlon currently has a huge performance advantage over Itanium on integer apps, and a huge price/performance advantage (with comparable absolute performance) on FP apps. AMD's aim with Hammer is to extend Athlon cheaply and effectively into the 64-bit realm.
Intel's aim with Itanium appears to be to crush all competition; unfortunately, they've placed a *huge* bet on improvements in compiler technology that just hasn't paid off yet, resulting in a high-end chip that lags behind not just the high-end RISC chips like Alpha and Power, but low-cost desktop chips. To achieve commercial success, the Itanium needs integer performance somewhere in the vicinity of their competitors, but they currently trail the pack by a huge margin. Even SGI do better, and they all but shut down their CPU design efforts years ago.
Maybe McKinley will be the answer - but it doesn't look like it, given that the promised speeds have dropped to 1GHz. IA-64 is an interesting architecture which may even have a future, but so far it just don't fly.
"producing a db that actually implements the ACID properties reliably is very, very hard"
Actually, it's not that hard. What is hard, is producing a database engine that implements ACID properly *and* performs well for large datasets and large user counts. Naive implementations of ACID tend to result in performance bottlenecks when you try to scale up.
My Win98 machine, which I use only for playing games, has 384MB. My old Linux box has 384MB. My new Linux box has 1GB.
Work machines? My Sun Ultra2 has 1GB. My Linux box has 1GB. My Sun E250 had 768MB, but another department "borrowed" it a year ago and never gave it back.
Servers? I don't know about all the little servers scattered about the place, but they typically start at 512MB. New installs start at 1GB. The enterprise servers range from 12GB to 64GB. And these are all Unix. No NT anywhere.
Anyone who works extensively with databases, simulations, GIS or imaging would laugh at 256MB. There's not that many people who have 4GB on the desktop yet, but that will change over the next 2-3 years as memory becomes cheaper. (Plenty of people who want 4GB on their desks, it's just too expensive for most right now.)
A number of IA32 chips support 64GB of physical memory; however, a single process can only map 4GB directly. The operating system has to play funky tricks to get at different parts of memory at different times. Not unlike the days of extended/expanded memory (anyone remember that? Ugh!) So it's mainly useful on large multi-user machines.
It's from "A Shropshire Lad" by A. E. Housman. The whole thing is pretty long, but has some good bits, for example:
"Terence, this is stupid stuff:
You eat your victuals fast enough;
There can't be much amiss, 'tis clear,
To see the rate you drink your beer.
But oh, good Lord, the verse you make,
It gives a chap the belly-ache.
The cow, the old cow, she is dead;
It sleeps well, the horned head:
We poor lads, 'tis our turn now
To hear such tunes as killed the cow.
Pretty friendship 'tis to rhyme
Your friends to death before their time
Moping melancholy mad:
Come, pipe a tune to dance to, lad."
Re:Now if they only hurried up with Planescape 2..
on
Baldur's Gate 2 Gold
·
· Score: 1
> Maybe Morte (always wondered how he managed to carry stuff for me...);)
Heh. You know the bit where Morte gets kidnapped? Well, guess who was carrying my skull collection? Seemed like a good idea at the time...
> Also the AltiVec in the G4 is similar to a VLIW design.
Er, no, sorry. AltiVec is a short vector / SIMD implementation, like MMX, SSE and 3DNow: it allows you to apply a single instruction to multiple data elements (hence SIMD). The data elements in all these architectures must be identically sized and packed into a single field (vector), so a 128-bit AltiVec register can contain 4 32-bit, 8 16-bit or 16 8-bit values.
VLIW is all about applying multiple instructions to multiple, independent values. The independence of the values is essential, since all the instructions in a word are processed simultaneously without checking for conflicts, so two writes to the same register produces an undefined result.
SIMD and VLIW are orthogonal approaches, and there's no reason why they can't both be implemented on the same chip.
Yeah! 16-processor 16-core 16-issue VLIW with 16-way SIMD! At 16GHz!! Beowulf clu - ow! I'll be good this time, really!
Doing pretty well for a dead architecture. No arguing that X86 is goddamn ugly and annoying, but my elderly (I mean, it's 6 months old!) Athlon-700 whomps any chip Sun have in production on both int and floating point. Admittedly, you can't currently get 64 Athlons in an SMP box, or run 64 bit apps on them (at any useful speed), or put 8MB of L2 cache on them... Where was I?
Anyway, SledgeHammer gives me: 64-bit addressing, 64-bit native integers (don't know about you, but I need them), solid performance and hopefully sane pricing. And AA-64 has cleaned up some of the cruftiest corners of IA-32, with the extra GPRs and the new FP modes (16 128-bit SSE registers).
On the VLIW side - it's hardly a given that VLIW will beat OOO (Out-of-Order) RISC architecture even when VLIW compiler technology matures. Particularly for C/C++ code, which can't use a lot of optimisation techniques (due mostly to pointer issues). It's a wait-and-see there, I think. If you want to program in ASM and produce 100 bytes of code a day, then a w-i-d-e VLIW is for you, otherwise...
Since my performance needs are on big (32-bit need not apply) multi-user systems, I'll be watching the multi-core (Power4, SledgeHammer) vs. multi-thread (Alpha 21464) vs. VLIW (IA-64) battle with interest.
Ha! But the bytes sent over a network are big-endian! The 68000 (or at least its documentation) is somewhat schizophrenic - big-endian byte ordering, little-endian bit ordering (oops). Looks sensible until you stop and think about it.
I just wish that 30 years ago everyone had settled on one or the other, so I hadn't (didn't? wouldn't? Past perfect subjunctive is very confusing) just spent the last two weeks dumping and loading 250GB of data just because the byte ordering was different between the two systems.
One little, two little, three little endi - ow! Stop hitting me, I'll be good!
Agreed 100%. IA-64 is a very interesting architecture (all those little crinkly bits - lovely baroque feel) but the first chips (i.e. Merced) look like they'll be hot (150W), slow, and expensive. Intel are already spinning Merced as a development platform only. McKinley (chiefly designed by HP, who tend to know what they're doing) looks like the first "real" IA-64 chip, but it's still some distance away.
Meanwhile, AMD has designed the SledgeHammer as a minimal 64-bit extension to the Athlon, so it's not much bigger than existing chips (on the order of 10%), and so hopefully won't be too expensive. Though if it comes with dual cores and a large L2 cache, you can expect to pay rather more than for a Duron.
Assuming that it does come with dual cores and a healthy L2 cache (and no critical bugs), SledgeHammer will make a good choice for small servers and high-end desktops even without true 64-bit OS support. And Intel's troubles with Merced effectively hand AMD a 12-to-18-month window of opportunity in the low-end 64-bit market. Which may be all they need.
The other issue is that Merced is likely to be relatively slow on IA-32 apps, while SledgeHammer could well be the performance leader. If you don't expect all your code to go 64-bit overnight, it's another plus for the AMD solution.
People working with databases (my area), complex simulations and digital video already have problems with 32 bit limits. All can be worked around, but it's annoying to the developer, and often inefficent. My desktop machines both at work and home have 1GB of memory; 4GB of real memory is probably only two or three years away for me. 95% of my development is targeted at 64-bit systems (Sun, SGI and Alpha).
Also, the SledgeHammer is expected to have dual cores, which addresses at least one of your other points. If I can get a dual slot/socket motherboard, and thus four processors, I'll be happy (for a while, at least).
I do agree with your points on I/O - PCI has done well, but today a single GBit Ethernet or Ultra160 SCSI controller can swamp standard PCI, and 10GBit Ethernet and Ultra320 are waiting in the wings. PCI-64/66 will help, but it's only a short-term solution.
Slashdot Mirror
What is the percentage of worthwhile movies that came out in the last *sixty-two* years? [1939 was a good year, I must admit.]
2)Do you really think the consumer-level D-VHS "VCRs" are going to have recording ability?
Well, this one does. Debatable whether US$2k is consumer level, though. There's another model selling for $949, but it doesn't appear to have HDTV support.
What they *should* do is produce 12" DVDs. That would give them around 100GB to play with (double-sided, double layer) with current technology.
Yes, I have a laserdisc player. Why do you ask?
You can't tell from the article, but a look at JVC's web site shows that it's a recorder, not just a player. It's still very expensive, sure, but how many options are available *now* for HDTV recording and playback?
Oh, and it works out around 12GB per hour in HS mode and half that in STD mode.
Latency is the key factor in cache design, yes, but the extra bandwidth still helps. And 4ns access/2ns cycle DDR SRAM is a lot cheaper than 2ns access SRAM. I think loads from L3 are 4-word bursts on the G4, so the improved bandwidth does matter.
:( Still, I'm told that the decline in our dollar is a major factor in the fact the the Australian economy has been going strong the last couple of years. (Recession? There's supposed to be a recession?)
With two 1GHz G4s, I would expect the PC-133 memory is getting to be a bottleneck. Unfortunately, the G4's bus is stuck at 133MHz (and is shared between the two CPUs) so DDR RAM wouldn't help much. On some applications, though, the 2MB of cache per CPU will make this box a winner. Remember the days when 2MB of memory was a lot? Well, write your apps like you did then and they'll fly!
Price is AUS$6,995 here. Poor doomed Aussie dollar
I've found that the high-end multi-channel IDE controllers (such as 3Ware's Escalade line) work well in small database servers. They get around IDE's shortcomings by devoting a separate channel to each drive. Mind you, cabling up 8 drives is a b*tch.
Of course, the drives are still lower performance, but with a healthy amount of RAM I get good results at a reasonable price.
Bullshit.
AMD has stated *explicitly* that the Hammer is an evolutionary rather than revolutionary design. They've said all along that it is an Athlon with 64-bit extensions and some minor tweaks (SSE2, extended pipeline). They haven't deceived anyone.
Now, as to the relative performance of the two architectures (x86-64 vs. IA-64): the Athlon XP 1900+ achieves a SpecInt2000 score of 701 (peak) while the 800MHz Itanium manages... 314. On floating point the Itanium does rather better: 645 vs. 634 for the Athlon. (The current leader is the IBM Power4, which gets 814 SpecInt and 1169 SpecFP.)
Having 128 64-bit registers is good, but remember that the Athlon and Hammer have far more physical registers than are presented in the programming model, and automatically map them according to the requirements of instructions in the pipeline. And the predicates and wide issue of the Itanium are balanced against the ability of the Athlon to *automatically* issue instructions speculatively and re-order the instruction queue to improve ILP.
And on the subject of manipulating multiple values with a single instruction: ever heard of MMX? 3DNow? SSE? Athlon has all of these, and Hammer will add SSE2. What do you think these are for?
As to the value of 64-bit addressing: I've programmed for machines (Suns and Compaq Alphas) with as much as 64GB of memory. While you *can* address that much with a 32-bit CPU, it means that you have to constantly re-map your view of memory, which is a royal pain. Moving to 64 bit addressing makes the problem disappear. And with current memory prices, even small commodity servers could make good use of more than 4GB of memory.
And 64-bit integer registers are good for a lot of things, and while you can certainly use 64-bit integers on a 32-bit CPU, making them faster won't hurt.
So, Athlon currently has a huge performance advantage over Itanium on integer apps, and a huge price/performance advantage (with comparable absolute performance) on FP apps. AMD's aim with Hammer is to extend Athlon cheaply and effectively into the 64-bit realm.
Intel's aim with Itanium appears to be to crush all competition; unfortunately, they've placed a *huge* bet on improvements in compiler technology that just hasn't paid off yet, resulting in a high-end chip that lags behind not just the high-end RISC chips like Alpha and Power, but low-cost desktop chips. To achieve commercial success, the Itanium needs integer performance somewhere in the vicinity of their competitors, but they currently trail the pack by a huge margin. Even SGI do better, and they all but shut down their CPU design efforts years ago.
Maybe McKinley will be the answer - but it doesn't look like it, given that the promised speeds have dropped to 1GHz. IA-64 is an interesting architecture which may even have a future, but so far it just don't fly.
Slashdot fthagn! Ia Slashdot! Ia! Ia!
I think what they're referring to is the 16-wheeled cart upon which the idol containing the bones of Krishna is drawn during the Rathayatra.
HTH, HAND, SQL Error
> 185 billion is a lot of transistors to design.
:)
It is, but 4GB of L2 cache will use it up
(6 transistors per bit * 8 bits per byte * 4 billion = 192 billion. Damn, we're over budget!)
The Dell Precision 730 is the same box too. Spooooky.
But the HP at least comes with an Nvidia Quadro 2 card. The Dell comes with a Matrox G450.
Got benchmarks? http://www.intel.com/eBusiness/products/ia64/overv iew/bm012101.htm
I have two 64-bit desktops - SGI & Sun. Second hand SGI & Sun boxes are pretty cheap these days.
The Dreamcast, though, runs on the *32-BIT* Hitachi SH-4.
SQL Error
Well, the Amiga *was* cool, except for
AAH! BPTRS! Look what you've done! BPTRS!! There crawling down the walls!! Blblflblmblrgrfp
"producing a db that actually implements the ACID properties reliably is very, very hard"
Actually, it's not that hard. What is hard, is producing a database engine that implements ACID properly *and* performs well for large datasets and large user counts. Naive implementations of ACID tend to result in performance bottlenecks when you try to scale up.
> I live in Florida. Its been below 32 for almost everynight this month.
Well, you could come to Sydney, where it's been above 32 every night for the past week. That's 32C, which makes about 90 of your puny american Fs.
Last week it hit 45C here. That's 113F. Wanna swap?
[Raises hand]
My Win98 machine, which I use only for playing games, has 384MB. My old Linux box has 384MB. My new Linux box has 1GB.
Work machines? My Sun Ultra2 has 1GB. My Linux box has 1GB. My Sun E250 had 768MB, but another department "borrowed" it a year ago and never gave it back.
Servers? I don't know about all the little servers scattered about the place, but they typically start at 512MB. New installs start at 1GB. The enterprise servers range from 12GB to 64GB. And these are all Unix. No NT anywhere.
Anyone who works extensively with databases, simulations, GIS or imaging would laugh at 256MB. There's not that many people who have 4GB on the desktop yet, but that will change over the next 2-3 years as memory becomes cheaper. (Plenty of people who want 4GB on their desks, it's just too expensive for most right now.)
A number of IA32 chips support 64GB of physical memory; however, a single process can only map 4GB directly. The operating system has to play funky tricks to get at different parts of memory at different times. Not unlike the days of extended/expanded memory (anyone remember that? Ugh!) So it's mainly useful on large multi-user machines.
It's from "A Shropshire Lad" by A. E. Housman. The whole thing is pretty long, but has some good bits, for example:
"Terence, this is stupid stuff:
You eat your victuals fast enough;
There can't be much amiss, 'tis clear,
To see the rate you drink your beer.
But oh, good Lord, the verse you make,
It gives a chap the belly-ache.
The cow, the old cow, she is dead;
It sleeps well, the horned head:
We poor lads, 'tis our turn now
To hear such tunes as killed the cow.
Pretty friendship 'tis to rhyme
Your friends to death before their time
Moping melancholy mad:
Come, pipe a tune to dance to, lad."
> Maybe Morte (always wondered how he managed to carry stuff for me ...) ;)
Heh. You know the bit where Morte gets kidnapped? Well, guess who was carrying my skull collection? Seemed like a good idea at the time...
eHpl !'I mrtpaep dniiseda P PD1-!1
> Also the AltiVec in the G4 is similar to a VLIW design.
Er, no, sorry. AltiVec is a short vector / SIMD implementation, like MMX, SSE and 3DNow: it allows you to apply a single instruction to multiple data elements (hence SIMD). The data elements in all these architectures must be identically sized and packed into a single field (vector), so a 128-bit AltiVec register can contain 4 32-bit, 8 16-bit or 16 8-bit values.
VLIW is all about applying multiple instructions to multiple, independent values. The independence of the values is essential, since all the instructions in a word are processed simultaneously without checking for conflicts, so two writes to the same register produces an undefined result.
SIMD and VLIW are orthogonal approaches, and there's no reason why they can't both be implemented on the same chip.
Yeah! 16-processor 16-core 16-issue VLIW with 16-way SIMD! At 16GHz!! Beowulf clu - ow! I'll be good this time, really!
Doing pretty well for a dead architecture. No arguing that X86 is goddamn ugly and annoying, but my elderly (I mean, it's 6 months old!) Athlon-700 whomps any chip Sun have in production on both int and floating point. Admittedly, you can't currently get 64 Athlons in an SMP box, or run 64 bit apps on them (at any useful speed), or put 8MB of L2 cache on them... Where was I?
Anyway, SledgeHammer gives me: 64-bit addressing, 64-bit native integers (don't know about you, but I need them), solid performance and hopefully sane pricing. And AA-64 has cleaned up some of the cruftiest corners of IA-32, with the extra GPRs and the new FP modes (16 128-bit SSE registers).
On the VLIW side - it's hardly a given that VLIW will beat OOO (Out-of-Order) RISC architecture even when VLIW compiler technology matures. Particularly for C/C++ code, which can't use a lot of optimisation techniques (due mostly to pointer issues). It's a wait-and-see there, I think. If you want to program in ASM and produce 100 bytes of code a day, then a w-i-d-e VLIW is for you, otherwise...
Since my performance needs are on big (32-bit need not apply) multi-user systems, I'll be watching the multi-core (Power4, SledgeHammer) vs. multi-thread (Alpha 21464) vs. VLIW (IA-64) battle with interest.
Ha! But the bytes sent over a network are big-endian! The 68000 (or at least its documentation) is somewhat schizophrenic - big-endian byte ordering, little-endian bit ordering (oops). Looks sensible until you stop and think about it.
I just wish that 30 years ago everyone had settled on one or the other, so I hadn't (didn't? wouldn't? Past perfect subjunctive is very confusing) just spent the last two weeks dumping and loading 250GB of data just because the byte ordering was different between the two systems.
One little, two little, three little endi - ow! Stop hitting me, I'll be good!
Agreed 100%. IA-64 is a very interesting architecture (all those little crinkly bits - lovely baroque feel) but the first chips (i.e. Merced) look like they'll be hot (150W), slow, and expensive. Intel are already spinning Merced as a development platform only. McKinley (chiefly designed by HP, who tend to know what they're doing) looks like the first "real" IA-64 chip, but it's still some distance away.
Meanwhile, AMD has designed the SledgeHammer as a minimal 64-bit extension to the Athlon, so it's not much bigger than existing chips (on the order of 10%), and so hopefully won't be too expensive. Though if it comes with dual cores and a large L2 cache, you can expect to pay rather more than for a Duron.
Assuming that it does come with dual cores and a healthy L2 cache (and no critical bugs), SledgeHammer will make a good choice for small servers and high-end desktops even without true 64-bit OS support. And Intel's troubles with Merced effectively hand AMD a 12-to-18-month window of opportunity in the low-end 64-bit market. Which may be all they need.
The other issue is that Merced is likely to be relatively slow on IA-32 apps, while SledgeHammer could well be the performance leader. If you don't expect all your code to go 64-bit overnight, it's another plus for the AMD solution.
The Palm Pilot is 32-bit (Motorola 68328).
People working with databases (my area), complex simulations and digital video already have problems with 32 bit limits. All can be worked around, but it's annoying to the developer, and often inefficent. My desktop machines both at work and home have 1GB of memory; 4GB of real memory is probably only two or three years away for me. 95% of my development is targeted at 64-bit systems (Sun, SGI and Alpha).
Also, the SledgeHammer is expected to have dual cores, which addresses at least one of your other points. If I can get a dual slot/socket motherboard, and thus four processors, I'll be happy (for a while, at least).
I do agree with your points on I/O - PCI has done well, but today a single GBit Ethernet or Ultra160 SCSI controller can swamp standard PCI, and 10GBit Ethernet and Ultra320 are waiting in the wings. PCI-64/66 will help, but it's only a short-term solution.