4 ms·

As much as I dislike that most of the "language shootout" benchmarks are mostly numeric wanking, the binary tree benchmark actually makes, uses and disposes of

• melling 12y ago
  Rust looks great but hasn't shipped yet. Go is production quality and it's being used in some large projects at Google and elsewhere. http://blog.golang.org/4years http://blog.golang.org/4years - From Nov 2013 No, the Go optimizing isn't great. This will be addressed after the compiler is completely rewritten from C to Go. The Go community is growing too, which is probably more important than how well you do on a micro benchmark.
  • cromwellian 12y ago
    I don't understand how writing the Go compiler from scratch in Go is going to make it better than super-mature compilers. Wouldn't it better to leverage Clang/LLVM? Redoing all the optimizations by rewriting the whole compiler in Go seems like it will significantly delay performance parity.
    • chadzawistowski 12y ago
      I don't think being written in Go will make the compiler produce intrinsically fast code. Rather, it will be easier for them to iterate. It is much faster to develop in Go than in C.
    • melling 12y ago
      They haven't written the optimizing compiler yet. They are waiting.
      • masklinn 12y ago
        Wouldn't an optimising compiler run contrary to go's goal of fast compilation?
        • melling 12y ago
          Unless they had a flag... I would think so.
        • orbifold 12y ago
          They could use the same front end and enable optimisation passes in the backend with compile flags / heuristics. GHC for example uses for certain flow optimisations "fuel" once it runs out it stops doing further optimisations. For long running applications, ideally the runtime would profile the application during its execution and JIT / optimise based on the live state of the application. The JVM demonstrates that this can have major benefits over AOT compilation.
        • MetaCosm 12y ago
          No, going fast is about not doing work twice. It is about the dependency graph. Go was developed to make dependency analysis very simple, so you recompile a tiny number of files even on massive, complex apps... and don't spend massive amounts of time deciding what to compile, or building stuff up just to tear it down (include all the things, use macros to exclude, etc).
    • riwsky 12y ago
      For what it's worth, the go team's plan is to automatically translate the compiler to go, not to rewrite it from scratch: http://talks.golang.org/2014/c2go.slide#18 http://talks.golang.org/2014/c2go.slide#18 And, the gccgo compiler does leverage gcc, assuming that counts as a mature compiler: http://blog.golang.org/gccgo-in-gcc-471 http://blog.golang.org/gccgo-in-gcc-471 . Neither of these contradict your implicit point of "they chose to invest time in this port instead of trying to maximize performance ASAP", but you still might want to know.
      • cromwellian 12y ago
        Seems weird to fork a compiler like gcc or clang via transpilation, because you split the community. It may be faster to iterate on Go, but will all of the compiler contributors on GCC or Clang/LLVM want to switch to editing the go version? It seems you'd lose out on picking up improvements from the main compiler branch and have to keep transpiling and gardening in patches. Plus upstreaming improvements would also be irritating. I'd think a Go frontend to LLVM would be optimal in terms of productivity.
        • e12e 12y ago
          The go compiler is based on the plan9 c compiler, not gcc. I'm not quite sure what the story is with gccgo (who initiated it, why) - but i think it was for interfacing with c on non-plan9 architectures, and not really about leveraging gcc optimizations.
          • astrange 12y ago
            gccgo was written by a gcc developer for the purpose of trying out new ways to write a frontend, but also to use all the various things gcc has. https://blog.golang.org/gccgo-in-gcc-471 https://blog.golang.org/gccgo-in-gcc-471 The Go developers have claimed LLVM was not useful because it's too slow, which is why they used the plan9 compiler style.
        • MetaCosm 12y ago
          Go is a spec, not a compiler.
    • shanemhansen 12y ago
      Go can already leverage some of gcc's optimizations. There's also https://github.com/go-llvm/llgo https://github.com/go-llvm/llgo
• gillianseed 12y ago
  Why only compare based upon one of the benchmarks (binary-trees), and also why choose 32-bit which the most unlikely architecture this would run on as I see it ? Here's java compared to go on all benchmarks, 64-bit: quad-core: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... single-core: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... Gives a much better overview than a single test running under 32-bit .
  • Roboprog 12y ago
    I picked the 32 bit version of the benchmarks, since the demo program didn't need multiple GB worth of memory, FWIW. I thought that single vs multi-core was comparable on either 32 or 64 bit. Otherwise, I thought I was pretty clear why I picked binary tree over, say, mandelbrot set. Wanted to favor "data structure" usage over number crunching.
    • gillianseed 12y ago
      >I picked the 32 bit version of the benchmarks, since the demo program didn't need multiple GB worth of memory, FWIW. More addressable memory is but one advantage of 64-bit versus 32-bit, the fact that it has double the amount of registers is another VERY important performance aspect since registers are by far the fastest place to store and retrieve data from, so less need to push values from registers on to stack / flushing cache lines, means faster running code, and in hot loops the difference in performance can be huge. >Otherwise, I thought I was pretty clear why I picked binary tree over, say, mandelbrot set. But why not show ALL the results and just highlight binary trees, there are a lot more benchmarks there than mandelbrot, also I don't see what is wrong with 'number crunching' benchmarks ?
      • Roboprog 12y ago
        Good point about the registers. Most business apps don't do much number crunching or bit-twiddling. Think of moving strings/records/objects to and from a data store, putting them temporarily in an in-memory hierarchy or an indexed cache for lookup/evaluation, then pumping more strings to a browser / the console / a dialog box. I didn't pick the binary tree example to pick on Go, it's my "best match use case" for the "allocate and find things" that I envision goes on in most applications, regardless of which languages I am comparing.
• placeybordeaux 12y ago
  Rust still isn't 1.0. In fact to even use basic syntax such as selecting a range of a slice you need to specify that you are using not yet supported features. I love the concept of rust, but trying to write a trivial program in it was a pain in the ass.
  • Roboprog 12y ago
    Thanks for the tip. Everything I read about Rust sounds really good, BUT, I've yet to download it and write Hello World, so not sure how painful it is in practice.
    • keeperofdakeys 12y ago
      It's not painful, the problem is that the code you write now might change in a month. With the release of 1.0 (which is less than six months IIRC), they will stabilize the syntax (but will be adding more down the line). But the libraries will still be very much in flux. The reason things have been changing so much is mainly to get a better language now, and not have to write a 2.0 that changes everything. When you look at rust code from six months ago, things have improved greatly, so it will hopefully be worth it.