Hello World execution time
lists.nongnu.org
lists.nongnu.org
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.
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.
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...
Space overhead doesn't matter for most applications. But it makes Java a no-go for embedded devices and data-intensive domains.
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...
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.
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.
Why would this take so much time?
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. "
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...
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.
Do SSDs magically fix this?
http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
You can disable it using the -S option if/when you care about startup time.
Here are some numbers on my MacBook Pro:
$ ./run.sh bash hello.sh
median 0.002
$ ./run.sh python hello.py
median 0.016
$ ./run.sh python -S hello.py
median 0.008
Assuming the bash program was: `echo "hello, world!"`
Edit: I likely am mistaken. Chances are this was done using the builtin 'echo', not '/bin/echo'. The builtin is always faster (though putting them in a file (as is the only fair way to do it) slows them both down of course).
This article is basically trolling java, and it seems a number of people have taken the bait. Different languages have different strengths and weaknesses. You'll choose the one most appropriate to the task required. If that's printing "Hello World" to the console then fine, but I doubt many people would think "java" when presented with this requirement.
echo 'class Hello {public static void main(String[] args) {System.out.println("hello, world");}}' > Hello.java
gcj --main=Hello -o Hello Hello.java
time ./Hello
echo 'main() { printf("hello world\n");}' | gcc -x c -o hello -
time ./helloAgain, with the rapid unexplained downvotes... seriously, did you see the article about speeding up Eclipse? The suggestion was to make sure you're not using gcj and others commented that they agree'd. It's well known the gcj is just flat slow compared to Oracle's/OpenJDK.
lol, whatever guys, pile on, I must be missing the joke!
Eclipse is not representative of a typical command line program. Write "ls" with the OpenJDK and tell me you don't pull you hair out waiting for it to start up when using it.
But I can see how compiling a simple program with gcj could make it faster.
For some more info: http://harmful.cat-v.org/software/dynamic-linking/
EDIT: a micro-benchmark between static and dynamic C program:
gcc -- static a.c
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m0.958s
####
gcc a.c # that's dynamic linking
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m1.292s
The code:
#include <stdio.h>
int main(void) {
puts("hello world!");
return 0;
}What a misleading example. That's not GNU hello world, that's Linux hello world. The difference: it does not use GNU libc nor any other parts of GNU project -- except for the `unistd.h' -- but instead interfaces with the kernel directly.
Another matter is that it's not a C program, as it doesn't have int main(...) :P
[/nitpick mode]
On the contrary:
- The program is compiled with GCC
- "GCC development is a part of the GNU Project..."
For sake of example, consider Linux (the kernel); usually compiled with GCC -- but ICC works as well -- and distributed under GPL, yet is not part of GNU project.
Moreover, the program in question can be ran directly on bare Linux, with no GNU stuff present anywhere, if passed via `init=PATH_TO_THE_PROGRAM' boot param. Of course the kernel would panic right after the syscall(__NR_exit, 0)... so I'm bailing out of nitpick mode right now ;-)
Before your kernel panic out of nitpick mode, shouldn't you at least have compiled and run that hello world program with ICC? ;-)
Hm... huh?
"Astonishing indeed. The whole thing confirmed my hunch that Bash, Chicken, and C provide a complete toolset to tackle 99.9% of programming needs."
No no no! Try running anything non-trival in bash or python and compare that to the java. Obviously if all you ever want to do with programming is write little boring scripts then you shouldn't be using a language like java in the first place. For anything mildly interesting and performance intensive Java is pretty much a no brainer only behind c/c++ amongst the major languages. For a site with REAL benchmarks which actually mean anything unlike the language fanboyism in this posted article checkout http://shootout.alioth.debian.org/u64q/which-programming-lan...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=hel...
But "if all you ever want to do with programming is write little boring scripts" it might help to understand that 9 hundredths of a second delay is below the threshold that someone using the boring little script will notice.
And "if all you ever want to do with programming is write little boring scripts" simply using Java as an interpreter with -Xint might be faster.
For example, that old benchmarks game n=200 "hello world"
Java 6 -Xint 15.429s
Java 6 -client 16.929s
Java 6 -server 17.073s
Java 1.4 -server 35.738sThat does not seem to be the use case that's being examined.
The use case that's being examined is - "writing shell scripts / cron jobs / random commandline utilities".
4 ms: C, gcc (median real time)
4 ms: bash
5 ms: LuaJIT 2.0.0-beta4
73 ms: Python2.6.1
When "writing shell scripts / cron jobs / random commandline utilities" I believe my priorities are
1) Does it work? 2) How easy is this to write? 3) How easy is this to read?
In that order.
Not that this benchmark is actually indicating anything about which language to use in any of those circumstances (Java has a bad startup but pretty good during runtime, and startup time on these orders is generally irrelevant for any nontrivial application), but that isn't to say that language benchmarks in general are irrelevant.
And a poorly maintained C program will outperform an equally poorly maintained Java program...
The things that make programs dramatically slower is poor algorithmic complexity (and often a poor understanding of the architecture, be it the JVM or the metal). That's not what we're talking about here though, this discussion is pretty explicitly about start-up times. We're talking constant-time issues.
So it looks like PHP is a good deal slower than python, and certainly perl. 22 times slower than C..