Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Beating C with 70 lines of Go

ajeetdsouza.github.io

Post reply on HN
Print view View original

41–50 of 106 posts

Re: Beating C with 70 lines of Go

#42

Post by weberc2 »

timClicks wrote: post #20

I'm really surprised by how much memory this task needs. Using a 16KB buffer and incrementing an integer needs multiple MB. I guess that's the size of the executable after it's been loaded into RAM that's so large?

Yeah, if that figure includes the executable, then it's also probably including the whole runtime (scheduler, GC, etc) since Go programs statically link the runtime by default. In that case, 2MB isn't so bad (especially considering glibc is ~10MB [and with no scheduler or GC!] iirc).

Re: Beating C with 70 lines of Go

#43

Post by weberc2 »

microtonal wrote: post #28
microtonal wrote: post #7

Another article in the series beating C by moving the goal posts . My comment on the original article about the Haskell version on lobste.rs: Keep in mind in all comparisons to GNU wc that it does extra work, detecting multi-byte characters and decoding multi-byte characters if present, to correctly count the number of words. perf shows a significant amount of time being spent in multibyte character handling. If you…

For the people down voting, please read the source code of GNU and Apple wc before down voting.

https://en.wikipedia.org/wiki/Hitchens%27s_razor

Re: Beating C with 70 lines of Go

#44

Post by Gibbon1 »

aikah wrote: post #34
big_chungus wrote: post #9

> I hope it demonstrates that Go can be a viable alternative to C as a systems programming language. Are you kidding me? This is nothing close to a systems programming language. This isn't much of a comparison at all. wc is a very simple case that doesn't match the complexity of real-world programs. Go comes close here because you're not using the high-level abstractions and that make it useful in the real world. GNU…

Furthermore this isn't "system programming", he just replaced a "user land" program with another. But I blame the Go team for turning "system programming" and "realtime programming" into useless buzzwords to promote their language.

Yeah when I first looked at go that was the first 'no fu' for me. Go isn't a systems or real time programming language. It's a managed language with training wheels. Which is okay by me. Lying about it though is not okay.

The second FU is they claim that decisions they made based on personal preferences were technical ones. That's a very insidious lie that programmers make all the time. Insidious because it destroys trust between programmers and managers.

Re: Beating C with 70 lines of Go

#45

Post by weberc2 »

0xdead wrote: post #25

> Go can be a viable alternative to C as a systems programming language Stop this nonsense please. This does not show anything even remotely close to systems programming capability of Go. Write a device driver in Go that performs without lagging, benchmark it and then come back.

"systems programming" is not well defined. While you and I probably prefer a similar definition, comments that criticize TFA for not using our preferred definition are really boring. Let's just say that Go is a fine language for `wc` (and not a very good language for device drivers) and move on.

Re: Beating C with 70 lines of Go

#47

Post by grumpydba »

0xdead wrote: post #25

> Go can be a viable alternative to C as a systems programming language Stop this nonsense please. This does not show anything even remotely close to systems programming capability of Go. Write a device driver in Go that performs without lagging, benchmark it and then come back.

https://news.ycombinator.com/item?id=18399389.

It's been done. Performs well.

Re: Beating C with 70 lines of Go

#48

Post by tuckerpo »

Yeah, let me just multithread and hand-optimize the piss out of this Go program until it's marginally faster than it would have been in C.

Reminds me of the argument that venison tastes better than beef. The argument roughly being, "If you shoot the deer right, drag it home right, gut it right, skin it right, tenderize it right and cook it _just_ right, it'll be _almost_ as good as store-bought frozen beef"

Re: Beating C with 70 lines of Go

#49

Post by esmi »

ajeetdsouza wrote: post #30
esmi wrote: post #6

wc seems like a bad example because it’s basically IO bound. The title should read, “Go’s built in bufio reader is faster than raw reads on the file descriptor.” Which it should be because that’s the point of bufio.

Author here. I have addressed this in the article. The bufio-based implementation was the first one, and it was actually slower. In the second section, I was able to surpass the performance of the C implementation - by using a read call with a buffer. As I mentioned in the article, the C implementation does the same, and in the interest of a fair benchmark, I set equal buffer sizes for both.

I don't know Go so I am not sure what file.Read does exactly but wc, on my system which uses the same wc.c as Jenner's article, is doing blocking reads in a naive way which I argue makes it somewhat of a paper target.

Maybe the Linux wc version you have is better. I don't know. They do exist and Penner's article gave a link to one. I am not sure as you didn't link to the source of your wc. (Edit: I just noticed you did use the OSX wc, you're just running it on Fedora. Sorry about that.)

But in any case using just wall clock time can be deceptive. Here is what I mean. On my machine, a somewhat old Mac Mini with a spinning disk, user CPU is only ~1/5 of the real time. The rest waiting for the OS or the disk.

  % for ((i=0;i> a; done
  % /usr/bin/time wc -l a                                         
   58971500 a
          1.24 real         0.28 user         0.64 sys

Re: Beating C with 70 lines of Go

#50

Post by fao_ »

Something I posted elsewhere:

All of these articles are frustrating because they use different environments and test sets and none of the ones I’ve read have posted the test sets up. Some people use random characters, some people use existing files. Some people use files of 1 MiB, some 100 MiB, some several GiB in size. Not only that, but the people programming the replacements don’t even normalize for the difference in machine/processor capability by compiling the competitors and GNU wc from scratch. The system wc is likely to be compiled differently depending on your machine. The multithreaded implementations are going to perform differently depending on if you’re running Chrome when you test the app or not, etc.

This would easily be solved by using the same distribution as a live USB, sharing testing sets, and compiling things from scratch with predefined options, but nobody seems to want to go to that much effort to get coherent comparisons.

Post reply on HN