> Why is he discarding compsci literally in the introduction? Does he really think "big O" is all there is, presumably because those ivory tower compsci people have no clue about computers?

Hi! I'm the author. I do have an ivory tower compsci degree. I'm poking fun at myself as much as anyone else.

> There are some good bits of advice in the article, too, though.

Thanks! "Everything Sysadmin" is my 3x/yearly column in ACM Queue. My goal is to bring a bit of operational reality to an organization with a reputation for being ivory tower. Click on the phrase "everything sysadmin" to see the other columns I've written.

> So, when you are using C/C++, "small" for this problem is a billion elements.

I know, right? "Small" has gotten so big that we have to re-think our gut reactions and recalibrate our back-of-the-envelope estimations. Just imagine how big small will be for the next generation of developers?

I just want to say that I really enjoyed this article. I was surprised to see all the negativity here on HN about it! Thank you for writing it, as it really got me thinking. I've done some of these things before, but it's easy to lose the forest for the trees when you're deep down in the middle of solving some problem.

Moore's law is dead. Small won't change nearly as fast as it used to.

>Just imagine how big small will be for the next generation of developers?

about the same, since moores law is dead for cpus, and ram doesnt seem to be getting much faster either

Wait, are you saying that C is 50 times faster than Go? I find that very hard to believe. I could buy 3-4 times faster, especially if the C code is vectorized and the Go code is not, but 50-100x seems unrealistic IMO. Do you have any benchmarks to back up your claim?

https://ideone.com/T56tDZ I get close to 5 GB/s with this online IDE and twice that on my 6 year old laptop, which is roughly a factor of 20 to 40 faster than 250 MB/s. A factor of 100 sounds plausible with more modern RAM or larger cache size.

You only benchmarked the C code. In order to get an apples to apples comparison, you have to benchmark the Go code on the same hardware - your comment compares the runtimes of two different implementations on different hardware.

> Wait, are you saying that C is 50 times faster than Go?

Are you saying you need 50 clock cycles to compare two integers?

...no? What made you think that?

Its hard to believe because its dead wrong. See my benchmark above.

Yeah what OP wrote is complete nonsense. Sad that this stuff bubbles to the front of HN and then gets quoted endlessly...

Go is not nearly as slow as you're making it seem to be, I dont know what the authors implementation was doing, but this code runs at a rate of 7GiB/s/core on my laptop

  func BenchmarkFindMax(b *testing.B) {
   ints := make([]int32, 13*1000*100)
   for i := 0; i < len(ints); i++ {
    ints[i] = rand.Int31()
   }

    for i := 0; i < b.N; i++ {
      max := int32(math.MinInt32)
      for _, x := range ints {
        if x > max {
          max = x
        }
      }
      dontOptimize = max
   }

   b.ReportMetric(float64(b.N*len(ints)*4/1000/1000/1000), 
  "GiB/s")
  }


  goos: darwin
  goarch: amd64
  BenchmarkFindMax-8  1530   678975 ns/op   7.00 GiB/s

EDIT: Actually my original code was reporting the metric wrong, it should have been:

b.ReportMetric(float64(b.N)float64(len(ints))4/1000/1000/1000, "GiB/s")

which leads to 9-10GiB/s on my laptop

The author was running on a 2013 laptop, which had smaller cache and slower RAM than what you're probably using.

Benchmark comparisons are useless without running on equivalent hardware.

He was probably scanning elements that were larger than int32s, even on a 2013 this code would run at Gib/s.

The point of my benchmark was that C is nowhere near 50-100x faster than Go and that the user I'm replying to shouldn't make unsubstantiated claims like that.

My claim that the trivial C code is 100x faster than the number from the article is a) well substantiated b) all there is c) perfectly clear.

> Go is not nearly as slow as you're making it seem to be

It's rather obvious I compared against the quoted figure.

Not just that, in a language with reasonable abstractions it is max(elems), maybe in some external module. His arguments about simpler / less buggy code don't apply.

Someone has to write the algorithm beneath those abstractions. It's not magic. There's a point in the abstraction call stack where the programmer needed to understand how a CPU actually works.

Same applies for his sort example. Someone has to write sort. Except that now also includes sorting.

In a language with lazy stream abstraction, the max() function can be pretty efficient.