|
|
| Author |
Message |
papa
|
|
Compiler comparison
| 
Jun 5 23:12 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. |
papa
|
|
response 1 of 6:
|
Jun 5 23:16 UTC 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.
|
papa
|
|
response 2 of 6:
|
Jun 5 23:20 UTC 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.
|
cross
|
|
response 3 of 6:
|
Jun 6 00:08 UTC 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
|
papa
|
|
response 4 of 6:
|
Jun 6 01:15 UTC 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.
|
papa
|
|
response 5 of 6:
|
Jun 6 01:21 UTC 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.
|
cross
|
|
response 6 of 6:
|
Jun 6 11:56 UTC 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.
|