Didn't one land in the Mariana Trench, or something, and its still there?
The SNAP-27 from Apollo 13, IIRC. They were so happy to get them home that they let the craft sink.
Whatever. Pretty interesting stuff. Too bad we can't all have RTG's to get ourselves off the grid, eh?;)
Not quite.:-) RTGs produce far too little power to manage your home. However, I have put forth proposals for SRGs that could power Cell phones and laptops. Sadly, people hear "nuclear" and freak. Even those trained to know better.
It wouldn't have taken very much at all to decapsulate the plutonium, had the probe accidentally re-entered the atmosphere. But if that did happen, the results would not be so terrible.
Incorrect. The Plutonium is encased in a box explicitly designed to survive reentry. There have been several instances where launches have failed and RTGs have reentered the atmosphere. In one case, NASA actually reused the RTG. Previous to NASA's use of black box style technology, they simply burned up the RTGs in the atmosphere. Eventually they figured that wasn't such a good idea.
Russia continued to burn up RTGs even after we'd stopped. One satellite actually burned up over Canada. No deaths were ever linked to the incident, but Canada made a big stink over it and had Russia pay for reparations.
But you need to make sure that your arguments in favor of them are well-thought and appropriate, or you sound just as stupid as the vehemently anti-RTG nutjobs.
You'll have to forgive me, but they *really* piss me off. Even a *little* bit of research would show them that the risk is practically nill. In fact, there's much more risk from all the other chemicals on the rocket than from the RTG.
Maybe you could also convert light into electro-magnetic radiation.
Holy crap, somebody clue in Leibnitz that heat is energy!
You people look for any reason to get uppity don't you? I will rephrase that to clarify the implied meaning: The PU gets extremely hot and we convert the heat into usable energy. Happy now?
And exactly how has the Cassini mission failed so far?
It hasn't. It just caused a PR ruckus because of the RTGs on board. NASA has *never* had to deal with so many protesters before. They're trying to avoid having to do so again.
The problem is, that RTGs are huuuuge, for space stuff, and they really don't generate very much power, and introduce all sorts of cooling problems, cause they get hot.
Don't be ridiculous. An RTG with twice the power output would have weighed far less than the batteries, solar panels, and mounting. Not to mention that 5 pounds of PU is pretty small (remember, atomic number in the 90's). Cooling is the least of their concerns on Mars. (Or getting it there, for that matter). They had a working RTG system for the Mars rover. NASA just backed off of it because of the outrage over Cassini. (Insert comment about stupid tree huggers with oatmeal for brains who can't even take 10 minutes to find out what the hell they're protesting over. And that also goes for that whats-his-name physicist who complained about Cassini. "Oh no! A little plutonium in an indestructible box that has had flight testing during several accidents is going to kill us all!!!! Run for the #$*%#$*%$%$ hills!!!!")
ntil I googled a little and found the RHUs (Radioisotope Heater Units) on Sojourner.
Sojourner? You do realize that the Mars rover has those same heating elements? Since it's only a few grams of plutonium, they've managed to keep it pretty quiet. Unfortunately, the 3-5 pounds of Pu-238 required to replace the (insert explicative here) solar panels would draw too much attention. NASA's *still* licking their wounds from Cassini.
Oh, and just for your info, RTGs are passive units. This rock of PU gets really hot and we convert the heat into energy. The upside is that there's no moving parts, and about 75W per 2.5 pounds of PU-238. The downside is that you can never turn the thing off, so you sometimes have to dump some extra power.:-(
Anybody out there like to comment? Is it a possibility? Could we come back with another rover and get Opportunity working again after it runs out of juice?
Opportunity's batteries will be dead (as in won't charge) inside a year of landing. Since the little guy can't rove without a stored supply of juice, he'll be as good as dead. That's actually one reason why scientists had wanted to use an RTG on the mission. An RTG could have kept it running for years, and in fact would have been one of the LAST components to kick the bucket. Sadly, NASA doesn't want another PR problem like with the Cassini probe.
Touche. I will argue however, that the election committee does know that you voted. It is your right to not allow them to link you to your vote, but they do know the transaction occurred, just not the details of it.
However, you also make a big assumption that's probably not true: that the native code software you're running must be compiled for 386/486. Nobody who cares about performance would run unoptimized, 386-compiled code. If you have a P4 doing intensive calculations, you're going to use software compiled for P4 using SSE2.
Does anyone around here fscking READ?
READ THIS PARAGRAPH AGAIN:
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
And what part of the fact that I used that example because I don't remember MMX/SSE/SSE2 instructions makes it so difficult for you to get through your thick head?
Now, I don't program in Java, but I understand that Java pointers are "smarter" than C/C++ pointers and that the JVM may be smarter at determining aliasing and be more aggressive about optimizing.
That's because Java uses references instead of pointers. When you have an object reference, the JVM might tweak the actual storage or linking situations to its hearts content. It may even do things like link a "new" object to an existing one if it can prove that the object is immutable. This is particularly handy for Strings, where creating the same string over and over would be a waste of memory and CPU.
Very observant. My original reply was to the poster who said it was impossible for the JVM to run faster than native. However, I realize that real world code is likely to be impacted by the time it takes the Hotspot compiler to do optimizations. (That's actually one of the reasons that Java has been such a good fit for servers.)
Now here's the catch-22. All this stuff about making code perform better on the processor is BS. Unless you happen to have a platform designed for HPC (such as a Cray), your processor is otherwise spending that time doing nothing. (Memory wait states, cache misses, and other annoyances.) The thing to pay attention to is that the lost cycles don't matter. A.5% increase in performance is not going to make a lick of difference when your code is only running for 300 milliseconds at a time. And in that 300 millisconds, a few hundred million instructions get processed.
Unless programmers have a justification for a few thousand extra instructions a second (e.g. crypto cracking), their time would be better spent writing portable and maintainable code. The time they save from that maintainability can then be put into adding new features, and making their applications that much better. Especially since Java excels in the area of libraries. Dream up the most complex program you want, and I'll guarantee that 60-90% of the hard work has already been done for you.
Compare that to DLLs and staticly linked libs. Using C and C++ libraries back in the day, was more an exercise in frustration. Eventually you just said, "screw it!" and rewrote it yourself. Today, there are some very good libs for Unix, but there is still nowhere near the wealth of libs as Java has.
Pentium Pro code doesn't run on a 386. You're not making any sense, man.
Oh, for crying out loud. Since you're insisting on being denser than lead, let me spell it out for you:
1. Assume that Hotspot and the C compiler will generate the same code if told to optimize for the same processor.
2. Assume that the C implementation must generate code for the lowest common denominator. e.g. If your customers have 386s, you must generate code for a 386, no later.
Thus:
386:
C - The first code example JVM - The first code example
PPro:
C - The first code example (since the customer can't or won't recompile) JVM - The second code example (since the JVM is doing the compiling)
No, it doesn't. The second piece of code will not run on a 386 like you said it must.
Of course it won't! That's the point. The Hotspot compiler will generate the second piece of code because it notices you're using a Pentium Pro. If the JVM was running on a 386, it would generate the first bit of code, just like the C compiler.
Also, GNU GCC compiles code for processors like i686 that still executes on i386 by not using the i686-only instructions.
As much as I wish they did, not all OSes use ELF binaries. Besides, generating binaries for multiple processors creates a great deal of bloat in the binaries. Not to mention that the JVM will be able to optimize for future processers (when they come out) while the GCC binaries will only be optimized through the current processor.
No way. I can believe that - given certain conditions - a good compiler can optimise code better than an assembler (I believe it, but i've never seen it; I'm told that this is the case), but I cannot believe that an interpreter can. Maybe I'm living in the past. Please correct me.
Wrong on many counts. First off, Hotspot is a native compiler. It just compiles at runtime. Secondly, a good compiler can outperform a human optimizer because it can juggle such concepts as superscaler packets, out of order execution, and predictive branching. These are things that take a human a long time to calculate and figure out effectively.
BTW, it's been this way for 10+ years. It's just taken Intel processors a long time to catch up. And the *#$@ things STILL don't do SuperScaler right. Nor do they have enough registers. Or proper task switching. In fact, I think Intel still recommends not using the built-in task switch instructions. Blech.
Please explain how this would be faster than writing the app in native code using an assembler and then I'll believe you.
Ok. My assembly is a little rusty, so bear with me. Let's say we have equivalent Java and C programs. They both have to run on a 386 or higher. (Bear with me. I haven't kept up with the MMX/SSE/SSE2 instructions, so I'll have to fake this a little.) Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386. So, it generates the code:
pop AX STOSW 0x0005 pop AX STOSW 0x0005
Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.
Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:
pop EAX STOD 0x0005
That's twice as fast as the C code!
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.
> > Which often benchmark faster than natively implemented code. > >You do realize that this is impossible, right?
What makes you say that? In fact, the original poster is quite correct. The JVM *can* generate faster code. You know how? By doing runtime optimizations. Compilers have to optimize for what *might* be the best performance profile at runtime. Also, they can only compile for the lowest common processor. (e.g. A pentium II) The Hotspot Java VM can optimize based on how the code is currently being used, undo an optimization if it starts slowing things down, and use processor specific instructions! Natively compiled code just can't beat that.
Activities that are "one's own business" are still not anonymous. You simply don't have to disclose information about your business. When you buy a beer from the store, you are conducting a business transaction between you, the store, and the provider of the goods. All those parties have a right to know about the transaction, and indeed cannot be prevented from knowing. Unless you can spin me a business transactional relationship where laws could interpreted so that parties must forget the details of the transaction, I stand by my original statement.
This whole idea of anonymity is getting out of hand. Guess what? Anonymity never existed and has never been protected by any government. The idea of being anonymous came out of people getting lost in the industrial culture. Before the industrial age, you tended to have few choices on who to buy from, and the store owner knew you and what you bought. He didn't carry anything that you didn't want people to know you bought, because it would soon be getting around if you did buy it. Now we're using computers to pull that all back together, but mostly for the old advantages of knowing how to serve the customer better. Budweiser is not really interested in gossiping with others that you bought a keg, so what's the big deal already?
I know people like the idea of having a protective shroud of mystery surrounding them. I hate to break it to you, but it's just a false sense of security. If you do something worth noticing, you *will* get noticed.
Re:Sounds like you might like Stephen Baxter
on
Singularity Sky
·
· Score: 1
That said, Baxter's written some other great stuff, so you wouldn't do too badly picking up the wrong book.
No, it is *not* feasible today. No one has ever built a nanotube of a few feet, much less a nanotube of kilometers in length. We have built nuclear engines, and we do know they can work. Obviously, some of the more exotic designs quickly fall into the same amount of development time as nanotubes, but for high temperature, plasma producing engines, we've got NERVA/ROVER and Project Pluto under our belts. We *know* they can fly. Even Orion had quite a bit of work done on the pusher plate, shaped charges, and deployment mechanism (based off of a coke vending machine!).
Now I'm not saying that a skyhook is a bad or impossible idea. Just don't confuse what is already within the realm of engineering with what is still in the laboratory.
Sorry, I should have clarified. Super-weapons can make sense in major conflicts. However, modern warfare is not well suited to the super-weapons that are being developed. As a result, a much better bang for your buck is found in incremental development.
Besides, the atomic warhead was pretty much a single system. A bomb that exploded. Imagine if it was part of a complex tactical fighter!
Slashdot Mirror
Didn't one land in the Mariana Trench, or something, and its still there?
;)
:-) RTGs produce far too little power to manage your home. However, I have put forth proposals for SRGs that could power Cell phones and laptops. Sadly, people hear "nuclear" and freak. Even those trained to know better.
The SNAP-27 from Apollo 13, IIRC. They were so happy to get them home that they let the craft sink.
Whatever. Pretty interesting stuff. Too bad we can't all have RTG's to get ourselves off the grid, eh?
Not quite.
*sigh*
It seems that even geeks don't understand geek humor.
It wouldn't have taken very much at all to decapsulate the plutonium, had the probe accidentally re-entered the atmosphere. But if that did happen, the results would not be so terrible.
Incorrect. The Plutonium is encased in a box explicitly designed to survive reentry. There have been several instances where launches have failed and RTGs have reentered the atmosphere. In one case, NASA actually reused the RTG. Previous to NASA's use of black box style technology, they simply burned up the RTGs in the atmosphere. Eventually they figured that wasn't such a good idea.
Russia continued to burn up RTGs even after we'd stopped. One satellite actually burned up over Canada. No deaths were ever linked to the incident, but Canada made a big stink over it and had Russia pay for reparations.
But you need to make sure that your arguments in favor of them are well-thought and appropriate, or you sound just as stupid as the vehemently anti-RTG nutjobs.
You'll have to forgive me, but they *really* piss me off. Even a *little* bit of research would show them that the risk is practically nill. In fact, there's much more risk from all the other chemicals on the rocket than from the RTG.
I wonder if he tested the RTGs that have gone up. PeeUoo!
;-D
(insert groans here)
Maybe you could also convert light into electro-magnetic radiation.
Holy crap, somebody clue in Leibnitz that heat is energy!
You people look for any reason to get uppity don't you? I will rephrase that to clarify the implied meaning: The PU gets extremely hot and we convert the heat into usable energy. Happy now?
Frickin' trolls.
And exactly how has the Cassini mission failed so far?
It hasn't. It just caused a PR ruckus because of the RTGs on board. NASA has *never* had to deal with so many protesters before. They're trying to avoid having to do so again.
The problem is, that RTGs are huuuuge, for space stuff, and they really don't generate very much power, and introduce all sorts of cooling problems, cause they get hot.
Don't be ridiculous. An RTG with twice the power output would have weighed far less than the batteries, solar panels, and mounting. Not to mention that 5 pounds of PU is pretty small (remember, atomic number in the 90's). Cooling is the least of their concerns on Mars. (Or getting it there, for that matter). They had a working RTG system for the Mars rover. NASA just backed off of it because of the outrage over Cassini. (Insert comment about stupid tree huggers with oatmeal for brains who can't even take 10 minutes to find out what the hell they're protesting over. And that also goes for that whats-his-name physicist who complained about Cassini. "Oh no! A little plutonium in an indestructible box that has had flight testing during several accidents is going to kill us all!!!! Run for the #$*%#$*%$%$ hills!!!!")
ntil I googled a little and found the RHUs (Radioisotope Heater Units) on Sojourner.
:-(
Sojourner? You do realize that the Mars rover has those same heating elements? Since it's only a few grams of plutonium, they've managed to keep it pretty quiet. Unfortunately, the 3-5 pounds of Pu-238 required to replace the (insert explicative here) solar panels would draw too much attention. NASA's *still* licking their wounds from Cassini.
Oh, and just for your info, RTGs are passive units. This rock of PU gets really hot and we convert the heat into energy. The upside is that there's no moving parts, and about 75W per 2.5 pounds of PU-238. The downside is that you can never turn the thing off, so you sometimes have to dump some extra power.
Anybody out there like to comment? Is it a possibility? Could we come back with another rover and get Opportunity working again after it runs out of juice?
Opportunity's batteries will be dead (as in won't charge) inside a year of landing. Since the little guy can't rove without a stored supply of juice, he'll be as good as dead. That's actually one reason why scientists had wanted to use an RTG on the mission. An RTG could have kept it running for years, and in fact would have been one of the LAST components to kick the bucket. Sadly, NASA doesn't want another PR problem like with the Cassini probe.
Touche. I will argue however, that the election committee does know that you voted. It is your right to not allow them to link you to your vote, but they do know the transaction occurred, just not the details of it.
However, you also make a big assumption that's probably not true: that the native code software you're running must be compiled for 386/486. Nobody who cares about performance would run unoptimized, 386-compiled code. If you have a P4 doing intensive calculations, you're going to use software compiled for P4 using SSE2.
Does anyone around here fscking READ?
READ THIS PARAGRAPH AGAIN:
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
And what part of the fact that I used that example because I don't remember MMX/SSE/SSE2 instructions makes it so difficult for you to get through your thick head?
Now, I don't program in Java, but I understand that Java pointers are "smarter" than C/C++ pointers and that the JVM may be smarter at determining aliasing and be more aggressive about optimizing.
That's because Java uses references instead of pointers. When you have an object reference, the JVM might tweak the actual storage or linking situations to its hearts content. It may even do things like link a "new" object to an existing one if it can prove that the object is immutable. This is particularly handy for Strings, where creating the same string over and over would be a waste of memory and CPU.
Very observant. My original reply was to the poster who said it was impossible for the JVM to run faster than native. However, I realize that real world code is likely to be impacted by the time it takes the Hotspot compiler to do optimizations. (That's actually one of the reasons that Java has been such a good fit for servers.)
.5% increase in performance is not going to make a lick of difference when your code is only running for 300 milliseconds at a time. And in that 300 millisconds, a few hundred million instructions get processed.
Now here's the catch-22. All this stuff about making code perform better on the processor is BS. Unless you happen to have a platform designed for HPC (such as a Cray), your processor is otherwise spending that time doing nothing. (Memory wait states, cache misses, and other annoyances.) The thing to pay attention to is that the lost cycles don't matter. A
Unless programmers have a justification for a few thousand extra instructions a second (e.g. crypto cracking), their time would be better spent writing portable and maintainable code. The time they save from that maintainability can then be put into adding new features, and making their applications that much better. Especially since Java excels in the area of libraries. Dream up the most complex program you want, and I'll guarantee that 60-90% of the hard work has already been done for you.
Compare that to DLLs and staticly linked libs. Using C and C++ libraries back in the day, was more an exercise in frustration. Eventually you just said, "screw it!" and rewrote it yourself. Today, there are some very good libs for Unix, but there is still nowhere near the wealth of libs as Java has.
Pentium Pro code doesn't run on a 386. You're not making any sense, man.
Oh, for crying out loud. Since you're insisting on being denser than lead, let me spell it out for you:
1. Assume that Hotspot and the C compiler will generate the same code if told to optimize for the same processor.
2. Assume that the C implementation must generate code for the lowest common denominator. e.g. If your customers have 386s, you must generate code for a 386, no later.
Thus:
386:
C - The first code example
JVM - The first code example
PPro:
C - The first code example (since the customer can't or won't recompile)
JVM - The second code example (since the JVM is doing the compiling)
Got it? No? Then read it again.
No, it doesn't. The second piece of code will not run on a 386 like you said it must.
Of course it won't! That's the point. The Hotspot compiler will generate the second piece of code because it notices you're using a Pentium Pro. If the JVM was running on a 386, it would generate the first bit of code, just like the C compiler.
Also, GNU GCC compiles code for processors like i686 that still executes on i386 by not using the i686-only instructions.
As much as I wish they did, not all OSes use ELF binaries. Besides, generating binaries for multiple processors creates a great deal of bloat in the binaries. Not to mention that the JVM will be able to optimize for future processers (when they come out) while the GCC binaries will only be optimized through the current processor.
No way. I can believe that - given certain conditions - a good compiler can optimise code better than an assembler (I believe it, but i've never seen it; I'm told that this is the case), but I cannot believe that an interpreter can. Maybe I'm living in the past. Please correct me.
Wrong on many counts. First off, Hotspot is a native compiler. It just compiles at runtime. Secondly, a good compiler can outperform a human optimizer because it can juggle such concepts as superscaler packets, out of order execution, and predictive branching. These are things that take a human a long time to calculate and figure out effectively.
BTW, it's been this way for 10+ years. It's just taken Intel processors a long time to catch up. And the *#$@ things STILL don't do SuperScaler right. Nor do they have enough registers. Or proper task switching. In fact, I think Intel still recommends not using the built-in task switch instructions. Blech.
Here
You'll need OpenOffice or (ewww) MSOffice to read it. Alternatively, there's a Google cache, but it isn't very interesting without the images.
Please explain how this would be faster than writing the app in native code using an assembler and then I'll believe you.
Ok. My assembly is a little rusty, so bear with me. Let's say we have equivalent Java and C programs. They both have to run on a 386 or higher. (Bear with me. I haven't kept up with the MMX/SSE/SSE2 instructions, so I'll have to fake this a little.) Now, your C compiler will see that you want to store a 32 bit value, but has to generate code for a 386. So, it generates the code:
pop AX
STOSW 0x0005
pop AX
STOSW 0x0005
Even though the code may be running on a Pentium Pro (which is optmized for 32 bit code), it's still going to execute those 4 statements.
Now, the Java Hotspot compiler will start and notice the fact that you're running on a Pentium Pro. So when it converts the bytecode to machine code, it creates the following instructions:
pop EAX
STOD 0x0005
That's twice as fast as the C code!
Real code would tend to be running on modern processors, so this example is a little contrived. However, the JVM can (and will) use SSE instructions to do multiple calculations in one instruction, while the C code will be forced to generate non-SSE instructions to support the old Pentium Is out there.
Hotspot is also capable of analyzing the running code and regenerating even better assembly that would perform poorly in other circumstances. For example, let's say Hotspot notices that the bounds can't be exceeded on an array. Well, Hotspot will then recompile to remove the bounds checking.
Does that explain it better?
> > Which often benchmark faster than natively implemented code.
>
>You do realize that this is impossible, right?
What makes you say that? In fact, the original poster is quite correct. The JVM *can* generate faster code. You know how? By doing runtime optimizations. Compilers have to optimize for what *might* be the best performance profile at runtime. Also, they can only compile for the lowest common processor. (e.g. A pentium II) The Hotspot Java VM can optimize based on how the code is currently being used, undo an optimization if it starts slowing things down, and use processor specific instructions! Natively compiled code just can't beat that.
Activities that are "one's own business" are still not anonymous. You simply don't have to disclose information about your business. When you buy a beer from the store, you are conducting a business transaction between you, the store, and the provider of the goods. All those parties have a right to know about the transaction, and indeed cannot be prevented from knowing. Unless you can spin me a business transactional relationship where laws could interpreted so that parties must forget the details of the transaction, I stand by my original statement.
This whole idea of anonymity is getting out of hand. Guess what? Anonymity never existed and has never been protected by any government. The idea of being anonymous came out of people getting lost in the industrial culture. Before the industrial age, you tended to have few choices on who to buy from, and the store owner knew you and what you bought. He didn't carry anything that you didn't want people to know you bought, because it would soon be getting around if you did buy it. Now we're using computers to pull that all back together, but mostly for the old advantages of knowing how to serve the customer better. Budweiser is not really interested in gossiping with others that you bought a keg, so what's the big deal already?
I know people like the idea of having a protective shroud of mystery surrounding them. I hate to break it to you, but it's just a false sense of security. If you do something worth noticing, you *will* get noticed.
That said, Baxter's written some other great stuff, so you wouldn't do too badly picking up the wrong book.
ARRRGGGGHHHHH!!!!
If I never hear about his fantasy space squids again, it will be too soon.
No, it is *not* feasible today. No one has ever built a nanotube of a few feet, much less a nanotube of kilometers in length. We have built nuclear engines, and we do know they can work. Obviously, some of the more exotic designs quickly fall into the same amount of development time as nanotubes, but for high temperature, plasma producing engines, we've got NERVA/ROVER and Project Pluto under our belts. We *know* they can fly. Even Orion had quite a bit of work done on the pusher plate, shaped charges, and deployment mechanism (based off of a coke vending machine!).
Now I'm not saying that a skyhook is a bad or impossible idea. Just don't confuse what is already within the realm of engineering with what is still in the laboratory.
Tell that to the Japanese... =(
Sorry, I should have clarified. Super-weapons can make sense in major conflicts. However, modern warfare is not well suited to the super-weapons that are being developed. As a result, a much better bang for your buck is found in incremental development.
Besides, the atomic warhead was pretty much a single system. A bomb that exploded. Imagine if it was part of a complex tactical fighter!