Interesting but correlates with the number of files and libraries the interpreter must read or parse. Anything that's quite self-contained is fast; anything that needs to look up and read lots of files is slow.
All I can say is that Java startup time is abysmal. Still, and after fifteen years. Java was dead slow in the 90's and it's dead slow these days when compared to anything else. I love Clojure but Java startup time rules it out for anything else but long-running processes or, when coding, using repl via swank.
I know it's great fun, and fashionable to bash Java, but the Java startup time is slow, because the default settings are optimized for long running processes.
If you want a quicker execution time for a short lived program, just tweak the settings. But then Java may not be the best choice for short lived 'scripting' anyway.
So yes, it rules it out, unless you know what you're doing.
Java is indeed slow to start. So slow, in fact, that Maven created a "Maven Shell" project to avoid re-launching a JVM for each build: http://shell.sonatype.org/
The primary disadvantage of Java/.NET compared to C/C++ is the memory overhead. Generational garbage collectors can require up to 5 times as much memory as their explicitly-managed equivalents. [1]
Space overhead doesn't matter for most applications. But it makes Java a no-go for embedded devices and data-intensive domains.
I couldn't access the paper itself, but the excerpts are indeed interesting.
Another disadvantage of using a Garbage collector, is that it's hard to predict when the JVM will "freeze" to collect garbage memory. This makes standard Java relatively ill-suited for real-time applications. For these, you need to consider technologies such as http://en.wikipedia.org/wiki/Real_time_Java
The problem with those GC freezes, is that they can be quite long in big memory-intensive applications. This is a reason for the work on alternative parallel GCs. The complexity and relative mysteriousness of the GC makes it hard to tune. Dhanji, a Google Wave engineer, who wrote the "Dependency Injection" book, and is the lead developer of sitebricks, wrote a great article on this subject : http://dhanji.posterous.com/taking-out-the-trash-and-other-c...
All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
"We present a novel experimental methodology that lets us treat unaltered Java programs as if they used explicit memory management. Our system generates exact object reachability information by processing heap traces with the Merlin algorithm [34, 35]. It then re-executes the program, invoking free on objects just before they become unreachable. Since this point is the latest that a programmer could explicitly free objects, our approach conservatively approximates explicit memory management."
All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
You're on the right track, but with a twist: Explicit memory management works the opposite way around. Freeing an object when it goes out of scope, like the paper's oracle, is the worst case scenario. A real programmer is free to optimize and release memory before that, even if the object still has references.
In practice, I doubt the difference matters. The primary focus of memory management in C/C++ is avoiding leaks from objects that were never freed and can never be freed because all their references are out-of-scope. Programmers have a small window to free memory, before the pointers are out of scope, but only once the object isn't needed. There's not much room for optimization.
There's RTSJ (or jrts) specifically designed for real-time use. It has an incremental GC that is overall less efficient, but is guaranteed to have bounded wait times.
Interestingly, Java and Clojure have decidedly different startup times on my machine.
A trivial hello-world in Java takes ~130 ms on my Debian sid box with « OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-4) / OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) ». This is with all default runtime options.
The program « (ns hello (:gen-class)) (defn -main [] (println "Hello, world!")) » compiled with Clojure 1.2.0 (again from Debian sid) takes ~1700 ms. Using -Xbootclasspath takes it down to ~800 ms. -client doesn't do anything obvious. Unpacking the Clojure JAR increases the time.
So presumably there's something about pulling in the Clojure runtime pieces that is very slow, but I have no idea what it is.
There is the nailgun project (http://www.martiansoftware.com/nailgun/) which seems to initialize a JVM in the background so that tasks can execute more quickly, but it's not being maintained.
For Java long start time is because it initializes big amount of RAM at the start, but thanks to this creating objects latter is fast.
Additionally measuring of start of program is meaningless, what this say to us? Nothing. OK, maybe something, something like "write programs/scripts which execution is less than seconds in languages like ....".
But for most of programs it doesn't matter.
What the difference if program starts 3.1-3.2 seconds and 0.05 second? If execution time is longer than minute human will not see difference.
I can understand people decrying results of .05 seconds apart or so, but 3 second start ups? That would be infuriating. That kind of UX would take me back quite a few decades...
Garwk. I've helped write whole operating systems that boot in less time. [Atari ST. Check. Newton OS. Check. Other stuff I can't talk about: tens of milliseconds, mostly waiting for external crap like USB to initialize and settle down.]
If xterm, less, ls, vi and others would take 3 seconds to start, I would never get anything done. I think it's sad that people think that 3 seconds is fast (unless the program is loading some big data of course).
"Suppose you had an automatic tool that optimizes Java code for your target platform before execution. Free of resource constraints inherent to run time optimizers, it processes all the code and optimizes it well.
You feed the application's classes to the tool, which optimizes them for performance and saves the results to disk. Now, you can deploy your Java application in optimized form so that it runs fast from the start on target systems.
...
Using the Excelsior JET Optimizer, you convert the classes into highly optimized x86 code and create a native executable for Windows or Linux. This technique is called Ahead-Of-Time (AOT) compilation. "
I'd like to know what version (and vendor, especially in the case of Java) of each he was running. I've heard time and time again that "Java isn't as slow any more" and maybe that is the case with the "newer" Sun (and Oracle) versions.
However, as one of the later mails[1] says, "such a short program doesn't give the JIT time to warm up"—"Hello world" is a poor comparison to real-world performance.
That depends on what you mean by "real-world performance". The board on which this conversation takes place compares Java to Python, bash and C. Their "real-world" probably consists of a bunch of short-lived small programs on the command line, lots of i/o pipelines etc etc. I think the benchmark gives a meaningful measure of "fit-for-purpose" for that kind of workload.
Comments
Interesting but correlates with the number of files and libraries the interpreter must read or parse. Anything that's quite self-contained is fast; anything that needs to look up and read lots of files is slow.
All I can say is that Java startup time is abysmal. Still, and after fifteen years. Java was dead slow in the 90's and it's dead slow these days when compared to anything else. I love Clojure but Java startup time rules it out for anything else but long-running processes or, when coding, using repl via swank.
I know it's great fun, and fashionable to bash Java, but the Java startup time is slow, because the default settings are optimized for long running processes.
If you want a quicker execution time for a short lived program, just tweak the settings. But then Java may not be the best choice for short lived 'scripting' anyway.
So yes, it rules it out, unless you know what you're doing.
Java is indeed slow to start. So slow, in fact, that Maven created a "Maven Shell" project to avoid re-launching a JVM for each build: http://shell.sonatype.org/
More details: http://ericmiles.wordpress.com/2010/03/23/intro-to-maven-she...
Note that, startup time aside, Java's overall performance is actually quite good, due to the JIT compiler: http://stackoverflow.com/questions/145110/c-performance-vs-j...
The primary disadvantage of Java/.NET compared to C/C++ is the memory overhead. Generational garbage collectors can require up to 5 times as much memory as their explicitly-managed equivalents. [1]
Space overhead doesn't matter for most applications. But it makes Java a no-go for embedded devices and data-intensive domains.
[1] http://lambda-the-ultimate.org/node/2552
I couldn't access the paper itself, but the excerpts are indeed interesting.
Another disadvantage of using a Garbage collector, is that it's hard to predict when the JVM will "freeze" to collect garbage memory. This makes standard Java relatively ill-suited for real-time applications. For these, you need to consider technologies such as http://en.wikipedia.org/wiki/Real_time_Java
The problem with those GC freezes, is that they can be quite long in big memory-intensive applications. This is a reason for the work on alternative parallel GCs. The complexity and relative mysteriousness of the GC makes it hard to tune. Dhanji, a Google Wave engineer, who wrote the "Dependency Injection" book, and is the lead developer of sitebricks, wrote a great article on this subject : http://dhanji.posterous.com/taking-out-the-trash-and-other-c...
All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
"We present a novel experimental methodology that lets us treat unaltered Java programs as if they used explicit memory management. Our system generates exact object reachability information by processing heap traces with the Merlin algorithm [34, 35]. It then re-executes the program, invoking free on objects just before they become unreachable. Since this point is the latest that a programmer could explicitly free objects, our approach conservatively approximates explicit memory management."
Finally, according to the following (2005) article by Brian Goetz, using a garbage collector may yield more opportunities for optimization, at the cost of predictability: http://www.ibm.com/developerworks/java/library/j-jtp09275/in...
You can download the paper from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61....
All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
You're on the right track, but with a twist: Explicit memory management works the opposite way around. Freeing an object when it goes out of scope, like the paper's oracle, is the worst case scenario. A real programmer is free to optimize and release memory before that, even if the object still has references.
In practice, I doubt the difference matters. The primary focus of memory management in C/C++ is avoiding leaks from objects that were never freed and can never be freed because all their references are out-of-scope. Programmers have a small window to free memory, before the pointers are out of scope, but only once the object isn't needed. There's not much room for optimization.
There's RTSJ (or jrts) specifically designed for real-time use. It has an incremental GC that is overall less efficient, but is guaranteed to have bounded wait times.
Interestingly, Java and Clojure have decidedly different startup times on my machine.
A trivial hello-world in Java takes ~130 ms on my Debian sid box with « OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-4) / OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) ». This is with all default runtime options.
The program « (ns hello (:gen-class)) (defn -main [] (println "Hello, world!")) » compiled with Clojure 1.2.0 (again from Debian sid) takes ~1700 ms. Using -Xbootclasspath takes it down to ~800 ms. -client doesn't do anything obvious. Unpacking the Clojure JAR increases the time.
So presumably there's something about pulling in the Clojure runtime pieces that is very slow, but I have no idea what it is.
There is the nailgun project (http://www.martiansoftware.com/nailgun/) which seems to initialize a JVM in the background so that tasks can execute more quickly, but it's not being maintained.
For Java long start time is because it initializes big amount of RAM at the start, but thanks to this creating objects latter is fast. Additionally measuring of start of program is meaningless, what this say to us? Nothing. OK, maybe something, something like "write programs/scripts which execution is less than seconds in languages like ....". But for most of programs it doesn't matter. What the difference if program starts 3.1-3.2 seconds and 0.05 second? If execution time is longer than minute human will not see difference.
I can understand people decrying results of .05 seconds apart or so, but 3 second start ups? That would be infuriating. That kind of UX would take me back quite a few decades...
Garwk. I've helped write whole operating systems that boot in less time. [Atari ST. Check. Newton OS. Check. Other stuff I can't talk about: tens of milliseconds, mostly waiting for external crap like USB to initialize and settle down.]
What przemelek actually suggested is that you won't notice the difference between a 63.1 second run time and a 60.05 second run time.
For Java long start time is because it initializes big amount of RAM at the start.
Why would this take so much time?
He wrote: "[...] it's pretty important when you are writing shell scripts / cron jobs / random commandline utilities.".
I definitely notice the difference in speed between CLI utilities written in C and those in python or ruby.
If xterm, less, ls, vi and others would take 3 seconds to start, I would never get anything done. I think it's sad that people think that 3 seconds is fast (unless the program is loading some big data of course).
"Suppose you had an automatic tool that optimizes Java code for your target platform before execution. Free of resource constraints inherent to run time optimizers, it processes all the code and optimizes it well.
You feed the application's classes to the tool, which optimizes them for performance and saves the results to disk. Now, you can deploy your Java application in optimized form so that it runs fast from the start on target systems.
...
Using the Excelsior JET Optimizer, you convert the classes into highly optimized x86 code and create a native executable for Windows or Linux. This technique is called Ahead-Of-Time (AOT) compilation. "
http://www.excelsior-usa.com/jetinternals.html
I'd like to know what version (and vendor, especially in the case of Java) of each he was running. I've heard time and time again that "Java isn't as slow any more" and maybe that is the case with the "newer" Sun (and Oracle) versions.
However, as one of the later mails[1] says, "such a short program doesn't give the JIT time to warm up"—"Hello world" is a poor comparison to real-world performance.
http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
Java running times can be really good, but the startup times are terrible. See the recently posted Eclipse speed-up article: http://news.ycombinator.com/item?id=2694840 .
> a poor comparison to real-world performance
That depends on what you mean by "real-world performance". The board on which this conversation takes place compares Java to Python, bash and C. Their "real-world" probably consists of a bunch of short-lived small programs on the command line, lots of i/o pipelines etc etc. I think the benchmark gives a meaningful measure of "fit-for-purpose" for that kind of workload.
Anything that's quite self-contained is fast; anything that needs to look up and read lots of files is slow.
Do SSDs magically fix this?
The test was done with a warmed cache, so SSDs would make no difference, the files were read from RAM cache.
They reduce the IO burden, but not to the level to compete.