4 ms·
How is the compiler for such a simplistic language so slow? The optimizing ocaml compiler is 5-10x faster, and is compiling a much more advanced language, comp
by MustardTiger 10y ago
How is the compiler for such a simplistic language so slow? The optimizing ocaml compiler is 5-10x faster, and is compiling a much more advanced language, complete with features developed in the 1970s even.
- lobster_johnson 10y agoI don't doubt that OCaml is faster — but how do you know this to be true? Are there benchmarks comparing equivalent programs in Go and OCaml? In this particular case, the discussion is about a program that imports around 500 package dependencies and is compiling everything (as I understand it) from scratch, resulting in a binary that is around 90MB.
- MustardTiger 10y ago>Are there benchmarks comparing equivalent programs in Go and OCaml? Yes. Go was nearly as bad as java and C++ in 2014, and it has gotten nearly twice as slow since then. And yet "compiler performance" is the excuse for not having generics. While C++ and java both have them and are now faster than go's compiler, and ocaml is way faster and has them. http://forum.nim-lang.org/t/682 http://forum.nim-lang.org/t/682
- lobster_johnson 10y ago> Yes. Please do provide them. The notion that Go's compiler is slower than C++ is ridiculous. Go's compiler, despite the recent slowdown, is still famously fast, whereas C++'s notorious header file problem means that even small changes can trigger huge recompiles (which is exacerbated by the fact that templates must often have their implementation code in the header file, not the implementation file). Meanwhile, Rust's compiler is much, much slower than Go's, and probably not much faster than GCC/Clang with C++.
- MustardTiger 10y agoI just linked to one in the post you replied to. And it shows clearly that 2014 go is almost as bad as C++ and java.
- lobster_johnson 10y agoThat's a runtime benchmark, not a compile-time one. Sure, the Nim post includes compile times, but no information about benchmarking methodology; warm caches? How many runs? Percentiles? etc. Also, the program being tested is just a few dozen lines (75 in Go, 73 in C++). Not exactly exercising compilation speed here.
- MustardTiger 10y agoIt is both, hence both numbers being listed. "I don't like that evidence" is not an argument. You asked if I had evidence, I provided it. If you still want to believe go is not slow, then you provide evidence.
- lobster_johnson 10y agoThe link you provided is not evidence, just an anecdote. It's not that I don't "like it"; it's absolutely not an indicator of anything real. At best it's an indication that all compilers have some startup overhead, some more or less than others. Based on JVM startup time alone, I could "prove" that Java was the slowest language in the world. The burden is on you to provide evidence, since it is your claim. Likewise, benchmarks to support the claim that OCaml's compiler is faster. I develop in Go daily, and nothing I've seen indicates that Go is anywhere close to approaching C++ in compilation slowness. (I have also worked extensively with C++.)
- MustardTiger 10y ago>The link you provided is not evidence, just an anecdote No it is not. A reproducible test is evidence, not anecdote. >At best it's an indication that all compilers have some startup overhead, some more or less than others. Based on JVM startup time alone, I could "prove" that Java was the slowest language in the world. That seems unlikely since we just saw otherwise. >The burden is on you to provide evidence, since it is your claim And I did. Dismissing it because it does not fit your preconceptions does not mean I need to continue supplying more and more evidence for you to dismiss without any justification. >I develop in Go daily, and nothing I've seen indicates that Go is anywhere close to approaching C++ in compilation slowness. (I have also worked extensively with C++.) Now that is an anecdote.