The summary unnecessarily confuses things. It starts talking about launcher engines, while the real subject is an in-space low-thrust ion engine.
Ion engines run for months on end at low thrust but high efficiency, so the acceleration adds up when you are going, say, from one planet to another. They are not useful for launching anything to orbit.
Probably because the US perceived the old Galileo proposal as a threat and had it killed off years ago.
Not really. The Wired article you quote is from 2002 and no longer reflects reality.
Galileo was almost dead in the beginning of 2002, but it got resurrected within a couple of months. It has been very much alive and active for almost four years now. Launches and ground segment construction to commence in 2006. See Wikipedia for Galileo history.
The trouble with xylitol is that according to independent (= not funded by companies selling it) studies you have to eat humongous amounts of it constantly for it to have a measurable effect on your dental health.
And at those dosages it causes chronic diarrhea in a lot of people.
> This is the kind of stuff that would take NASA 20 years to do
What, get a rocket to blow up? And another to lift off a few feet and then tip over? NASA can do that too.
> Shit, we can't even go to the moon if we wanted to.
Sure you can. It's a question of money. A lot of people would like to pay less taxes rathern than more. It's a question of priorities. Talk to your congressman about that.
> All the tooling for the saturn rockets was DESTROYED.
An urban legend that just won't die. Some facilities were converted for new uses (e.g. STS). No, NASA engineers do not randomly go whacking equipment with axes. Some equipment can rust if there is no program (= money) to store it properly. Some equipment just gets old and no longer relevant (room-size computers with less computing power than your cell phone, electronic equipment for which nobody manufactures the required vacuum tubes, etc.)
A rednecky "the government is big and bad and can never do anything right" paranoia game is a fun game to play. Lets you work up to a nice adrenaline rush. Feel like a big man when you get to look down your nose at others. But don't actually believe it when it matters.
maybe it's possible that C/C++ compilers have improved as well.
Unfortunately it seems nobody really has come up with radically better malloc/free in 11 years. Small tweaks probably yes.
But if you benchmark your favorite C/C++ compiler (just run "free(malloc(16))" in a loop) you'll find that malloc/free indeed is of the order of 10 times slower than a similar loop in Java. There is no great conspiracy here; this is easy enough to verify yourself.
All memory in a Java program has to be allocated dynamically. Other languages offer static memory alternatives. Static memory use will be more efficient in many cases.
Here is how you can allocate variables in Java:
static int n; static char text[] = new char[10000];
The first line allocates a static variable, just like a static/extern int in C. The second line does indeed cause a dynamic allocation. This happens when the class is loaded and takes about 10 machine instructions. That is of the order of 0.000000001 seconds on a 1 GHz CPU.
It's a weird program that has so many static variables that 0.000000001 second once time startup costs add up to something that matters.
The Shootout Benchmarks are short-running microbenchmarks. Just-in-time compiled environments (e.g. Java and.NET) have a startup time that is as high as 100-200 milliseconds. You can imagine what that looks like in an Ackermann benchmark whose total runtime is 120 milliseconds. A 100-millisecond startup time matters less in real applications.
I converted the Ackermann and binary trees benchmarks from that site to run in a loop (to get JIT compilation happening). Java became faster than gcc. YMMV.
the people who keep telling me allocation in Java is slow (much slower than 10 instructions) are generally experienced Java programmers.
In that case "experience" does not mean "knowledgeable", it just means "old". Or "working for Microsoft and lying about the competition".
Java on my PC can allocate and garbage collect about 170 million objects per second. Account for loop overhead, GC, whatnot, and on a 1.6 GHz CPU 10 instructions per allocation sounds about right.
> And the article dares to justify its "assuptions" by > comparing Java against a language interpreter such as Perl.
Err... what? The article mentions Perl once, as an example of a C application.
The article says if you run that particular application you'll find that it spends 20-30% of its time in malloc() and free(). The points being that allocation speed matters in real applications, and that malloc+free is pretty slow.
> Try writing a Java program that eats less than 32k.
Huh? The terms "reference" and "pointer" mean the same thing in Java. It is the address of an object.
On, say, a 32-bit machine, the reference to an object is the exact same 4-byte value - the same size, shape, and numerical value as a pointer in C.
If you disassemble the machine code produced by Sun's JVM, object references go in registers and are dereferenced using the exact same instructions as what a C compiler produces.
Check out this article on real time and safety critical Java.
Googling for real time java should come up with RT Java VM vendors.
>...articles [...] which suggest that
> Java's real time support is fairly
> immature.
And keep in mind that there are companies (well, the one anyway) with competing technologies. Between their FUD spinning departments, employees, shareholders, and fanboys, a steady stream of non-factual Java-bashing is inevitable.
Java is being used, and has been used, for RT programming for years.
Anyway, in the (near) future, all the chain from the source (DVD player) to the screen (plasma, LCD,...) will be encrypted.
The signal still needs to be decrypted at some point. The TV's LCD panel wants unencrypted data. Somewhere in your TV there will be a chip that gets encrypted data in and gives decrypted data out. It'll take more work (and a screwdriver) to get at the decrypted pin of the chip, but it will be done.
Unplug TV's LCD panel, plug in a frame grabber that pretends to be an LCD.
Unless every LCD, projector, and CRT gets built-in decryption... TVs will be monolithic single-component devices with only "encrypted data in" connectors. Not any time soon.
The tech-savvy will easily find a way around this protection...it's only a matter of time.
And the time it takes is roughly ten seconds:
(1) Locate the digital output port in your DVD player.
(2) Plug said output port to your computer's frame grabber input port.
(3) Press "record", then press "play".
The unprotected data stream must come out of the DVD player, otherwise the TV can't get it. And if the TV can get it, a frame grabber card can.
All this kind of harrasment does is make more people get pirated stuff. Like CD copy protection: store-bought CDs don't work on my mp3 player, so I never buy CDs any more.
There is at least one Java JIT compiler today that does have stack-based objects. There is also work being done on the Sun JDK in that regard - watch out for JDK 6.0.
2) The nature of the Java language, with everything being derived from class Object, makes every cast dynamic.
Only casts that need to be dynamic need to be dynamic (duh). Runtime statistics collection, combined with dynamic decompilation, move cast checks up the call graph (and thus loop graph). All this is done today.
There is no "pausing a program" to do a cast. A checked cast is a "cmp" instruction, followed by a (usually non-taken) branch. No "pausing" is involved (what the heck is "pausing" anyway?). And even that "cmp" can often be moved up the call graph, moved outside loops, or eliminated.
Of course, proper OO programming style results in few checked casts. I write less than one cast per 10,000 lines of production Java code myself. And even a lowly PC can do tens of millions of dynamic casts per second. So...is there a real, measurable problem (in contrast to an imaginary FUD one)???
in C++, the compiler will inline member functions [...] The above is not possible with run-time optimization, because the VM can not have a graph of the whole program.
and
the compiler can assert that the underlying object is always of a certain class. This can not be done with bytecode languages
In fact, you have this exactly backwards.
These types of optimizations are exactly the ones that can be done, and are done, in Java.
The Hotspot Java compiler does not "assert that the underlying object is of a certain class". It can actually notice that, hey, this object seems to be of class X at least so far. So maybe it is always of that class. So Hotspot compiles a method that makes that assumption.
Here is the neat trick: if Hotspot's assumption turns out to be wrong, it discards the earlier compilation and recompiles with a looser assumption.
This is done today. It is called dynamic deoptimization. It means that "virtual" function calls can be compiled as direct jumps, and even inlined. If it turns out later that the call really needs to be virtual -> automatic recompilation on the fly and you are good to go again.
Dynamic length collision free hashing is called encryption. The "hash" is necessarily at least as long as the message itself (see pigeonhole principle.)
Something is wrong and really, really fucked up in America
And I've figured out what it is: your odd rant is considered "insightful" by some:-)
Even with AIDS running rampat, the police recently had the time to come over and arrest a couple of two-bit burglars I caught red-handed.
Ok, that wasn't in America. But I hope the police investigate such small crimes over there too.
And here we are, posting on/., even though there are starving children in the world. Everyone: stop immediately! You are hereby not allowed to do anything else less important until everyone in the world is fed and healthy!
In which country does the police not care about burglary?
Are you really sure that the police don't care, or is this more of a quick game of shout-at-"The-Man"-and-run-away-giggling? Do you have hard facts that show that the police do not care about burglary in the country in question? Or, if burglary is just an example, real grown-ups' facts on some other real crime?
I live in Finland, where some of the recent high profile bittorrent occurred. A while back, I stumbled on two burglars in my apartment building's basement. I called the cops, and they sure came in a hurry and collected the gentlemen in question into custody.
So in my limited experience, "Joe Average can't catch burglars" would be fantasy here at least. And if the police (paid with my tax euros) didn't care about burglars, I'd get off my duff and find out a way to make a public stink of it...
With enough money to fund attorneys you can apparently get other countries, especially the Finnish, to comply.
Total utter bullshit. If you have some real evidence of some impropriety, cough it up, instead of spreading vague libelous allegations.
I don't know if scientologists got someone raided here. But even those scumbags do have rights: if someone violates their copyright or other legal rights, they absolutely have the full protection of the law.
Neither you or I get to pick whom the legal system protects. It protects everyone equally. If that doesn't happen in your country, I'm truly sorry, but don't try to piss on others because they have it better.
How long will it be until any technology that is used for illegal deeds is at risk?
Is there real evidence of some technology being at risk?
The bittorrent raids were not targeted at bittorrent, they were against sites where the vast majority of stuff was covered by copyright and not legally redistributable.
Set up a site that truly and honestly distributes only legal Linux distro bittorrents and other such legal stuff. All tin foil hats aside, nobody will bother you if you do that.
Cars can be used in bank robberies. The use of a car in a bank robbery is a no-no. Owning a car is ok. It's not about the technology, or the device, it is about the particular use of that technology in a specific case. As long as the technology has at least some reasonably legitimate use (see e.g. silencers on hand weapons, or privately owned nuclear weapons.)
Slashdot Mirror
The summary unnecessarily confuses things. It starts talking about launcher engines, while the real subject is an in-space low-thrust ion engine.
Ion engines run for months on end at low thrust but high efficiency, so the acceleration adds up when you are going, say, from one planet to another. They are not useful for launching anything to orbit.
Not really. The Wired article you quote is from 2002 and no longer reflects reality.
Galileo was almost dead in the beginning of 2002, but it got resurrected within a couple of months. It has been very much alive and active for almost four years now. Launches and ground segment construction to commence in 2006. See Wikipedia for Galileo history.
Still begs the question: why is this news now?
The trouble with xylitol is that according to independent (= not funded by companies selling it) studies you have to eat humongous amounts of it constantly for it to have a measurable effect on your dental health.
And at those dosages it causes chronic diarrhea in a lot of people.
Clean teeth or clean undies, take your pick.
> This is the kind of stuff that would take NASA 20 years to do
What, get a rocket to blow up? And another to lift off a few feet and then tip over? NASA can do that too.
> Shit, we can't even go to the moon if we wanted to.
Sure you can. It's a question of money. A lot of people would like to pay less taxes rathern than more. It's a question of priorities. Talk to your congressman about that.
> All the tooling for the saturn rockets was DESTROYED.
An urban legend that just won't die. Some facilities were converted for new uses (e.g. STS). No, NASA engineers do not randomly go whacking equipment with axes. Some equipment can rust if there is no program (= money) to store it properly. Some equipment just gets old and no longer relevant (room-size computers with less computing power than your cell phone, electronic equipment for which nobody manufactures the required vacuum tubes, etc.)
A rednecky "the government is big and bad and can never do anything right" paranoia game is a fun game to play. Lets you work up to a nice adrenaline rush. Feel like a big man when you get to look down your nose at others. But don't actually believe it when it matters.
Unfortunately it seems nobody really has come up with radically better malloc/free in 11 years. Small tweaks probably yes.
But if you benchmark your favorite C/C++ compiler (just run "free(malloc(16))" in a loop) you'll find that malloc/free indeed is of the order of 10 times slower than a similar loop in Java. There is no great conspiracy here; this is easy enough to verify yourself.
Here is how you can allocate variables in Java:
The first line allocates a static variable, just like a static/extern int in C. The second line does indeed cause a dynamic allocation. This happens when the class is loaded and takes about 10 machine instructions. That is of the order of 0.000000001 seconds on a 1 GHz CPU.It's a weird program that has so many static variables that 0.000000001 second once time startup costs add up to something that matters.
The Shootout Benchmarks are short-running microbenchmarks. Just-in-time compiled environments (e.g. Java and .NET) have a startup time that is as high as 100-200 milliseconds. You can imagine what that looks like in an Ackermann benchmark whose total runtime is 120 milliseconds. A 100-millisecond startup time matters less in real applications.
I converted the Ackermann and binary trees benchmarks from that site to run in a loop (to get JIT compilation happening). Java became faster than gcc. YMMV.
In that case "experience" does not mean "knowledgeable", it just means "old". Or "working for Microsoft and lying about the competition".
Java on my PC can allocate and garbage collect about 170 million objects per second. Account for loop overhead, GC, whatnot, and on a 1.6 GHz CPU 10 instructions per allocation sounds about right.
> And the article dares to justify its "assuptions" by
> comparing Java against a language interpreter such as Perl.
Err... what? The article mentions Perl once, as an example of a C application.
The article says if you run that particular application you'll find that it spends 20-30% of its time in malloc() and free(). The points being that allocation speed matters in real applications, and that malloc+free is pretty slow.
> Try writing a Java program that eats less than 32k.
Lots of cell phone games manage to do this.
Huh? The terms "reference" and "pointer" mean the same thing in Java. It is the address of an object.
On, say, a 32-bit machine, the reference to an object is the exact same 4-byte value - the same size, shape, and numerical value as a pointer in C.
If you disassemble the machine code produced by Sun's JVM, object references go in registers and are dereferenced using the exact same instructions as what a C compiler produces.
Do you suppose, then, that this is the reason why modern Java virtual machines are based on JIT compilation or dynamic compilation?
On my computer at least, Java is compiled using a highly optimizing dynamic compiler. Java uses the same machine instruction set as C.
Googling for real time java should come up with RT Java VM vendors.
> ...articles [...] which suggest that
> Java's real time support is fairly
> immature.
And keep in mind that there are companies (well, the one anyway) with competing technologies. Between their FUD spinning departments, employees, shareholders, and fanboys, a steady stream of non-factual Java-bashing is inevitable.
Java is being used, and has been used, for RT programming for years.
The signal still needs to be decrypted at some point. The TV's LCD panel wants unencrypted data. Somewhere in your TV there will be a chip that gets encrypted data in and gives decrypted data out. It'll take more work (and a screwdriver) to get at the decrypted pin of the chip, but it will be done.
Unplug TV's LCD panel, plug in a frame grabber that pretends to be an LCD.
Unless every LCD, projector, and CRT gets built-in decryption... TVs will be monolithic single-component devices with only "encrypted data in" connectors. Not any time soon.
And the time it takes is roughly ten seconds:
(1) Locate the digital output port in your DVD player.
(2) Plug said output port to your computer's frame grabber input port.
(3) Press "record", then press "play".
The unprotected data stream must come out of the DVD player, otherwise the TV can't get it. And if the TV can get it, a frame grabber card can.
All this kind of harrasment does is make more people get pirated stuff. Like CD copy protection: store-bought CDs don't work on my mp3 player, so I never buy CDs any more.
> set ty=mx
> hackiis6.com
Non-authoritative answer:
hackiis6.com MX preference = 10, mail exchanger = hostmaster1.local.banneretcs.com
Hee hee, MS didn't have the cojones to put the mail server on hackiis6.com.
How to secure MS software: run as little of it as possible.
There is at least one Java JIT compiler today that does have stack-based objects. There is also work being done on the Sun JDK in that regard - watch out for JDK 6.0.
2) The nature of the Java language, with everything being derived from class Object, makes every cast dynamic.
Only casts that need to be dynamic need to be dynamic (duh). Runtime statistics collection, combined with dynamic decompilation, move cast checks up the call graph (and thus loop graph). All this is done today.
There is no "pausing a program" to do a cast. A checked cast is a "cmp" instruction, followed by a (usually non-taken) branch. No "pausing" is involved (what the heck is "pausing" anyway?). And even that "cmp" can often be moved up the call graph, moved outside loops, or eliminated.
Of course, proper OO programming style results in few checked casts. I write less than one cast per 10,000 lines of production Java code myself. And even a lowly PC can do tens of millions of dynamic casts per second. So ...is there a real, measurable problem (in contrast to an imaginary FUD one)???
and
the compiler can assert that the underlying object is always of a certain class. This can not be done with bytecode languages
In fact, you have this exactly backwards.
These types of optimizations are exactly the ones that can be done, and are done, in Java.
The Hotspot Java compiler does not "assert that the underlying object is of a certain class". It can actually notice that, hey, this object seems to be of class X at least so far. So maybe it is always of that class. So Hotspot compiles a method that makes that assumption.
Here is the neat trick: if Hotspot's assumption turns out to be wrong, it discards the earlier compilation and recompiles with a looser assumption.
This is done today. It is called dynamic deoptimization. It means that "virtual" function calls can be compiled as direct jumps, and even inlined. If it turns out later that the call really needs to be virtual -> automatic recompilation on the fly and you are good to go again.
Blogging is as much journalism as lap dancing is freedom of speech.
Dynamic length collision free hashing is called encryption. The "hash" is necessarily at least as long as the message itself (see pigeonhole principle.)
And I've figured out what it is: your odd rant is considered "insightful" by some :-)
Even with AIDS running rampat, the police recently had the time to come over and arrest a couple of two-bit burglars I caught red-handed.
Ok, that wasn't in America. But I hope the police investigate such small crimes over there too.
And here we are, posting on /., even though there are starving children in the world. Everyone: stop immediately! You are hereby not allowed to do anything else less important until everyone in the world is fed and healthy!
Are you really sure that the police don't care, or is this more of a quick game of shout-at-"The-Man"-and-run-away-giggling? Do you have hard facts that show that the police do not care about burglary in the country in question? Or, if burglary is just an example, real grown-ups' facts on some other real crime?
I live in Finland, where some of the recent high profile bittorrent occurred. A while back, I stumbled on two burglars in my apartment building's basement. I called the cops, and they sure came in a hurry and collected the gentlemen in question into custody.
So in my limited experience, "Joe Average can't catch burglars" would be fantasy here at least. And if the police (paid with my tax euros) didn't care about burglars, I'd get off my duff and find out a way to make a public stink of it...
I keep seeing comments like this, and they confuse me a bit.
Is the implication that one type of crime should not be investigated if another randomly selected type doesn't first enjoy a 100% solved rate?
That can't really be it, can it?
Total utter bullshit. If you have some real evidence of some impropriety, cough it up, instead of spreading vague libelous allegations.
I don't know if scientologists got someone raided here. But even those scumbags do have rights: if someone violates their copyright or other legal rights, they absolutely have the full protection of the law.
Neither you or I get to pick whom the legal system protects. It protects everyone equally. If that doesn't happen in your country, I'm truly sorry, but don't try to piss on others because they have it better.
How long will it be until any technology that is used for illegal deeds is at risk?
Is there real evidence of some technology being at risk?
The bittorrent raids were not targeted at bittorrent, they were against sites where the vast majority of stuff was covered by copyright and not legally redistributable.
Set up a site that truly and honestly distributes only legal Linux distro bittorrents and other such legal stuff. All tin foil hats aside, nobody will bother you if you do that.
Cars can be used in bank robberies. The use of a car in a bank robbery is a no-no. Owning a car is ok. It's not about the technology, or the device, it is about the particular use of that technology in a specific case. As long as the technology has at least some reasonably legitimate use (see e.g. silencers on hand weapons, or privately owned nuclear weapons.)
So the article doesn't say whether the RIAA was involved. The police here don't usually kiss and tell about such things.
Move along, nothing to see here.