You're not likely to see 128- or 512-bit general-purpose computers in your lifetime, I'm afraid. The increase from 32-bits to 64-bits isn't for performance reasons, it's for memory addressing.
A 32-bit computer can address up to 4 gigs natively. Intel has some extensions to allow up to 64 gigs, but with a performance penalty.
By moving to a 64-bit computer, the address space becomes astronomical - it is 4 billion time larger than the 32-bit addressing space. In the last twenty years, the average amount of memory in a computer has gone from about 512k to 512 megs - it's increased by about a thousand times. At that growth rate, a 64-bit address space would easily last through our lifetimes.
When you see video cards and dedicated gaming hardware that has a 128-bit (or higher) processer, it's done for different reasons. Usually, they need to perform complex mathematical operations that are very repetitive and easily parallelizable, which is not generally the case with a general-purpose CPU.
Yeah, I know. Some of the super-expensive RISC chips blow away PC's on floating point. But look at your FLOPS per dollar. Chances are the PC will be at least an order of magnitude lower.
It's been trendy to bash PC's for quite a while. However, if you've been "in the business" for two decades, and had your eyes open, you've realized that things have been slowly changing.
In the "bad old days", PC's sucked hard. Companies like Sun, DEC, and IBM were the only choices if you needed more computing power than an average automobile.
Because of the economies of scale in the economy market - and the competition - PC chip makers like Intel, AMD, Cyrix, etc. kept improving their products steadily. Now, a modern PC chip compute with "big iron" chips very well in integer work, and are fast approaching (in some cases, BEATING) them in floating point work - and all at a tenth to a hundredth of the price.
Back in the bad old days, it didn't matter how fast of a computer you bought, it still wouldn't run a desktop at an acceptable speed. These days, it practically doesn't matter how SLOW of a chip you buy, it'll still run a desktop at an acceptable speed.
There will always be a market for the big iron and specialty hardware, but as time goes on, the PC technology has improved by leaps and bounds over the years.
Now, don't get me wrong. There's still room for massive amounts of improvement. I would love to see the x86 architecture, and all of the legacy crop dropped like a hot potato. I'm not confident that it will happen in this decade, but it sure would be nice if it was.
A few weeks ago, I was looking into buying a $35,000 Sun system. I needed a machine with better memory bandwidth than a PC could offer. The machine in question interleaved its memory 8 ways, if you had all of the processers!
Then, I noticed that each bank ran at 75 MHz. Boy, was I shocked. That means that all 8 banks together run at the equivalent of 600 MHz. The new Granite Bay chipsets, with dual DDR 333, give you the equivalent of 666 MHz.
Both systems use PCI to connect to the outside world. The PC has a 533 MHz front-side bus, and an AGP port. I can't think of anywhere that the Sun would have had any better I/O.
Now, when you get into 8-way systems, the I/O between processers is better on the "high end" machines. But before you can come up with more I/O than a modern PC, you have to spend about 6 figures. In other words, two ORDERS OF MAGNITUDE HIGHER!
The press release *seemed* to indicate that only the Athlon64 (single-processer desktop version) would be delayed, and perhaps not the Opteron (multi-CPU server version). However, it wasn't entirely clear.
I guess that all I can do is assume that they'll all be delayed unless I hear otherwise. As much as I've been a supporter of AMD (and been waiting quite anxiously for the Hammers!), I think that they've not only dropped the ball, the ball has broken their foot on the way down.
SMP makes the kernel less secure? Wow. Gee. Yeppers, we must have seen a MILLION security holes in Linux from the SMP code.... (yeah, right.)
Simply claiming that it would make it more complex and less secure still doesn't excuse the fact that it's just about the only real, stable, robust operating system left that doesn't support SMP.
If they'll just get off of their butts and get SMP support, I'd switch all of my servers over to it in a week. Really. It's just too bad that they don't seem to want to support anything larger than a desktop PC.
Wait, my desktop is a dual Athlon. I guess my DESKTOP machine is just too advanced for them. C'mon, Theo, get it together.
Not only was Deep Blue specifically designed to beat Kasparov, it would be re-tuned and configured after each match to further customize it to his playing style.
You'd have to be a completely ignorant moron to believe that. A good number of large companies have been running PostgreSQL succesfully in mission-critical situation for *years*.
It's been used in network-monitoring apps for deployment in military vehicles, $30 million POS systems, medical systems, ticketmaster, a good number of heavy-traffic web sites, and just about everything else you can think of.
Anybody who told you it hadn't been tested was living long in the past.
Wow. You're talking about a lot of admins. I handle the functions of systems administrator and network engineer alone for a site that does 2,500,000+ hits per day. If I had to do it with Windows, I'd be swamped. Because I choose reliable hardware and Linux, it doesn't take a lot of time at all.
Yes, you can run a standard x86 RedHat. That's the attractive thing about the Hammer/Athlon64/Opteron/Whatever. They can run 32- or 64-bit code. In fact, they can run BOTH at the same time. One of the demos that AMD showed was a dual-monitor Opteron, with two spinning 3D objects. One was running as a 32-bit app, the other as a 64-bit app - on the same machine.
However, I believe that RedHat IS going to have a release for the Hammer. Considering that some packages (like Apache) are having a good amount of work done to make them really take advantage of the 64-bit environment, I'm not sure how much of a difference the special distro will make, but there's plenty of time for that.
I used to do client/server programming at a health care provider that employed over 20,000 people. The few apps that used Oracle were completely insigificant - EVERYTHING was on the AS/400. And they had a lot of AS/400's. In fact, they were buying MORE AS/400's. They were even planning on spending millions of dollars on a few very large AS/400's to replace several of the smaller AS/400's.
Why in the world would they still be using something so ancient? Legacy, man. "Back in the day", they started using AS/400's, and since everything was running on them, they just kept getting more and more of them. I'm sure that they're not the only ones that keep pumping millions of dollars per year into "Big Blue"'s coffers just because the idea of switching over is too daunting.
Of course, at the company I presently work for, we've done all of our CGI programming in Perl. We haven't found any reason to switch to anything else, and likely never will - but even if we did, we still probably wouldn't. It's taken YEARS of our entire programming team working like feral weasels to produce the programming we have. Just picking it up and migrating would take at least as long. If you look at the number of programmers, taking 4 years of their time to reprogram everything would cost them nearly a million dollars. The scary part? A million bucks is NOTHING compared to the market share we'd lose if we just took 4 years off from improving our product.
Yeah, legacy has a lot more power than most people realize.
I've been eagerly waiting for Hammer ever since it's announcement. High-bandwidth interconnects, 8-way SMP support, and AMD's incredibly high IPC all team up for a chip that sounds like a winner.
However, each chip is only going to get a single DDR333 memory path. With all of this time and effort, and so much at stake for AMD, you'd think that they'd make sure that they did it right, and move to a dual-channel solution, or at the very least, a DDR400 solution - which will be a pretty standard offering when the Opteron/Hammer/Athlon64/Whatever is released.
Sure, it'll perform pretty well with a single channel of DDR333. But I'll bet it would perform MUCH better with more bandwidth. And compared to all of the design and development that they've already done, implementing a dual-channel memory controller really wouldn't have been any significant challenge.
So, I'm not nearly as optimistic. On the other hand, I'm not a skeptic yet. When they come out, I'll see how they perform. But I'm certainly not as excited as I used to be.
There's a tradeoff, and in most cases, hardware is cheaper than labor. Let's say that someone earns $60,000 a year as a coder. After all of the costs to the employer, it will cost around $90,000 to $100,000 to keep them employed for a year.
That means that if the coder spends two weeks writing his program to do the math more quickly, it cost the employer $4,000 - in addition to the opportunity costs.
Now, given that you can pick up a 2 GHz-class machine for $500, you're presented with another option: You could just use Mathematica, and let it run across 8 machines in parallel.
Which way makes more sense? It depends on the situation. Let's say your coder is in great demand for other projects - the hardware route might make more sense. If he's sitting around anyway, you might as well put him to work. There are a lot of factors which can tip the scales one way or another.
It's really not that difficult. Provided that the center of pressure (the summation of drag forces on the rocket) is behind the center of gravity, small differences like that aren't going to make much of a difference at all.
The problem with losing a fin is not the resultant asymmetry of the rocket, it's that it shifts the center of pressure very far forward - almost always ahead of the center of mass, which then results in, to put it mildly, a "suboptimal" flight pattern. : )
You'd be amazed at some of the amazingly odd designs people come up with that still fly perfectly fine. Take a browse through here.
Some time ago, I downloaded all of their movies. in the higher-thrust liftoffs, yet, the G-forces do causes temporary glitches in the video, but they're very minor. However, when the deployment charge goes off and separates the sections, there is a more noticeable dropout in video.
The difference in propagation time is so low that for reaonable-length interconnects, it's going to be meaningless. Light travels around 186,000 miles per second, so under ideal conditions, a fifty-foot interconnect would take you about fifty nanoseconds. We'll use that for the example, it's plenty close for order-of-magnitude calculations.
So, let's say that the difference in propagation speed between copper and fiber is 15%, which is probably pretty high. That would mean a difference of only about 8 nanoseconds.
How much of a difference is that? Considering that the latency of the networking layers is generally measured in milliseconds, or if you're *really* fast, microseconds, that means that the extra latency from the fiber would be anywhere from 3 to 6 orders of magnitude LOWER than that of the networking layers. That's pretty insignificant.
Now if you're talking about running a 1,000 mile interconnect, then the differences become pronounced - but trying to get any decent bandwidth out of copper at that distance is going to be impossible. Ten gigabits over long-haul fiber is commonplace. Currently, the 10 gigabit ethernet over copper attempts have been limitted to a few *feet*.
There are also plenty of people who take pictures and/or videos from high-power rockets as well - and I'm not talking about the cheap Estes camera rockets. The preferred way to get still-shots is to use a decent-enough "point-and-shoot" with auto-advance, and wire a timer to the contacts of the button which takes the picture, although others use a servo to actuate the button, like this example.
It seems like even more people take videos, however - everything from a tiny "X10"-style camera with a transmitter to the full monty, where multiple digital video cameras are mounted inside the rockets. One of the founders of Xircom, Dirk Gates, has some very high-quality DV videos of his rocket flights at http://gbrocketry.com/movie_theater.htm.
After maintaining a good number of web servers and office machines for over three years, I have a nice pile of dead hard drives. About 30% of the machines got Fujitsu hard drives, yet every single dead drive but one is a Fujitsy. I stopped bothering with replacing them under warranty, because a new Fujitsu would just mean another dead hard drive in less than a year.
You're right that Tycos won't do it, but Tycos are trash. Look at Associated, and no, it won't kill the speed controllers. A NORMAL run in an R/C heat is 4 minutes, and the motors and gears are chosen to deplete the batteries (which are very high capacity) in just over that.
Even the off-road 1/10th RC cars go 30 mph without any modifications, and the on-road models will go 60. Add more batteries, a more powerful motor, and some numerically lower gearing, and you're ready to rock and roll!
A lot of stock, commodity 1/10th scale electric RC cars can go 60 mph, out of the box. With modifications, much, MUCH faster. And that's not even getting into the gas-powered rigs.
Yeah, I wish that SMP was taking over. We're not really that much farther in that regard than we were 5 or 6 years ago, with the Pentium Pro. In fact, in some regards, we're WORSE off: Since the PPro, all Intel chips had SMP capabilities, even the "non-SMP capable" celerons. However, now the norm is for their chips to NOT have SMP capability.
Yes, the Itanium and upcoming SledgeHammer are going to change things. But we've been hearing that for a decade. We'll see if things REALLY change or not.
Availability: Keep the hardware running, PostgreSQL will keep running. Our PostgreSQL server simply DOESN'T have problems. The only two times it's been shut down in YEARS were for planned hardware upgrades.
If that isn't enough, there are replication/clustering options available, both free and commercial.
Scalability: PostgreSQL scales much better than the competitors with the number of CPU's.
Secure data: Hot backups work just dandy, and you can send them anywhere you want.
Slashdot Mirror
You're not likely to see 128- or 512-bit general-purpose computers in your lifetime, I'm afraid. The increase from 32-bits to 64-bits isn't for performance reasons, it's for memory addressing.
A 32-bit computer can address up to 4 gigs natively. Intel has some extensions to allow up to 64 gigs, but with a performance penalty.
By moving to a 64-bit computer, the address space becomes astronomical - it is 4 billion time larger than the 32-bit addressing space. In the last twenty years, the average amount of memory in a computer has gone from about 512k to 512 megs - it's increased by about a thousand times. At that growth rate, a 64-bit address space would easily last through our lifetimes.
When you see video cards and dedicated gaming hardware that has a 128-bit (or higher) processer, it's done for different reasons. Usually, they need to perform complex mathematical operations that are very repetitive and easily parallelizable, which is not generally the case with a general-purpose CPU.
steve
"Where's the power?"
Easy. It's in the PC.
Yeah, I know. Some of the super-expensive RISC chips blow away PC's on floating point. But look at your FLOPS per dollar. Chances are the PC will be at least an order of magnitude lower.
It's been trendy to bash PC's for quite a while. However, if you've been "in the business" for two decades, and had your eyes open, you've realized that things have been slowly changing.
In the "bad old days", PC's sucked hard. Companies like Sun, DEC, and IBM were the only choices if you needed more computing power than an average automobile.
Because of the economies of scale in the economy market - and the competition - PC chip makers like Intel, AMD, Cyrix, etc. kept improving their products steadily. Now, a modern PC chip compute with "big iron" chips very well in integer work, and are fast approaching (in some cases, BEATING) them in floating point work - and all at a tenth to a hundredth of the price.
Back in the bad old days, it didn't matter how fast of a computer you bought, it still wouldn't run a desktop at an acceptable speed. These days, it practically doesn't matter how SLOW of a chip you buy, it'll still run a desktop at an acceptable speed.
There will always be a market for the big iron and specialty hardware, but as time goes on, the PC technology has improved by leaps and bounds over the years.
Now, don't get me wrong. There's still room for massive amounts of improvement. I would love to see the x86 architecture, and all of the legacy crop dropped like a hot potato. I'm not confident that it will happen in this decade, but it sure would be nice if it was.
steve
Lousy I/O?
A few weeks ago, I was looking into buying a $35,000 Sun system. I needed a machine with better memory bandwidth than a PC could offer. The machine in question interleaved its memory 8 ways, if you had all of the processers!
Then, I noticed that each bank ran at 75 MHz. Boy, was I shocked. That means that all 8 banks together run at the equivalent of 600 MHz. The new Granite Bay chipsets, with dual DDR 333, give you the equivalent of 666 MHz.
Both systems use PCI to connect to the outside world. The PC has a 533 MHz front-side bus, and an AGP port. I can't think of anywhere that the Sun would have had any better I/O.
Now, when you get into 8-way systems, the I/O between processers is better on the "high end" machines. But before you can come up with more I/O than a modern PC, you have to spend about 6 figures. In other words, two ORDERS OF MAGNITUDE HIGHER!
steve
The press release *seemed* to indicate that only the Athlon64 (single-processer desktop version) would be delayed, and perhaps not the Opteron (multi-CPU server version). However, it wasn't entirely clear.
I guess that all I can do is assume that they'll all be delayed unless I hear otherwise. As much as I've been a supporter of AMD (and been waiting quite anxiously for the Hammers!), I think that they've not only dropped the ball, the ball has broken their foot on the way down.
steve
SMP makes the kernel less secure? Wow. Gee. Yeppers, we must have seen a MILLION security holes in Linux from the SMP code.... (yeah, right.)
Simply claiming that it would make it more complex and less secure still doesn't excuse the fact that it's just about the only real, stable, robust operating system left that doesn't support SMP.
If they'll just get off of their butts and get SMP support, I'd switch all of my servers over to it in a week. Really. It's just too bad that they don't seem to want to support anything larger than a desktop PC.
Wait, my desktop is a dual Athlon. I guess my DESKTOP machine is just too advanced for them. C'mon, Theo, get it together.
steve
you're asking your opponent for hints? No wonder you keep losing. ; )
steve
Not only was Deep Blue specifically designed to beat Kasparov, it would be re-tuned and configured after each match to further customize it to his playing style.
steve
"untested in mission-critical applications"?
You'd have to be a completely ignorant moron to believe that. A good number of large companies have been running PostgreSQL succesfully in mission-critical situation for *years*.
It's been used in network-monitoring apps for deployment in military vehicles, $30 million POS systems, medical systems, ticketmaster, a good number of heavy-traffic web sites, and just about everything else you can think of.
Anybody who told you it hadn't been tested was living long in the past.
steve
It's not often that people become angry because a corporation is selling things cheaply.
Rather than be mad at Microsoft for charging so little, I'd be mad at the MPEG body for charging what they do.
steve
Wow. You're talking about a lot of admins. I handle the functions of systems administrator and network engineer alone for a site that does 2,500,000+ hits per day. If I had to do it with Windows, I'd be swamped. Because I choose reliable hardware and Linux, it doesn't take a lot of time at all.
steve
Yes, you can run a standard x86 RedHat. That's the attractive thing about the Hammer/Athlon64/Opteron/Whatever. They can run 32- or 64-bit code. In fact, they can run BOTH at the same time. One of the demos that AMD showed was a dual-monitor Opteron, with two spinning 3D objects. One was running as a 32-bit app, the other as a 64-bit app - on the same machine.
However, I believe that RedHat IS going to have a release for the Hammer. Considering that some packages (like Apache) are having a good amount of work done to make them really take advantage of the 64-bit environment, I'm not sure how much of a difference the special distro will make, but there's plenty of time for that.
steve
I used to do client/server programming at a health care provider that employed over 20,000 people. The few apps that used Oracle were completely insigificant - EVERYTHING was on the AS/400. And they had a lot of AS/400's. In fact, they were buying MORE AS/400's. They were even planning on spending millions of dollars on a few very large AS/400's to replace several of the smaller AS/400's.
Why in the world would they still be using something so ancient? Legacy, man. "Back in the day", they started using AS/400's, and since everything was running on them, they just kept getting more and more of them. I'm sure that they're not the only ones that keep pumping millions of dollars per year into "Big Blue"'s coffers just because the idea of switching over is too daunting.
Of course, at the company I presently work for, we've done all of our CGI programming in Perl. We haven't found any reason to switch to anything else, and likely never will - but even if we did, we still probably wouldn't. It's taken YEARS of our entire programming team working like feral weasels to produce the programming we have. Just picking it up and migrating would take at least as long. If you look at the number of programmers, taking 4 years of their time to reprogram everything would cost them nearly a million dollars. The scary part? A million bucks is NOTHING compared to the market share we'd lose if we just took 4 years off from improving our product.
Yeah, legacy has a lot more power than most people realize.
steve
I've been eagerly waiting for Hammer ever since it's announcement. High-bandwidth interconnects, 8-way SMP support, and AMD's incredibly high IPC all team up for a chip that sounds like a winner.
However, each chip is only going to get a single DDR333 memory path. With all of this time and effort, and so much at stake for AMD, you'd think that they'd make sure that they did it right, and move to a dual-channel solution, or at the very least, a DDR400 solution - which will be a pretty standard offering when the Opteron/Hammer/Athlon64/Whatever is released.
Sure, it'll perform pretty well with a single channel of DDR333. But I'll bet it would perform MUCH better with more bandwidth. And compared to all of the design and development that they've already done, implementing a dual-channel memory controller really wouldn't have been any significant challenge.
So, I'm not nearly as optimistic. On the other hand, I'm not a skeptic yet. When they come out, I'll see how they perform. But I'm certainly not as excited as I used to be.
steve
What's wrong with creating a PG user called "anonymous"?
steve
There's a tradeoff, and in most cases, hardware is cheaper than labor. Let's say that someone earns $60,000 a year as a coder. After all of the costs to the employer, it will cost around $90,000 to $100,000 to keep them employed for a year.
That means that if the coder spends two weeks writing his program to do the math more quickly, it cost the employer $4,000 - in addition to the opportunity costs.
Now, given that you can pick up a 2 GHz-class machine for $500, you're presented with another option: You could just use Mathematica, and let it run across 8 machines in parallel.
Which way makes more sense? It depends on the situation. Let's say your coder is in great demand for other projects - the hardware route might make more sense. If he's sitting around anyway, you might as well put him to work. There are a lot of factors which can tip the scales one way or another.
steve
It's really not that difficult. Provided that the center of pressure (the summation of drag forces on the rocket) is behind the center of gravity, small differences like that aren't going to make much of a difference at all.
The problem with losing a fin is not the resultant asymmetry of the rocket, it's that it shifts the center of pressure very far forward - almost always ahead of the center of mass, which then results in, to put it mildly, a "suboptimal" flight pattern. : )
You'd be amazed at some of the amazingly odd designs people come up with that still fly perfectly fine. Take a browse through here.
steve
Some time ago, I downloaded all of their movies. in the higher-thrust liftoffs, yet, the G-forces do causes temporary glitches in the video, but they're very minor. However, when the deployment charge goes off and separates the sections, there is a more noticeable dropout in video.
steve
The difference in propagation time is so low that for reaonable-length interconnects, it's going to be meaningless. Light travels around 186,000 miles per second, so under ideal conditions, a fifty-foot interconnect would take you about fifty nanoseconds. We'll use that for the example, it's plenty close for order-of-magnitude calculations.
So, let's say that the difference in propagation speed between copper and fiber is 15%, which is probably pretty high. That would mean a difference of only about 8 nanoseconds.
How much of a difference is that? Considering that the latency of the networking layers is generally measured in milliseconds, or if you're *really* fast, microseconds, that means that the extra latency from the fiber would be anywhere from 3 to 6 orders of magnitude LOWER than that of the networking layers. That's pretty insignificant.
Now if you're talking about running a 1,000 mile interconnect, then the differences become pronounced - but trying to get any decent bandwidth out of copper at that distance is going to be impossible. Ten gigabits over long-haul fiber is commonplace. Currently, the 10 gigabit ethernet over copper attempts have been limitted to a few *feet*.
steve
There are also plenty of people who take pictures and/or videos from high-power rockets as well - and I'm not talking about the cheap Estes camera rockets. The preferred way to get still-shots is to use a decent-enough "point-and-shoot" with auto-advance, and wire a timer to the contacts of the button which takes the picture, although others use a servo to actuate the button, like this example.
It seems like even more people take videos, however - everything from a tiny "X10"-style camera with a transmitter to the full monty, where multiple digital video cameras are mounted inside the rockets. One of the founders of Xircom, Dirk Gates, has some very high-quality DV videos of his rocket flights at http://gbrocketry.com/movie_theater.htm.
After maintaining a good number of web servers and office machines for over three years, I have a nice pile of dead hard drives. About 30% of the machines got Fujitsu hard drives, yet every single dead drive but one is a Fujitsy. I stopped bothering with replacing them under warranty, because a new Fujitsu would just mean another dead hard drive in less than a year.
steve
You're right that Tycos won't do it, but Tycos are trash. Look at Associated, and no, it won't kill the speed controllers. A NORMAL run in an R/C heat is 4 minutes, and the motors and gears are chosen to deplete the batteries (which are very high capacity) in just over that.
Even the off-road 1/10th RC cars go 30 mph without any modifications, and the on-road models will go 60. Add more batteries, a more powerful motor, and some numerically lower gearing, and you're ready to rock and roll!
steve
"....as fast as fifty miles per hour."
A lot of stock, commodity 1/10th scale electric RC cars can go 60 mph, out of the box. With modifications, much, MUCH faster. And that's not even getting into the gas-powered rigs.
steve
Yeah, I wish that SMP was taking over. We're not really that much farther in that regard than we were 5 or 6 years ago, with the Pentium Pro. In fact, in some regards, we're WORSE off: Since the PPro, all Intel chips had SMP capabilities, even the "non-SMP capable" celerons. However, now the norm is for their chips to NOT have SMP capability.
Yes, the Itanium and upcoming SledgeHammer are going to change things. But we've been hearing that for a decade. We'll see if things REALLY change or not.
steve
Availability: Keep the hardware running, PostgreSQL will keep running. Our PostgreSQL server simply DOESN'T have problems. The only two times it's been shut down in YEARS were for planned hardware upgrades.
If that isn't enough, there are replication/clustering options available, both free and commercial.
Scalability: PostgreSQL scales much better than the competitors with the number of CPU's.
Secure data: Hot backups work just dandy, and you can send them anywhere you want.
steve