Thanks for the tip, I will try to find this edition of LJ.
On the "collective IQ" of the Lobby, well, at least we don't have every single thread beginning with "FIRST POST!!" messages:) Now serious - any advocacy group will have some excesses, some people on a jihad, some kids pretending to be experts. And not being myself a Linux (or any OS's) advocate, I frequently read in/. too much BS written by pro-Linux zealots. One always needs to filter. As a long-time member of the JL, I already know the frequent posters so I can focus in the good posts and ignore the noise (unfortunately we miss something like/.'s moderation).
I am just waiting for Linux 2.4.0 + XFree 4
on
Java Rocks On Linux
·
· Score: 1
...although I guess the JDK still needs to be updated to use XFree4's DGA. I hope Blackdown's 1.3.0beta is out soon, as they're more likely to be first with such optimizations.
Anyway Linux 2.2 can be more scaleable, you only need to avoid native threads (like TowerJ does). OTOH, native threads are good with many CPUs. An implementation that uses multiple native threads, but can multiplex many Java threads per native thread, is probably the best.
This is a common error for me -- "teste" means "test" in Portuguese (which is my native language), so I guess my language switch failed for just one milissecond. And I was not aware of any meaning for "teste" in English (my knowledge of slang is limited) but I can guess from the context.:-))
Java is not slow; Java has some slow spots, which is different -- it affects you depending on the job. For example, Java has no select() yet so you're forced to have one thread per simultaneous connection in servers (very bad). Java2D's implementation sucks too, because it doesn't use available HW acceleration. Some libraries can be improved. And the JVM comes with a price in memory.
On the other hand, the server-side-JSP-based-app-including-our-own-CORBA- security-and-object-persistency-services that I wrote recently just rocks (but that's because we're not into the 1000's of users).
"AFAIK there is no way to eliminate it from random-access reading and writing of arrays."
This is "almost" true -- if you can proof that the index falls in the array's range trough other optimizations (maybe inlining the array code, so some index parameter benefits from the callee's analysis) you can eliminate the checks.
Another trick IBM is using is having the compiler to know about special libraries (like their Matrix and Complex libs) and doing many (otherwise unsafe) optimizations only in trusted sections of that code. And of course, VMs and static compilers might offer switches to do away with certain checks (maybe in a per-class or per-package base). I think at least TowerJ allows that. The risk is a good tradeoff for many programs -- if your action game crashes because you used unsafe optimizations, nobody is gonna lose a life or a million USD, so why not doing it.
Add the fact that most boundchecks happen inside tight loops that iterate arrays in a predictable way, and the unoptimizable random accesses that you can't optimize out become much less important (at least, for many apps).
"What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper."
This is one case where inlining would sometimes enable the compiler to kill boundschecking. For example, a pop() immediately followed by a push()on the same stack would be easy to optimize, at least to have a single check instead of two.
"We have to be careful not over-sell hoisting and lead people the wrong way in their programming."
Amen brother. BTW, the IBM stuff mention is not public yet (some of their optimizations depend on fixes in the JLS to be compliant), I loved the papers but I will hold my breadth when I see it in the wild, so I can run my JavaQuak\b\b\bscientific software.:-)
Simplicity: Java is considered simple precisely when compared to C++, not to C. A well-architected solution in C++ is possible, but considerably more painful to achieve than a well-architected equivalent in Java.
Garbage Collection: You are utterly wrong there. There's no such thing as "third party GC tools for Java". You might be extremely confused because different JVM implementors boast their own GC as a great feature. It's not even possible to plug a 3rd-party GC engine to ANY Java VM or compiler I know of. And safe GC in C++ depends on enforcing restrictions that break 99% of the legacy code and 3rd-party libs around, and performance will likely be inferior because C++ was not designed for that, and of course we will still live with manual memory mgmt (yet another hybrid situation to make things complex and risky).
Standard Libraries: Yes, there's a huge number of excellent, even multiplatform, libs for C++. And how good are they when they're not standards? How many C++ GUI libs do any experienced developer waste time learning, porting... along the years? Ever heard about reuse? (hint: if component O1 uses L1 do do X, and O2 uses L2 to do the same X task, you have either trouble or bloat if you need to use both O1 and O2).
Bounds checking on arrays: Agree. Now, go fix all 3rd-party and legacy code that you rely on and was implemented without boundschecked arrays and exposes raw arrays in public interfaces. Once again, Java's advantage is not that I can do something the right way, but that everybody does it the right way.
Printing stack traces from exceptions: You can always spend your money and/or time (if you have the necessary discipline) to use C++ libraries and code instrumenting debuggers. Java does it for free, easy, and every time. Add this to the safer typesystem, bounds checks, library checks and you know why so many Java developers never use any debugger.
Reflection: This is hilarious. C++'s RTTI is pitiful compared to Java's reflection -- in the same measure that Java's is, compared to Smalltalk's, but I don't think you have minimal experience in metaprogramming.
On the other hand, some standard libraries (like Swing) have performance problems that can't be fixed just by throwing in good code generation, and the JVM still fails to make use of hardware acceleration wherever possible -- a world-class JIT compiler will compete with a static compiler, but never with dedicated hardware (e.g. for 2D graphics). And there's a lot to do on platform-specific tuning (AWT, threads, memory mgmt, I/O).
This is only to make things clear, as I guess all the previous replies should originate from people thinking "duh, so why does it still look slow here".
But just to add another plus, array bounds checking is not a problem. Both Symantec's and IBM's latest JIT compilers seem to do a great job in avoiding these checks or moving them out of loops. In IBM, this is not even an issue anymore. And you still have full safety! Compare this to a C/C++ program that aims to be safe while doing lots of arrays -- it needs manual boundchecks (more likely, encapsulated by some array class's operator[]) and these checks can't be removed by an optimizing compiler as much as Java's can (hint for C fans: pointers). IBM has a ton of research to make Java *the* language for number crunching, and they have already shown very exciting results (up to 90% of FORTRAN performance).
One important reason for open-source benchmarks is that people are able to evaluate the benchmarks themselves. You shouldn't blindly assume that a benchmark is worth anything only because it's published by a famous magazine, company or organization.
I have produced a couple articles on Java performance (JavaLobby & JavaPro Aug'99) and unfortunately, some popular Java benchmarks exhibit various flaws (Caffeine, jBYTEmark, JMark). Even good benchmarks (Volano) are sometimes hard to analyse because I have no access to the sources and I don't know exactly what the benchmark is doing. Statistics without context are useless in the best case, and dishonest in the worst.
I have eaten roasted ants many years ago (before I even knew what a computer was) and that was not bad. I think a scale is needed:
A minor bug, like bad painting of GUI -- you can choose the bug, cook it, use salt etc.
A medium severity bug, that doesn't cause data loss -- you should eat ugly and nasty bugs like roaches.
A severe bug, that destroys data, compromises security or makes your CPU melt -- you should eat live roaches, in a single gulp (think about those little legs and wings moving inside your mouth).
This practice would do more for software quality than all CASE tools, methodologies, objects, formal proofs, design-by-contract, lint programs etc. combined.:-)) OTOH, even less women would be excited to apply for CS courses.:)
I'm surprise that the issue didn't surface in a Linux advocacy site, so there it goes: Artists should be paid for their work, we can understand the necessity for some control on pirated distribution. Now, suppose some solution is really feasible (trusted hardware, stronger protection than MS's, whatever).
This is NOT a good thing, because this means I cannot use the music I bought the way I like. I cannot freely combine my music gear (reader, mixers, amplifiers, etc.). I cannot edit the music to remove the vocals and do a karaoke, or something like that. Idem for video, what about pasting snippets of movies into personal productions just for fun?? Some guys I gave a course to decided to make fun of me (I wonder why?) and they grabbed a piece of Star Wars and edited it to put my face in Darth Vader's... it was just a good laugh, there was no financial implication, just a few seconds of AVI, I still pay for the video rental if I want to see the movie. And we have the right to use any media we paid for if it is for any kind of private enjoyment -- a good, common example is grabbing samples to make a personal desktop theme from your favorite band or movie. If you don't post the theme for everybody to download it, I see no IP violating, no piracy.
1) The idiots writing "FIRST POST!!" messages in/. - what is this, kindergarten? CmdrTaco should require a minimum age (say, 5) to join the site.
2) The Neanderthals making laws to stop science, or to stop cryptographic software, or to stop the Sun (who orbits the Earth, I suppose creationists believe this too 'cause it's in that old book) and anything else that cannot be stopped
3) 90% of television's content (to mention only one major offender)
4) All people programming in [insert despicable obsolete language here] who didn't evolve either
I'm not a Linux kernel expert, but I suppose Linux and his gang would have to glue XFS to the VFS... but I don't think they would complain about that:)
How surprising that some company who dependes completely on Office is defending Microsoft monopoly, isn't it?:)
This is all right, but what happend with serious journalism -- e.g. giving space for all conflicting opinions? as it stands it's only pro-MS testimonials.
Although we have important pioneers since Babbage & Ada, I'd bet the guys responsible for 90% of what we know as computer science are still alive:) so that's why there's no bronze for them.
But when Don Knuth, Dijkstra, Hoare, Kay, [insert favorite here -- Linus?] are dead, I want big statues for them!
This is only new BS from an old and well-known source of anti-CORBA FUD. Now, before you fear of CORBA's death: Although I haven't yet read the Component spec, I don't see why it should mean end of language neutrality. CORBA has no binary standards for any other spec (except Java), all standards we need are source and wire; binary is a bonus.
Additionally, you should know the OMG process. OMG has no design/development staff - they issue RFPs, collect proposals, discuss them and eventually they ADOPT something, which needs to have at least prototypical implementation. EJB happened to be a great spec, it has existing implementations to proof that it works, so why not using it? All OMG need to do is additional work to map the same designs, interfaces and rules to the general environments/languages -- that's why the Component spec is bigger than the EJB spec. If OMG were dropping language independence, they would just adopt EJB as-is.
Only the uninformed developer, or the typical pointy-haired manager, will take this bullshit seriously.
Slashdot Mirror
Thanks for the tip, I will try to find this edition of LJ.
:) Now serious - any advocacy group will have some excesses, some people on a jihad, some kids pretending to be experts. And not being myself a Linux (or any OS's) advocate, I frequently read in /. too much BS written by pro-Linux zealots. One always needs to filter. As a long-time member of the JL, I already know the frequent posters so I can focus in the good posts and ignore the noise (unfortunately we miss something like /.'s moderation).
On the "collective IQ" of the Lobby, well, at least we don't have every single thread beginning with "FIRST POST!!" messages
...although I guess the JDK still needs to be updated to use XFree4's DGA. I hope Blackdown's 1.3.0beta is out soon, as they're more likely to be first with such optimizations.
Anyway Linux 2.2 can be more scaleable, you only need to avoid native threads (like TowerJ does). OTOH, native threads are good with many CPUs. An implementation that uses multiple native threads, but can multiplex many Java threads per native thread, is probably the best.
This is a common error for me -- "teste" means "test" in Portuguese (which is my native language), so I guess my language switch failed for just one milissecond. And I was not aware of any meaning for "teste" in English (my knowledge of slang is limited) but I can guess from the context. :-))
Java is not slow; Java has some slow spots, which is different -- it affects you depending on the job. For example, Java has no select() yet so you're forced to have one thread per simultaneous connection in servers (very bad). Java2D's implementation sucks too, because it doesn't use available HW acceleration. Some libraries can be improved. And the JVM comes with a price in memory.
- security-and-object-persistency-services that I wrote recently just rocks (but that's because we're not into the 1000's of users).
On the other hand, the server-side-JSP-based-app-including-our-own-CORBA
"AFAIK there is no way to eliminate it from random-access reading and writing of arrays."
:-)
This is "almost" true -- if you can proof that the index falls in the array's range trough other optimizations (maybe inlining the array code, so some index parameter benefits from the callee's analysis) you can eliminate the checks.
Another trick IBM is using is having the compiler to know about special libraries (like their Matrix and Complex libs) and doing many (otherwise unsafe) optimizations only in trusted sections of that code. And of course, VMs and static compilers might offer switches to do away with certain checks (maybe in a per-class or per-package base). I think at least TowerJ allows that. The risk is a good tradeoff for many programs -- if your action game crashes because you used unsafe optimizations, nobody is gonna lose a life or a million USD, so why not doing it.
Add the fact that most boundchecks happen inside tight loops that iterate arrays in a predictable way, and the unoptimizable random accesses that you can't optimize out become much less important (at least, for many apps).
"What you mentioned about loops is called "hoisting" and yes this is happeneing, but an array implementation of a stack, for instance, must still check every access to make sure its within the memory area of the array proper."
This is one case where inlining would sometimes enable the compiler to kill boundschecking. For example, a pop() immediately followed by a push()on the same stack would be easy to optimize, at least to have a single check instead of two.
"We have to be careful not over-sell hoisting and lead people the wrong way in their programming."
Amen brother. BTW, the IBM stuff mention is not public yet (some of their optimizations depend on fixes in the JLS to be compliant), I loved the papers but I will hold my breadth when I see it in the wild, so I can run my JavaQuak\b\b\bscientific software.
Simplicity: Java is considered simple precisely when compared to C++, not to C. A well-architected solution in C++ is possible, but considerably more painful to achieve than a well-architected equivalent in Java.
Garbage Collection: You are utterly wrong there. There's no such thing as "third party GC tools for Java". You might be extremely confused because different JVM implementors boast their own GC as a great feature. It's not even possible to plug a 3rd-party GC engine to ANY Java VM or compiler I know of. And safe GC in C++ depends on enforcing restrictions that break 99% of the legacy code and 3rd-party libs around, and performance will likely be inferior because C++ was not designed for that, and of course we will still live with manual memory mgmt (yet another hybrid situation to make things complex and risky).
Standard Libraries: Yes, there's a huge number of excellent, even multiplatform, libs for C++. And how good are they when they're not standards? How many C++ GUI libs do any experienced developer waste time learning, porting... along the years? Ever heard about reuse? (hint: if component O1 uses L1 do do X, and O2 uses L2 to do the same X task, you have either trouble or bloat if you need to use both O1 and O2).
Bounds checking on arrays: Agree. Now, go fix all 3rd-party and legacy code that you rely on and was implemented without boundschecked arrays and exposes raw arrays in public interfaces. Once again, Java's advantage is not that I can do something the right way, but that everybody does it the right way.
Printing stack traces from exceptions: You can always spend your money and/or time (if you have the necessary discipline) to use C++ libraries and code instrumenting debuggers. Java does it for free, easy, and every time. Add this to the safer typesystem, bounds checks, library checks and you know why so many Java developers never use any debugger.
Reflection: This is hilarious. C++'s RTTI is pitiful compared to Java's reflection -- in the same measure that Java's is, compared to Smalltalk's, but I don't think you have minimal experience in metaprogramming.
On the other hand, some standard libraries (like Swing) have performance problems that can't be fixed just by throwing in good code generation, and the JVM still fails to make use of hardware acceleration wherever possible -- a world-class JIT compiler will compete with a static compiler, but never with dedicated hardware (e.g. for 2D graphics). And there's a lot to do on platform-specific tuning (AWT, threads, memory mgmt, I/O).
This is only to make things clear, as I guess all the previous replies should originate from people thinking "duh, so why does it still look slow here".
But just to add another plus, array bounds checking is not a problem. Both Symantec's and IBM's latest JIT compilers seem to do a great job in avoiding these checks or moving them out of loops. In IBM, this is not even an issue anymore. And you still have full safety! Compare this to a C/C++ program that aims to be safe while doing lots of arrays -- it needs manual boundchecks (more likely, encapsulated by some array class's operator[]) and these checks can't be removed by an optimizing compiler as much as Java's can (hint for C fans: pointers). IBM has a ton of research to make Java *the* language for number crunching, and they have already shown very exciting results (up to 90% of FORTRAN performance).
One important reason for open-source benchmarks is that people are able to evaluate the benchmarks themselves. You shouldn't blindly assume that a benchmark is worth anything only because it's published by a famous magazine, company or organization.
I have produced a couple articles on Java performance (JavaLobby & JavaPro Aug'99) and unfortunately, some popular Java benchmarks exhibit various flaws (Caffeine, jBYTEmark, JMark). Even good benchmarks (Volano) are sometimes hard to analyse because I have no access to the sources and I don't know exactly what the benchmark is doing. Statistics without context are useless in the best case, and dishonest in the worst.
I have eaten roasted ants many years ago (before I even knew what a computer was) and that was not bad. I think a scale is needed:
:-)) OTOH, even less women would be excited to apply for CS courses. :)
A minor bug, like bad painting of GUI -- you can choose the bug, cook it, use salt etc.
A medium severity bug, that doesn't cause data loss -- you should eat ugly and nasty bugs like roaches.
A severe bug, that destroys data, compromises security or makes your CPU melt -- you should eat live roaches, in a single gulp (think about those little legs and wings moving inside your mouth).
This practice would do more for software quality than all CASE tools, methodologies, objects, formal proofs, design-by-contract, lint programs etc. combined.
... lady Ada's time.
I'm surprise that the issue didn't surface in a Linux advocacy site, so there it goes: Artists should be paid for their work, we can understand the necessity for some control on pirated distribution. Now, suppose some solution is really feasible (trusted hardware, stronger protection than MS's, whatever).
This is NOT a good thing, because this means I cannot use the music I bought the way I like. I cannot freely combine my music gear (reader, mixers, amplifiers, etc.). I cannot edit the music to remove the vocals and do a karaoke, or something like that. Idem for video, what about pasting snippets of movies into personal productions just for fun?? Some guys I gave a course to decided to make fun of me (I wonder why?) and they grabbed a piece of Star Wars and edited it to put my face in Darth Vader's... it was just a good laugh, there was no financial implication, just a few seconds of AVI, I still pay for the video rental if I want to see the movie. And we have the right to use any media we paid for if it is for any kind of private enjoyment -- a good, common example is grabbing samples to make a personal desktop theme from your favorite band or movie. If you don't post the theme for everybody to download it, I see no IP violating, no piracy.
I think it was 6 * 9, or something like that (!= 42), which is the whole point of it :)
Proofs:
/. - what is this, kindergarten? CmdrTaco should require a minimum age (say, 5) to join the site.
1) The idiots writing "FIRST POST!!" messages in
2) The Neanderthals making laws to stop science, or to stop cryptographic software, or to stop the Sun (who orbits the Earth, I suppose creationists believe this too 'cause it's in that old book) and anything else that cannot be stopped
3) 90% of television's content (to mention only one major offender)
4) All people programming in [insert despicable obsolete language here] who didn't evolve either
I'm not a Linux kernel expert, but I suppose Linux and his gang would have to glue XFS to the VFS... but I don't think they would complain about that :)
if (Solaris) then SCSI.
How surprising that some company who dependes completely on Office is defending Microsoft monopoly, isn't it? :)
This is all right, but what happend with serious journalism -- e.g. giving space for all conflicting opinions? as it stands it's only pro-MS testimonials.
Although we have important pioneers since Babbage & Ada, I'd bet the guys responsible for 90% of what we know as computer science are still alive :) so that's why there's no bronze for them.
But when Don Knuth, Dijkstra, Hoare, Kay, [insert favorite here -- Linus?] are dead, I want big statues for them!
This is only new BS from an old and well-known source of anti-CORBA FUD. Now, before you fear of CORBA's death: Although I haven't yet read the Component spec, I don't see why it should mean end of language neutrality. CORBA has no binary standards for any other spec (except Java), all standards we need are source and wire; binary is a bonus.
Additionally, you should know the OMG process. OMG has no design/development staff - they issue RFPs, collect proposals, discuss them and eventually they ADOPT something, which needs to have at least prototypical implementation. EJB happened to be a great spec, it has existing implementations to proof that it works, so why not using it? All OMG need to do is additional work to map the same designs, interfaces and rules to the general environments/languages -- that's why the Component spec is bigger than the EJB spec. If OMG were dropping language independence, they would just adopt EJB as-is.
Only the uninformed developer, or the typical pointy-haired manager, will take this bullshit seriously.
A _big_ chunk of JBuilder's code is written in Java (I've read some Borland guy saying 80%)... so they have got only 20% to actually port or rewrite.