4 ms·

>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

>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 ago
  I 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 ago
    That'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 ago
      It 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 ago
        The 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.
        lobster_johnson 10y ago
        Again, it's not evidence. There's zero documentation about how the benchmark was done. Was it repeated? Is the timing "best of N", or a percentile? Was there warmup? And so on. The compile times are only shown in the Nim board comment, not the Github page, which doesn't benchmark compilation times. Again, where did the numbers come from? Secondly, again, it was for a ~70-line program. Do you seriously think that benchmarking the compilation of a 70-line program is statistically valuable? It's ridiculous. You completely missed the point of my JVM comment. Actually, I'm going to assume you're trolling. I'll stop here.

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 ago
I 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 ago
  That'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 ago
    It 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 ago
      The 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.
        lobster_johnson 10y ago
        Again, it's not evidence. There's zero documentation about how the benchmark was done. Was it repeated? Is the timing "best of N", or a percentile? Was there warmup? And so on. The compile times are only shown in the Nim board comment, not the Github page, which doesn't benchmark compilation times. Again, where did the numbers come from? Secondly, again, it was for a ~70-line program. Do you seriously think that benchmarking the compilation of a 70-line program is statistically valuable? It's ridiculous. You completely missed the point of my JVM comment. Actually, I'm going to assume you're trolling. I'll stop here.