Java #1 language on SourceForge
- Thread starter K.I.L.E.R
- Start date
Unless I have got the wrong end of the stick; tracback URL's need input which this forum does not provide.
http://jroller.com/page/matsh - should work.
BTW I'm not so sure the sheer volume of Java projects on SourceForge means a whole lot, except that it's easy to make Java projects
I think JIT stuff has its uses and misuses. Anyhoo even though I am a Java advocate I still dont think that just because there are more Java projects is a major indication of anything. I would like to get more numbers on numbers of active projects...and metrics on lines of code...and the type of projects meaning how complex they are and so on. Java has its shortcomings in terms of startup speed but it is coming along quite nicely.
Compilers NEED to become smarter.
We are still living in the stone age AFAIC.
We should all be doing high level programming and compilers should be the ones to optimise our code and yet there are still people who preach the reverse.
Personally I don't mind if there is a small drop in performance as long as my productivity increases a fairly large amount.
These days game companies don't even give a crap about performance(Didn't mean this as a generalisation it's just that while performance is still a priority, companies are now looking at faster ways of making money).
Look at EA's track record.
We are still living in the stone age AFAIC.
We should all be doing high level programming and compilers should be the ones to optimise our code and yet there are still people who preach the reverse.
Personally I don't mind if there is a small drop in performance as long as my productivity increases a fairly large amount.
These days game companies don't even give a crap about performance(Didn't mean this as a generalisation it's just that while performance is still a priority, companies are now looking at faster ways of making money).
Look at EA's track record.
arjan de lumens
Veteran
There are at least 2 metrics that performance should be judged by: Throughput and Response Time. I do in general get the impression that JIT compilers mostly solve the major throughput issues that Java otherwise has, but they still appear to suffer from serious response time issues.
That depends on which micro benchmarks you've been looking at.
I know things are not perfect as of yet but given engines such as AgentFX, do you really doubt Java's ability to perform well?
http://www.megacorpsonline.com/screenshots/
http://www.agency9.se/products/agentfx/
I know things are not perfect as of yet but given engines such as AgentFX, do you really doubt Java's ability to perform well?
arjan de lumens said:
http://www.megacorpsonline.com/screenshots/
http://www.agency9.se/products/agentfx/
arjan de lumens
Veteran
A JIT-compiled program should be quite fast - *AFTER* you have JIT-compiled the entire damn thing. Until you are done, you keep getting random slowdowns (this gets worse the larger your application is).
Alternatlvely, you can do Ahead-Of-Time compilation of Java just like you would do with C/C++, in which case any performance issues with JIT immediately become moot.
Alternatlvely, you can do Ahead-Of-Time compilation of Java just like you would do with C/C++, in which case any performance issues with JIT immediately become moot.
arjan de lumens
Veteran
Huh? Garbage collection pauses are a completely separate issue from JIT slowness, and AFAICS that problem is mostly solved; the incremental garbage collectors in recent Java versions (1.4 and up) seem to have developed to a point where you will no longer be annoyed, or even notice, the occasional garbage collection event.K.I.L.E.R said:
arjan de lumens
Veteran
I did read it, and still didn't get the impression that garbage collection problems, such as inadequate heap size (wtf?), were the main reason for Java program startup slowness.K.I.L.E.R said:
arjan de lumens said:
Modern Java JITs don't JIT the whole thing. They collect profile information and only JIT the "hotspots" aggressively. The rest is interpretated, or compiled with a non-optimizing compiler.
The difference between the client compiler, and server compiler in JVMs from Sun is that the client compiler is optimized for response time, so the optimizations the compiler chooses and which methods it chooses are determined by a heuristic to limit the amount of time consumed by the compilation thread. The server compiler can spend much more time on optimization (because servers want throughput), e.g. server compiler uses register coloring register allocator. The client compiler doesn't.
Java 6 has pretty good performance improvements and it is not even in beta stage yet. Performance is increasing as each version of JDK is being released. The only problem Java has is startup time along with GUI performance. But I think GUI performance is more the "what we feel"...meaning it isnt really slow but we perceive it to be slow. Look at Azureus for example. It is written in Java...but its very nicely done. Most people dont even know it is a Java app until they are told. I think the perceived problem with Swing being slow is that grey box that shows up as a component tries to refresh. I admit that is quite annoying but seeing that that is taken care of in the Mustang builds along with better compatibility with OpenGL I think things are quite bright. For those who disagree...well they disagree. If you go to Swing Connections...ah I will just post the link...http://java.sun.com/products/jfc/tsc/sightings/index.html you will find apps written purely in Java. They are great examples of what can be done if coding is done right. I have only checked out a few of the apps. Enjoy.
You can tell Azureus is a Java app by a few things: Terrible startup time, sluggish performance in the GUI sometimes. It just hangs a bit. Another thing that really gives it away is that it takes up an insane amount of memory compared to some other bit torrent clients.
Now, some of that could be bad coding. But those are generally all things I feel happen in Java apps that I've used. None of them have not felt sluggish.
Now, some of that could be bad coding. But those are generally all things I feel happen in Java apps that I've used. None of them have not felt sluggish.
arjan de lumens
Veteran
I don't know; I don't think so. It seems like an obvious optimization to do; doing it would presumably help startup/JIT-compilation times considerably.Saem said:
Similar threads
