language-implementation startup times
language-implementation startup times
Posted Dec 4, 2014 5:43 UTC (Thu) by idupree (guest, #71169)Parent article: Kawa — fast scripting on the Java platform
The following languages compile+run Hello World in under 0.1 second for me: Guile Scheme, Common Lisp (sbcl, clisp), Python, Bash, Perl, Ruby, JavaScript, PHP, Lua, OCaml, C (GCC and Clang; for C but not C++), and – almost – Go and Ada.
Other language implementations I tested come in somewhere above 0.2 second to compile+run Hello World: C++ (g++, clang++), D (dmd or gdc), Java (OpenJDK), Rust, SML (mlton), Haskell (GHC), Clojure. I love some of these languages. The compile/startup time is a downside.
How limiting do you find the JVM dependency to be for startup time? A precompiled Java Hello World runs in about 0.06 seconds for me – could be better, could be worse, and I recognize that benchmarking Hello World is not representative of real code.
[1] tests run on CPU i7-2630QM, DDR3-1600 RAM, SSD disk, Arch Linux x86_64
Posted Dec 4, 2014 8:33 UTC (Thu)
by Per_Bothner (subscriber, #7375)
[Link] (3 responses)
I find it difficult to understand why you care whether it takes 0.1 seconds or 0.3 seconds, or why 0.06 elicits a "could be better, could be worse". If you're a human starting up an application, half a second or less seems plenty fast enough. It's an issue if you write a shell script that calls lots of little applications each of which take more than half a second, but in that case you'd merge these little applications into a bigger program. Bringing up a complex GUI is a different matter, or course.
OTOH if you're making a request to a server, you really don't want that to take half a second plus networking time, but in those situations you'd have a server already running.
In a previous life, I was the technical lead for the GCJ project, and in the past Kawa could be built and run on GCJ. We also supported compiling Scheme programs to native (going via Java bytecode). Even that wasn't immune to startup delays - for example you had shared library relocation. I've removed support for using GCJ because GCJ is no longer being actively maintained, and does not support newer Java features which I found useful for Kawa. (There is a fair amount of conditional code in Kawa that can be pre-processed for different Java platforms. Not that long ago I had conditional code to support as far back as JDK 1.1. However, I now require Java 5 or newer, to avoid cluttering up the source with code that never gets tested ...)
Posted Dec 4, 2014 10:54 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (1 responses)
One reason may be that when you extrapolate to slower systems, 0.1 seconds on an i7 could be the difference between acceptable and unbearable. I just ran your test on the Raspberry Pi I'm currently developing for:
Posted Dec 4, 2014 15:42 UTC (Thu)
by Per_Bothner (subscriber, #7375)
[Link]
Point taken. On a slower system you might to use a different JVM, or perhaps a more limited version of Java, such as one that implements Java ME (rather than Java SE). These are designed for hardware that is slower or has less memory.
Specifically Android, which is sufficiently Java-like that I ported Java to it a few years ago. Android is of course designed for more resource-restricted environments than traditional Java (though these days a smart-phone is pretty powerful). The main limitation of Kawa for Android is that it currently doesn't support eval - everything has to be pre-compiled. This is because Android doesn't run Java bytecodes directly - Java
I haven't experimented with Kawa on "micro" systems except for Android. However, if Kawa depends on some Java language or library feature that is not available on your platform of interest, I will happily work with you to avoid the dependency. The Kawa conditional-compilation framework (see the
Posted Dec 28, 2014 8:00 UTC (Sun)
by pcarrier (guest, #65446)
[Link]
I might run it again now that I have a Linux laptop running Arch Linux natively again.
I might try to add Kawa, but given the terrible timing of the JVM for a single Java class, I don't think it'll fare all that well. Could get interesting results with Avian or jamvm though (alternative runtimes for JVM class files).
For what it's worth Clojure and JRuby were kept out as significantly slower than everything else.
Posted Dec 4, 2014 12:44 UTC (Thu)
by cortana (subscriber, #24596)
[Link]
On my i7-4700MQ laptop running:
language-implementation startup times
$ bin/time kawa -e '(format #t "hello~%")'
reports:
0.36user 0.02system 0:00.23elapsed 164%CPU (0avgtext+0avgdata 41304maxresident)
> I find it difficult to understand why you care whether it takes 0.1 seconds or 0.3 seconds, or why 0.06 elicits a "could be better, could be worse".
language-implementation startup times
time java -jar kawa-2.0.jar -e '(format #t "hello~%")'
hello
real 0m7.720s
user 0m7.260s
sys 0m0.430s
That's almost 8 seconds, just to print "hello". For comparison:
time (gcc -o hello hello.c && ./hello)
hello
real 0m1.967s
user 0m0.520s
sys 0m0.040s
And after that:
time ./hello
hello
real 0m0.009s
user 0m0.000s
sys 0m0.000s
But also:
time (javac Hello.java && java Hello)
hello
real 0m13.716s
user 0m12.750s
sys 0m0.860s
And then:
time java Hello
hello
real 0m1.618s
user 0m1.460s
sys 0m0.150s
While the relation is not linear, Idupree's tests give me a hint of how usable would be Kawa for my project.
One reason may be that when you extrapolate to slower systems, 0.1 seconds on an i7 could be the difference between acceptable and unbearable.
language-implementation startup times
.class files have to be translated to Dalvik ahead-of-time. It looks like it should be possible to fix this, either being by using a library to do the translation on the device, or to modify Kawa to generate Dalvik bytecode directly. However, I haven't looked into this.
PreProcess class) is very useful for this.
language-implementation startup times
language-implementation startup times