Are you implying that a tank of hydrogen can't explode into a fireball under any circumstances? Maybe you should review a tape of the Challenger disaster again.
BTW, regarding myth #2, I don't buy the theory that the Hindenburg accident was not made worse by hydrogen. If it were filled with helium, the outer skin might have burned off, but the entire frame of the airship probably would not have been instantly converted into white-hot molten aluminum. Maybe it would have gently settled to the ground, giving people enough time to think about not panicing and jump to their deaths.
But if you have asteroids of smaller size, they will burn up much easily in the earth's atmosphere, would they not?
Let's do the math on burning the asteroid up in the atmosphere. Assume you have a 3-mile diameter asteroid going at 50,000mph. That's 5.7e10 m^3 of rock; assuming 5 tons/m^3, mass = 2.9e14 kg. Energy = 0.5mv^2 = 7.2e22 joules.
Assume a blob of gravel of this mass hits one side of the earth evenly distributed over an entire hemisphere over a 1 minute time span. That deposits the energy over 2.6e14 m^2 surface area in 60 seconds, for a total power flux of 4.6 megawatts per square meter of the entire earth; about 4000X the brightness of the sun for 1 minute. Even if the burnup occurs high in the atmosphere, the power influx at the surface would not diminish because the radiation is coming from the whole sky, not from a point source.
Volume is proportional to diameter cubed. Now you're talking about 1 billion asteroids, not 1000. Come on, this is 6th grade-level math. It can't be that hard to understand.
You do realise surely that 1000 small asteroids is a lot better than 1 large asteroid, right? The effect of 1000 small chunks would be greatly reduced due to them burning up faster while descending through the atmosphere.
1000 pieces of a 3-mile asteroid are each 0.3 miles (0.5km) in diameter. The atmosphere is barely going to singe a rock of that size before it impacts.
Even if were blown to tiny pieces, that wouldn't help. Scientific American had a recent article that hypothesized that one of the worst parts of a big impact is the rebound of billions of tiny fragments into space, which then rain down all over the globe. Each one burns up individually, but the overall effect heats the entire atmosphere to hundreds of degrees, incinerating just about everything on the planet.
Sliced big or small, that much mass coming in from outer space would be a major problem.
Itanium has a small core size. That's the advantage they gain from pushing so much of the work into the software compiler; especially branch prediction and instruction reordering.
However, I think that over the long run that's a bad solution. The software compilers will always be playing catch-up with the latest incarnation of the Itanium miroarchitecture, since so many low-level details are exposed in the instruction set. It's been a decade since the initial Itanium design, and they still don't have the compilers where they want them to be.
With the exposed low-level scheduling, if they try to add new architecture features to future versions of the chip, the forks of different compilers and optimal object code scheduling will start to get annoying. Alternatively, they'll translate on-the-fly in hardware to the architecture du jour, and they'll be no better off than the X86.
Part of the advantage in core size is probably offset by the larger amount of code that has to be fed into the Itanium to explicitely specify speculative instructions that will get cancelled. This will require a larger instruction cache, all other things being equal.
Ultimately, the largest factors in CPU performance are things like memory bandwidth, cache sizes, number of cores, and branch prediction. The details of how each core works or how the instructions are encoded are increasingly irrelevant. The Itanium designers were obsessively focused on branch prediction, and they attempted a radical approach to improve it, but it doesn't seem to have made a huge difference in and of itself. They get decent overall performance numbers, but that's probably mainly a function of the outlandish cache sizes they put on the die.
but x86 (and x86-64 as well) is UGLY and laden with all kinds of OLD JUNK
The old junk is a constant overhead, but processor architectures keep getting bigger and more complex with or without the old junk. Processors are now so large that the old junk is a tiny percentage of the total logic.
All modern processors translate their user-visible instruction set on-the-fly into some other internal format anyway. The X86 ISA is just a kind of bytecode, and it's a relatively compact one at that. It's easier for compilers to generate than Itanium bytecodes, so it's not hard to see why X86 is still around.
I kind of doubt that X86 will ever get junked. Now that X86 has 64-bit addressing, there's little reason to create any new user-visible changes to the instruction set. Processors can continue to improve and change their internal architecture without bothering the users with silly implementation details.
Unfortunately however, a Mars mission will be no more immune to stupid politically-driven mistakes than any other undertaking of this monumental size. It will almost certainly end up costing much more than it could have.
Do the analyses of rocket scientists and nuclear physicists carry any sway with you?
No.
Rocket scientists also made wildly estimates for the costs of the space shuttle and the ISS that were off by factors of 10 to 100.
Of course, I could always trust estimates that work like this: "It costs $X to do something easy. Therefore, it will cost 1000 times that to do something harder".
If it's 1000X harder, it would be reasonable to expect that it will cost 1000X more.
There's no margin for error here. More than half of all of the robotic missions to Mars have been lost. So far, we've had a total of just a couple of weeks experience in human missions beyond LEO, and in just that time there was a near catastrophic accident. The two long-term space stations we've put up have had innumerable problems that required fixes including new equipment from earth, not to mention fires and collisions. This mission won't have the options of getting more equipment, supplies, or bailing out for a short ride home.
Basically, mankind has not yet invented any space technology anywhere reliable enough to pull off this mission. This is going to require major breakthroughs in creating robust, totally self-sufficient spacecraft that can operate for years without any serious incidents. Developing that is going to be expensive. Waving your arms with broad brushstrokes about things like how to generate fuel on Mars is just ignoring all of the details that will make this mission unbelievably hard and expensive.
If you're a member of the church of the $1 trillion mars mission, that's not enough.
I'm a proud, card-carrying member of the church of the $1T mars mission.
It cost almost $1B to put two measly 200kg robots on mars. No matter how you slice it, it's going to easily cost 1000X that to design, test, certify and launch enough infrastructure to Mars to support humans for ~2 years and then bring them back with reasonable margins of safety.
I don't care how many authors and futurists claim that it's only going to cost 79 cents to pull off the mission. Things never work out as smoothly as originally predicted, and in space the initial cost projections are usually off by orders of magnitude.
I'm not arguing against going to Mars. It will be expensive, and it won't have any scientific value that couldn't be achieved with robots, but it's worth doing for the same reasons that it was worthwhile for the ancient Egyptians to build the pyramids.
I seem to recall memory some memory parts being available with data bus widths other than eight.
One-bit wide chips used to be the most popular. If you assume that chips are sized small enough so that you always need at least as many chips per module as your machine's data width, then the lowest overall pincount (and least amount of address selection logic) is achieved by using one data bit per chip.
Those conditions held from the 8-bit days through the early 32-bit days. Once chips got enough capacity so that a typical 32-bit module could be implemented with ~8 chips, 4-bit and wider chips became more popular.
I looked at the surface the other day. I didn't use a calculator, but it looked pretty rough on any life that might be around.
Here on earth they've found organisms living embedded deep in solid rock, living in superheated water vents, living in deep boreholes, living in highly radioactive reactor cooling systems, and all sorts of places that look just as inhospitable as Mars.
A tiny minority of marketing people do understand technology. Over the decades, I've been involved with or close to just a couple of wildly successful projects. Each of these had highly talented marketing people who thoroughly understood both the market and how the products themselves worked in detail. Many of these people were ex-engineers themselves. (Usually they weren't "natural" engineers, but they were smart enough to get an engineering degree from a decent school, after which they realized that suitdom was their true calling in life).
One of the keys to a successful engineering career is finding companies and projects with to-notch marketing and management teams. This is very difficult because of the extreme rarity of such situations. When you're doing job interviews or looking for new projects within a company, one of the best skills you can have is judging who is truly a talented product manager or marketeer, and who is just a bullshitter.
Like it or not, you have to form a symbiotic relationship with marketing, management and production people to make an impact in engineering. If any part of the whole is below par, the whole effort is likely to fail. However, once in a while all of the contributors are competent, and those are the cases where you'll probably find the most success.
The standard C++ compiler itself can be downloaded for free. The ulterior motive, IIRC (I'm kind of rusty on Borland's products), is to push Borland Builder, which tries to turn C++ into some kind of value-added nonstandard RAD environment. Once again, the vendor's goal is lock-in.
By the time Linux made it big, the compiler market was mature.
Look at the DOS/Windows compilers. There used to be several commercial offerings, including Microsoft, Borland, Watcom, etc. Now just about nobody is left trying to sell a compiler for Windows as an end in itself. Microsoft makes a compiler to help people stay locked into the Windows ecosystem. Intel makes a compiler to help people stay locked into X86 (they focus on raw performance so that X86 can run a few percent faster, helping to keep people from bolting to other architectures). There's a port of GCC to help promote Free software.
Most of the other commercial offerings were eventually frozen and offered as a freebie novelty on the websites of whatever company ended up with them when the music stopped.
The only reason that you have slightly more choice in still-under-development compilers on the Windows platform is that the players left in the game have ulterior motives that they're pushing.
You know, it seems there were far more compilers available for DOS and OS/2 than are available for Linux.
That's most likely because the market for compilers has become more mature. There are usually fewer players left in a mature market than in a new one. It doesn't necessarily have anything to do with open vs. closed source.
Instead of wasting a lot of time trying to do vector transformations on the power draws of your incandescent lights, why don't you just get some compact fluorescent bulbs? They'd lower your electric bill even more than this scheme would (assuming it would work at all).
Software is better than just that. It's a miracle commodity:
It's copyrightable like a book.
It's patentable like a mouse trap.
It can hold trade secrets, like a glass of Coca Cola.
The consumer has to "sign" a contract to use it, like a cellphone account. Advertising pitches can be included for a captive audience, just like a movie theater.
It's artificially expensive, like a diamond.
It's a recurring source of support revenue, like a lawn service.
It's creator can disavow all liability for anything that may go wrong, and get away with it, like... I can't think of anything else like that!
Nothing else can do more than a couple of those things. Software is just too good to be true.
A stack is a vertically integrated solution. For example, it can be a combination of OS, network severs, application servers and management tools all provided in one package by a single vendor. Ideally, all of the components of the stack have been pre-tested to work together smoothly.
Ok, consumer product companies are going to fund the first manned mission to Mars out of their advertising budgets. And it's going to happen within 10 years.
I think you need to put down that glass of libertarian Kool-Aid.
If we do get a solid private space industry I can see this number being as low as 10 years.
The X-Prize was created in 1996. 8 years later, the private space industry has managed to fly human beings with an astonishing 5% of the kinetic energy required just to get into earth orbit. Projecting from that, I'd say you're estimate is a tad optimistic.
What's the maintenance burden like for a large body of Fortran code?
Much numerical code focuses mainly on a couple of tight inner loops. That's probably what they care about.
I can't stand Fortran myself, but it supposedly does have design features/constraints that make it even faster than C on many numerical algorithms. That's a big reason why Fortran is still in use.
The smart way to do it would be to write a few small core number crunching utilities in Fortran and then glue them together with a nice scripting language.
Slashdot Mirror
BTW, regarding myth #2, I don't buy the theory that the Hindenburg accident was not made worse by hydrogen. If it were filled with helium, the outer skin might have burned off, but the entire frame of the airship probably would not have been instantly converted into white-hot molten aluminum. Maybe it would have gently settled to the ground, giving people enough time to think about not panicing and jump to their deaths.
Let's do the math on burning the asteroid up in the atmosphere. Assume you have a 3-mile diameter asteroid going at 50,000mph. That's 5.7e10 m^3 of rock; assuming 5 tons/m^3, mass = 2.9e14 kg. Energy = 0.5mv^2 = 7.2e22 joules.
Assume a blob of gravel of this mass hits one side of the earth evenly distributed over an entire hemisphere over a 1 minute time span. That deposits the energy over 2.6e14 m^2 surface area in 60 seconds, for a total power flux of 4.6 megawatts per square meter of the entire earth; about 4000X the brightness of the sun for 1 minute. Even if the burnup occurs high in the atmosphere, the power influx at the surface would not diminish because the radiation is coming from the whole sky, not from a point source.
Bottom line, everything would fry.
3 miles = 4.827 Kilometers
4.827 / 1000 = 4.827 meters
Volume is proportional to diameter cubed. Now you're talking about 1 billion asteroids, not 1000. Come on, this is 6th grade-level math. It can't be that hard to understand.
1000 pieces of a 3-mile asteroid are each 0.3 miles (0.5km) in diameter. The atmosphere is barely going to singe a rock of that size before it impacts.
Even if were blown to tiny pieces, that wouldn't help. Scientific American had a recent article that hypothesized that one of the worst parts of a big impact is the rebound of billions of tiny fragments into space, which then rain down all over the globe. Each one burns up individually, but the overall effect heats the entire atmosphere to hundreds of degrees, incinerating just about everything on the planet.
Sliced big or small, that much mass coming in from outer space would be a major problem.
However, I think that over the long run that's a bad solution. The software compilers will always be playing catch-up with the latest incarnation of the Itanium miroarchitecture, since so many low-level details are exposed in the instruction set. It's been a decade since the initial Itanium design, and they still don't have the compilers where they want them to be.
With the exposed low-level scheduling, if they try to add new architecture features to future versions of the chip, the forks of different compilers and optimal object code scheduling will start to get annoying. Alternatively, they'll translate on-the-fly in hardware to the architecture du jour, and they'll be no better off than the X86.
Part of the advantage in core size is probably offset by the larger amount of code that has to be fed into the Itanium to explicitely specify speculative instructions that will get cancelled. This will require a larger instruction cache, all other things being equal.
Ultimately, the largest factors in CPU performance are things like memory bandwidth, cache sizes, number of cores, and branch prediction. The details of how each core works or how the instructions are encoded are increasingly irrelevant. The Itanium designers were obsessively focused on branch prediction, and they attempted a radical approach to improve it, but it doesn't seem to have made a huge difference in and of itself. They get decent overall performance numbers, but that's probably mainly a function of the outlandish cache sizes they put on the die.
The old junk is a constant overhead, but processor architectures keep getting bigger and more complex with or without the old junk. Processors are now so large that the old junk is a tiny percentage of the total logic.
All modern processors translate their user-visible instruction set on-the-fly into some other internal format anyway. The X86 ISA is just a kind of bytecode, and it's a relatively compact one at that. It's easier for compilers to generate than Itanium bytecodes, so it's not hard to see why X86 is still around.
I kind of doubt that X86 will ever get junked. Now that X86 has 64-bit addressing, there's little reason to create any new user-visible changes to the instruction set. Processors can continue to improve and change their internal architecture without bothering the users with silly implementation details.
It can't fly the entire mission unmanned like the Buran did.
Unfortunately however, a Mars mission will be no more immune to stupid politically-driven mistakes than any other undertaking of this monumental size. It will almost certainly end up costing much more than it could have.
No.
Rocket scientists also made wildly estimates for the costs of the space shuttle and the ISS that were off by factors of 10 to 100.
Of course, I could always trust estimates that work like this: "It costs $X to do something easy. Therefore, it will cost 1000 times that to do something harder".
If it's 1000X harder, it would be reasonable to expect that it will cost 1000X more.
There's no margin for error here. More than half of all of the robotic missions to Mars have been lost. So far, we've had a total of just a couple of weeks experience in human missions beyond LEO, and in just that time there was a near catastrophic accident. The two long-term space stations we've put up have had innumerable problems that required fixes including new equipment from earth, not to mention fires and collisions. This mission won't have the options of getting more equipment, supplies, or bailing out for a short ride home.
Basically, mankind has not yet invented any space technology anywhere reliable enough to pull off this mission. This is going to require major breakthroughs in creating robust, totally self-sufficient spacecraft that can operate for years without any serious incidents. Developing that is going to be expensive. Waving your arms with broad brushstrokes about things like how to generate fuel on Mars is just ignoring all of the details that will make this mission unbelievably hard and expensive.
I'm a proud, card-carrying member of the church of the $1T mars mission.
It cost almost $1B to put two measly 200kg robots on mars. No matter how you slice it, it's going to easily cost 1000X that to design, test, certify and launch enough infrastructure to Mars to support humans for ~2 years and then bring them back with reasonable margins of safety.
I don't care how many authors and futurists claim that it's only going to cost 79 cents to pull off the mission. Things never work out as smoothly as originally predicted, and in space the initial cost projections are usually off by orders of magnitude.
I'm not arguing against going to Mars. It will be expensive, and it won't have any scientific value that couldn't be achieved with robots, but it's worth doing for the same reasons that it was worthwhile for the ancient Egyptians to build the pyramids.
One-bit wide chips used to be the most popular. If you assume that chips are sized small enough so that you always need at least as many chips per module as your machine's data width, then the lowest overall pincount (and least amount of address selection logic) is achieved by using one data bit per chip.
Those conditions held from the 8-bit days through the early 32-bit days. Once chips got enough capacity so that a typical 32-bit module could be implemented with ~8 chips, 4-bit and wider chips became more popular.
For a good part of the history of life on earth, you wouldn't find any of those things either, because macroscopic organisms had not yet appeared.
Here on earth they've found organisms living embedded deep in solid rock, living in superheated water vents, living in deep boreholes, living in highly radioactive reactor cooling systems, and all sorts of places that look just as inhospitable as Mars.
One of the keys to a successful engineering career is finding companies and projects with to-notch marketing and management teams. This is very difficult because of the extreme rarity of such situations. When you're doing job interviews or looking for new projects within a company, one of the best skills you can have is judging who is truly a talented product manager or marketeer, and who is just a bullshitter.
Like it or not, you have to form a symbiotic relationship with marketing, management and production people to make an impact in engineering. If any part of the whole is below par, the whole effort is likely to fail. However, once in a while all of the contributors are competent, and those are the cases where you'll probably find the most success.
The whole thing would be simpler if you could just buy paint that has a zero alpha component.
The standard C++ compiler itself can be downloaded for free. The ulterior motive, IIRC (I'm kind of rusty on Borland's products), is to push Borland Builder, which tries to turn C++ into some kind of value-added nonstandard RAD environment. Once again, the vendor's goal is lock-in.
Look at the DOS/Windows compilers. There used to be several commercial offerings, including Microsoft, Borland, Watcom, etc. Now just about nobody is left trying to sell a compiler for Windows as an end in itself. Microsoft makes a compiler to help people stay locked into the Windows ecosystem. Intel makes a compiler to help people stay locked into X86 (they focus on raw performance so that X86 can run a few percent faster, helping to keep people from bolting to other architectures). There's a port of GCC to help promote Free software.
Most of the other commercial offerings were eventually frozen and offered as a freebie novelty on the websites of whatever company ended up with them when the music stopped.
The only reason that you have slightly more choice in still-under-development compilers on the Windows platform is that the players left in the game have ulterior motives that they're pushing.
That's most likely because the market for compilers has become more mature. There are usually fewer players left in a mature market than in a new one. It doesn't necessarily have anything to do with open vs. closed source.
Instead of wasting a lot of time trying to do vector transformations on the power draws of your incandescent lights, why don't you just get some compact fluorescent bulbs? They'd lower your electric bill even more than this scheme would (assuming it would work at all).
It's copyrightable like a book.
It's patentable like a mouse trap.
It can hold trade secrets, like a glass of Coca Cola.
The consumer has to "sign" a contract to use it, like a cellphone account.
Advertising pitches can be included for a captive audience, just like a movie theater.
It's artificially expensive, like a diamond.
It's a recurring source of support revenue, like a lawn service.
It's creator can disavow all liability for anything that may go wrong, and get away with it, like... I can't think of anything else like that!
Nothing else can do more than a couple of those things. Software is just too good to be true.
A stack is a vertically integrated solution. For example, it can be a combination of OS, network severs, application servers and management tools all provided in one package by a single vendor. Ideally, all of the components of the stack have been pre-tested to work together smoothly.
Well, that's exactly what I was saying when I pointed out that the X-Prize is only 5% of the way to orbit.
I think you need to put down that glass of libertarian Kool-Aid.
The X-Prize was created in 1996. 8 years later, the private space industry has managed to fly human beings with an astonishing 5% of the kinetic energy required just to get into earth orbit. Projecting from that, I'd say you're estimate is a tad optimistic.
Much numerical code focuses mainly on a couple of tight inner loops. That's probably what they care about.
I can't stand Fortran myself, but it supposedly does have design features/constraints that make it even faster than C on many numerical algorithms. That's a big reason why Fortran is still in use.
The smart way to do it would be to write a few small core number crunching utilities in Fortran and then glue them together with a nice scripting language.