Grex Agorage Conference

View Responses

Grex Agorage Item 16: Compiler comparison
Entered by papa on Mon Jun 5 23:12:15 UTC 2017:

Grex Compiler Comparison

Executable size and sample time results for "99 Bottles of Beer" programs.

Source: https://rosettacode.org/wiki/99_Bottles_of_Beer

| Language (compiler)  | Exe. size | Real (s) | User (s) | Sys (s) |
|----------------------+-----------+----------+----------+---------|
| C (gcc)              |     10384 |    0.012 |    0.010 |     0.0 |
| Fortran (gfortran)   |     11016 |    0.016 |      0.0 |   0.010 |
| OCaml (ocamlc)       |    126776 |    0.020 |      0.0 |   0.020 |
| Pascal (fpc)         |    155704 |    0.008 |      0.0 |   0.010 |
| Rust (rustc)         |    312042 |    0.017 |      0.0 |   0.020 |
| Go (go)              |   1272632 |    0.013 |      0.0 |   0.010 |
| Haskell (ghc)        |   1971753 |    0.025 |    0.010 |   0.010 |
| Common Lisp (clisp)* |      1487 |    0.071 |    0.020 |   0.050 |
| Java (javac)*        |      1118 |    0.247 |    0.090 |   0.130 |
|----------------------+-----------+----------+----------+---------|
* Compiler does not produce binary executable file.

6 responses total.

#1 of 6 by papa on Mon Jun 5 23:16:22 2017:

I'm not an expert in any of the listed languages. I just copied the sources
from Rosetta Code.

Interesting that all the languages except Common Lisp and Java are in the same
ballpark for performance, but there is a big spread for executable size, from
tiny C and Fortran to gargantuan Go and Haskell.

#2 of 6 by papa on Mon Jun 5 23:20:00 2017:

... Though I suppose the simple nature of the program may give an advantage
to the older languages (C, Fortran, Pascal) since it doesn't call on the
shiny new features of the newer languages.

#3 of 6 by cross on Tue Jun 6 00:08:50 2017:

Note: for common Lisp, I'd look at sbcl before clisp.

Executable size is, to be blunt, not a good metric for anything. In
particular, languages like Haskell and Go have big runtimes that get linked
into the binaries (also, linked mostly statically). But most of that is simply
never used; who cares if the executable file has a meg of string data in it
if it never gets paged in off the disk? Disk is cheap; the days of dynamic
linkers being useful to *save disk space* are long gone in all but a handful
of applications.

The Java and maybe Lisp programs are surely slower in no small part due to
image startup costs; amortizing for those can be challenging.

See also here:
http://web.archive.org/web/20110815233846/http://www.bobhancock.org:80/2011
/02/performance-of-cpython-pypy-java-and-go.html#comments

#4 of 6 by papa on Tue Jun 6 01:15:59 2017:

I agree with cross's point on executable size when working on a current OS
like Grex's. But it is relevant on retro systems like pre-VAX DEC and other
mainframes of the same era, early DOS, etc. Of course, for retro-computing
languages like Go and Haskell are off the menu.

#5 of 6 by papa on Tue Jun 6 01:21:03 2017:

... Well, maybe not 100% agree on executable size, but would say it is a low
priority on current systems. It still bugs me a little to have a fat
executable when the linked stuff isn't required by my simple source.

#6 of 6 by cross on Tue Jun 6 11:56:43 2017:

Another factor in binary size is whether one is statically linking or not.
Without explicitly doing so, often one is not; I'd suggest statically linking
all binaries to get a more accurate comparison of sizes.

But again, I *really* don't think that matters.

Response not possible - You must register and login before posting.