5 ms·

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

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.

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.