

Hello World execution time - sheffield
http://lists.nongnu.org/archive/html/chicken-users/2011-03/msg00070.html

======
yason
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.

~~~
przemelek
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.

~~~
burgerbrain
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...

~~~
kabdib
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.]

------
loganlinn
In a reply, he adds Haskell (compiled with ghc)

[http://lists.nongnu.org/archive/html/chicken-
users/2011-03/m...](http://lists.nongnu.org/archive/html/chicken-
users/2011-03/msg00090.html)

------
ronnix
The Python interpreter does an implicit "import site" on initialization.

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

------
burgerbrain
Unless I'm mistaken, the "Bash" benchmark is actually just measuring the
amount of time it takes a C program to read an argument and print, instead of
just a C program printing.

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).

------
retube
I guess java is so slow because you have the initial over-head of starting the
jvm. I'm guessing that subsequent prints of "Hello world" would be somewhat
faster.

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.

------
onedognight
The solution to java's slow startup time is gcj. Once compiled with gcc's java
compiler, a java hello world will have C like startup times.

    
    
        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 ./hello

~~~
drivebyacct2
Uh, if you think gcj is going to beat sun's javac/java, you're mistaken.

Again, 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!

~~~
onedognight
The OP was talking about program startup time and measuring that by comparing
hello world programs. When I run the above hello world program compiled with
gjc is 25% slower that the C program. Compare that with the OP's measured
version being 300 times slower than the C version when compiled with Oracle's
JDK.

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.

------
dexen
With disk caches primed, the main culprit may be the dynamic linker. Some of
those environments (Java, Perl, Python, PHP that others mention in this
thread) always load substantial number of dynamic libraries before doing
anything useful. That doesn't come free. Numberous symbols have to be
resolved, some static data initialized. There's non-trivial VirtualMemory to
set up for such libraries, too.

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
    

...and that's just libc alone! Those times were quite stable across several
runs, so it's not some random one-time fluctuation.

The code:

    
    
      #include <stdio.h>
      
      int main(void) {
            puts("hello world!");
            return 0;
      }

~~~
igouy
[http://shootout.alioth.debian.org/gp4/program.php?test=hello...](http://shootout.alioth.debian.org/gp4/program.php?test=hello&lang=gcc&id=3)

~~~
dexen
[nitpick mode]

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]

~~~
igouy
>>does not use GNU libc nor any other parts of GNU project<<

On the contrary:

\- The program is compiled with GCC

\- "GCC development is a part of the GNU Project..."

~~~
dexen
That you used GCC is irrelevant; other compilers would give pretty much the
same result. GCC is not required by the program by any means. Nothing of GCC
is part of the program itself due to the -nostartfiles flag. The program
doesn't use GCC, you (the software developer) do :-)

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 ;-)

~~~
igouy
>> The program doesn't use GCC... <<

Before your kernel panic out of nitpick mode, shouldn't you at least have
compiled and run that hello world program with ICC? ;-)

------
TheFacelessMan
Ignorance and stupidity is running amok. This kind of trivial benchmark is not
only incredibly dumb but is ACTIVELY HARMFUL to the programming community.
Consider the conclusion drawn by author a few posts down in the thread

"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/u64q/which-programming-languages-
are-fastest.php)

~~~
comex
There is no need for hysteria; it depends on your use case. In the Unix shell,
since every basic operation spawns a process, and performing such operations
only takes a few milliseconds, startup time is extremely important. If it were
written in Java, it would probably not be architected this way, but the
startup time of C makes it acceptable to do so; it is an issue if commands
written in languages like Perl and Python feel slower than the rest of the
system.

~~~
igouy
>>In the Unix shell, since every basic operation spawns a process...<<

That 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".

~~~
comex
"Random commandline utilities" sounds like exactly that; shell scripts use a
lot of Unix commands, I don't know why cron jobs are mentioned.

------
abecedarius
Just tried LuaJIT on a MacBook:

    
    
         4 ms: C, gcc (median real time)
         4 ms: bash
         5 ms: LuaJIT 2.0.0-beta4
        73 ms: Python2.6.1
    

So Bash still wins! I wonder if it gets any special advantage from getting
invoked from itself.

------
afiler
To my great astonishment, Ruby's performance was much closer to bash than
Python in my own test: 0.572sec for 101 runs in Ruby, versus 4.276sec with
Python and 0.318sec with bash. I now feel slightly less bad for all those
shell scripts I've written in Ruby instead of bash.

~~~
afiler
Adding the -S option to python (to skip 'import site') as seen in another post
here brings python's time down to 1.229sec.

------
glenjamin
Is this level of micro-benchmarking actually useful for the given use-case?

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.

~~~
sjs
It depends how often I run the commands. Subversion -> darcs, git, etc. was
like a breath of fresh air. I know that was going out to the network but still
latency can be a killer.

------
melling
Someone want to do a test for Scala? Why can't I have it all?

------
ashishb4u
when will people stop comparing languages based on their runtime speeds?

~~~
esrauch
I'm not really sure if I understand your question. People have runtime speed
demands for their applications and when they start a project they get to
choose a language. Runtime speed is one of several pertinent pieces of
information that is relevant when choosing which language to use.

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.

~~~
ashishb4u
from as little coding experience i have i can say that I have seen blazingly
fast V1.0 of applications which doomed to sluggish responses because of poor
maintenance. So, i really don't buy the speed thing. I'll always design with a
note that "There will be no awesome-coders to maintain this". A well-
maintained version of Java app will beat a struggling C app anyday. So, i
differ. And, ofcourse if you know what you are doing, these graphs do make
sense and its worth an effort to dig out the flipping bits on registers.

~~~
burgerbrain
_"A well-maintained version of Java app will beat a struggling C app anyday."_

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.

~~~
fleitz
And luckily the crappy java programmers will never even get a C program of any
complexity to start up.

------
gubatron
that has got to be the most useful language benchmark of all times... for
those that don't go past the "Hello World" step that is.

------
dkd903
What about PHP? Will it have same results as C?

~~~
tedunangst
Somewhere around perl or python likely.

~~~
burgerbrain
On my machine perl is .008, python is .036, and PHP is .044.

So it looks like PHP is a good deal slower than python, and certainly perl. 22
times slower than C..

