Java is inherently slow in the fact that it is an interpreted language. When you compile your source, it is turned into Java bytecode, which is converted to native code while its executed. Thus, the overhead of translating, which is generally slow.
There are some advances around this, that people have done. Caching native code is one way, where if a function is executed repeatedly, the first one is slow, then the next run-through will be much faster. Another way is to do something perl-esque, and translate the whole application to native code before running, but this takes some time to do.
The last way to speed it up would be a hardware coprocesser that spoke Java bytecodes natively.
Java is usable in the servlet arena, but...
on
Java Success Stories
·
· Score: 2
Java is usable in the servlet arena, however Java has two things that cause people like me to choose other solutions (C/C++ is what I am using, perl is another good choice, as well as Python, and plenty of other tools which I forgot to name.)
The first problem with it is its lack of speed. On a server answering a ton of transactions, the JVM needs to have some sort of native machine code cache where Java bytecodes are stored as native code for sake of speed. What would make this a nonissue for servers would be a PCI card (preferably two models -- one 32-bit, one 64-bit wide, both able to select 33/66 Mhz depending on the main bus speed) with a good Java bytecode processor. If these were made inexpensive enough, and put on the motherboards on new SPARC boxes as coprocessers, this would solve the slowness problem.
The second problem is the bad perception of Java. Two big whammies -- Blackdown, and the pulling out of the standards committee hit Java quite close together.
Not to say that Java is a lost cause. When Java was the hot thing amongst computer groups, every vendor with something that runs a CPU got some sort of JVM out for it. So, the write-once, run anywhere thing does still apply. Java 1.0 was, for the most part, a toy, but with the latest iteration, it really has matured into something usable.
Personally, I really don't know as much as I should about Java, but I have seen some very cool things done with it (www.jars.com has a good amount of examples of this, and the main application that drives www.hushmail.com is another good example.) to write it off as a toy language.
As for Sun, its a mixed bag. They come up with some good things, and then trip on themselves. I don't want to write them off just yet.
Is there even a place for DVD-Audio? Most people wouldn't buy new players for one or two CD's, as DVD-Audio will be pretty expensive at first (as manufacturers ramp up production), and it will take more time to get the DVD electronics in a small package, like a CD Walkman.
This reminds me of the stuff when DAT came out. DAT was a failure because of all the arguing over copy-protection (as well as being non-random access, but that was less of an issue than having copy-protection schemes voted on by the US Congress).
DVD-Audio has no place in high-end audio either. People who spend thousands for professional gear tend to stick to standard formats (I've noticed a migration to.WAV files, which is the one of the best ways to store a master because it can easily be converted to an MP3, burnt to a track on a CD, spat out digitally using S/PDIF, or dumped to DAT.) Storing a master on DVD-Audio is not a concept professional sound people would consider -- so many other alternatives, DAT, burnable CD's, MD's, that another entry in this market really wouldn't fly.
So, if the high-end audiophiles do not have a use for this technology, and Joe Average has to buy fairly expensive equipment, from people who assume he is a thief bent on stealing their music, to listen to discs that sound pretty much the same to an untrained ear, then there isn't much real mass market here.
The only place I see a place is selling to audio buffs who have to have the best of everything to listen to their CD's, and have to have 24/96 no matter what. However, these people are fairly rare, and probably would resent having to get yet another piece of gear to stick in their rack.
Slashdot Mirror
Java is inherently slow in the fact that it is an interpreted language. When you compile your source, it is turned into Java bytecode, which is converted to native code while its executed. Thus, the overhead of translating, which is generally slow.
There are some advances around this, that people have done. Caching native code is one way, where if a function is executed repeatedly, the first one is slow, then the next run-through will be much faster. Another way is to do something perl-esque, and translate the whole application to native code before running, but this takes some time to do.
The last way to speed it up would be a hardware coprocesser that spoke Java bytecodes natively.
Java is usable in the servlet arena, however Java has two things that cause people like me to choose other solutions (C/C++ is what I am using, perl is another good choice, as well as Python, and plenty of other tools which I forgot to name.)
The first problem with it is its lack of speed. On a server answering a ton of transactions, the JVM needs to have some sort of native machine code cache where Java bytecodes are stored as native code for sake of speed. What would make this a nonissue for servers would be a PCI card (preferably two models -- one 32-bit, one 64-bit wide, both able to select 33/66 Mhz depending on the main bus speed) with a good Java bytecode processor. If these were made inexpensive enough, and put on the motherboards on new SPARC boxes as coprocessers, this would solve the slowness problem.
The second problem is the bad perception of Java. Two big whammies -- Blackdown, and the pulling out of the standards committee hit Java quite close together.
Not to say that Java is a lost cause. When Java was the hot thing amongst computer groups, every vendor with something that runs a CPU got some sort of JVM out for it. So, the write-once, run anywhere thing does still apply. Java 1.0 was, for the most part, a toy, but with the latest iteration, it really has matured into something usable.
Personally, I really don't know as much as I should about Java, but I have seen some very cool things done with it (www.jars.com has a good amount of examples of this, and the main application that drives www.hushmail.com is another good example.) to write it off as a toy language.
As for Sun, its a mixed bag. They come up with some good things, and then trip on themselves. I don't want to write them off just yet.
Is there even a place for DVD-Audio? Most people wouldn't buy new players for one or two CD's, as DVD-Audio will be pretty expensive at first (as manufacturers ramp up production), and it will take more time to get the DVD electronics in a small package, like a CD Walkman.
.WAV files, which is the one of the best ways to store a master because it can easily be converted to an MP3, burnt to a track on a CD, spat out digitally using S/PDIF, or dumped to DAT.) Storing a master on DVD-Audio is not a concept professional sound people would consider -- so many other alternatives, DAT, burnable CD's, MD's, that another entry in this market really wouldn't fly.
This reminds me of the stuff when DAT came out. DAT was a failure because of all the arguing over copy-protection (as well as being non-random access, but that was less of an issue than having copy-protection schemes voted on by the US Congress).
DVD-Audio has no place in high-end audio either. People who spend thousands for professional gear tend to stick to standard formats (I've noticed a migration to
So, if the high-end audiophiles do not have a use for this technology, and Joe Average has to buy fairly expensive equipment, from people who assume he is a thief bent on stealing their music, to listen to discs that sound pretty much the same to an untrained ear, then there isn't much real mass market here.
The only place I see a place is selling to audio buffs who have to have the best of everything to listen to their CD's, and have to have 24/96 no matter what. However, these people are fairly rare, and probably would resent having to get yet another piece of gear to stick in their rack.