5 ms·
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 ha
by formerly_proven 6y ago
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?
There are some good bits of advice in the article, too, though.
> I conducted some simple benchmarks in Go to find how much data can be processed in 200 ms. A linear search can scan 13 million elements in less than 200 ms on a three-year-old MacBook laptop, and 13 million is no small feat.
It's funny how slow languages have shifted perceptions. Scanning 13 million elements to find the biggest element among 32 bit ints in 200 ms is slow. That's 250 MB/s, or about 50 clock cycles per element. Even the most naive and portable C three-liner is almost 100x faster (there is a difference in single-threaded performance, if you assume a very generous 50 % difference, it'd still be 50x faster).
maximum = INT_MIN;
for(int i = 0; i < N; i++)
maximum = elems[i] > maximum ? elems[i] : maximum;
So, when you are using C/C++, "small" for this problem is a billion elements.
Computers are super-fast. Next time you wait two seconds for some application to compute something, ask yourself: is this problem really eight-billion clock cycles hard?
- higerordermap 6y agoNot 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.
- secondcoming 6y agoSomeone 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.
- higerordermap 6y agoSame 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.
- YesThatTom2 6y ago> 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?
- mark-r 6y agoMoore's law is dead. Small won't change nearly as fast as it used to.
- thewebcount 6y agoI 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.
- voldacar 6y ago>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
- gautamcgoel 6y agoWait, 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?
- johndough 6y agohttps://ideone.com/T56tDZ 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.
- gautamcgoel 6y agoYou 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.
- formerly_proven 6y ago> Wait, are you saying that C is 50 times faster than Go? Are you saying you need 50 clock cycles to compare two integers?
- gautamcgoel 6y ago...no? What made you think that?
- richieartoul 6y agoIts hard to believe because its dead wrong. See my benchmark above.
- gautamcgoel 6y agoYeah what OP wrote is complete nonsense. Sad that this stuff bubbles to the front of HN and then gets quoted endlessly...
- richieartoul 6y agoGo 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
- Jtsummers 6y agoThe 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.
- richieartoul 6y agoHe 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.
- formerly_proven 6y agoMy 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.
- formerly_proven 6y ago> Go is not nearly as slow as you're making it seem to be It's rather obvious I compared against the quoted figure.