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

51–60 of 106 posts

Re: Beating C with 70 lines of Go

#51

Post by jstanley »

Alternatively, here's my entry for "Beating C with 40 lines of C": https://pastebin.com/JzFfE5GB

  $ time wc -w 100m
  2266395 100m
  
  real 0m4.568s

  $ cc -o wc wc.c
  
  $ time ./wc 100m
  2343390 100m
  
  real 0m0.511s
Of course, it disagrees on the answer, because I just used 100M of random data and it doesn't care about wide characters. It gives the same answer as GNU on plain ASCII text.

It's not faster because it's better, it's faster because it is doing less.

Re: Beating C with 70 lines of Go

#52

Post by xpe »

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.

This Wikipedia article suggests that Go is not regarded as a systems programming language:

https://en.wikipedia.org/wiki/System_programming_language#Ma...

Re: Beating C with 70 lines of Go

#53

Post by rpmisms »

tuckerpo wrote: post #48

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"

Venison is generally much better-fed meat than grocery store cow.

Re: Beating C with 70 lines of Go

#54

Post by pleasecalllater »

How many times have the tests been run? Once? First for C, then for Go? What about disk caching then?

What I can see there is that for the same algorithm, the Go version was not so fast. It was comparable. The memory overhead could be caused by the size of the program, as wc has more functionalities.

Then there is compared a totally different algorithm with a false claim "this way a go implementation is faster than a c one". Sure it is, as this is a different implementation of a different algorithm. A fair comparison would be implementing the same algorithm in c and comparing then. I assume the difference wouldn't be huge.

So, generally, I think it's not a fair comparison.

Re: Beating C with 70 lines of Go

#55

Post by zik »

tuckerpo wrote: post #48

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"

To be fair the author does say "it has since turned into a game of trying to take on the venerable wc with different languages". Of course the real message is that the original wc isn't particularly efficient and it can be beaten in many different languages - including C.

Re: Beating C with 70 lines of Go

#56

Post by pleasecalllater »

zenhack wrote: post #22
dijit wrote: post #17

Earlier quoted context omitted.

Are we really saying a garbage collected language should be considered for a systems language? I know the GC is fast but surely memory managed languages are going to have less issues with pausing during execution, no?

Re: pause times, Go's garbage collector is actually really good here; you're looking at 10s of microseconds. I'm convinced the term "systems language" doesn't have a coherent meaning at this point. See: https://zenhack.net/2018/07/14/three-funerals-in-the-name-of...

I always thought the GC pause depends on the heap size... a little searching... http://big-elephants.com/2018-09/unexpected-gc-pauses/.

Re: Beating C with 70 lines of Go

#57

Post by ajeetdsouza »

fao_ wrote: post #50

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…

I tested this on a fresh install of Fedora 31, so I didn’t really see any benefit of running it on a LiveUSB. As I mentioned in the article, the wc implementation I used for comparison has been compiled locally with gcc 9.2.1 and -O3 optimizations. I’ve also listed my exact system specifications there. I’ve used the unprocessed enwik9 dataset (Wikipedia dump), truncated to 100 MB and 1 GB.

I understand your frustrations with the previous posts, but I’ve tried to make my article as unambiguous as possible. Do give it a read, if you have any futher suggestions or comments, I’d be happy to hear them!

Re: Beating C with 70 lines of Go

#58

Post by eMSF »

fao_ wrote: post #50

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…

>none of the ones I’ve read have posted the test sets up

I think the earliest(?) entry[1] in this "series" (the one done in Haskell) had their test input shared alongside the source code, and it has been referenced in some others (often multiplied several times over, as the original isn't very big). Beyond that it's ASCII only, the contents matter little.

>nobody seems to want to go to that much effort to get coherent comparisons

I think nobody really wants to get any coherent comparisons, because this thing isn't really a competition between the entries themselves.

[1]: https://github.com/ChrisPenner/wc (see data/big.txt)

Re: Beating C with 70 lines of Go

#59

Post by ajeetdsouza »

tuckerpo wrote: post #48

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"

Author here. I think you should go through the article again. I think it's quite readable, and there are no "hand-optimizations" as you say. Also, the single-core implementation was already faster than the C version - the multithreaded version was only done to explore different methods of concurrency in Go.

Hope that clarifies things.

Re: Beating C with 70 lines of Go

#60

Post by __d »

zenhack wrote: post #22
dijit wrote: post #17

Earlier quoted context omitted.

Are we really saying a garbage collected language should be considered for a systems language? I know the GC is fast but surely memory managed languages are going to have less issues with pausing during execution, no?

Re: pause times, Go's garbage collector is actually really good here; you're looking at 10s of microseconds. I'm convinced the term "systems language" doesn't have a coherent meaning at this point. See: https://zenhack.net/2018/07/14/three-funerals-in-the-name-of...

Right, so when I’m trying to process a network packet in about a microsecond (a reasonable target for financial trading software), Go’s GC rules it out. Many low-level, high-performance systems language tasks aren’t feasible in Go for similar reasons.

That doesn’t make it a bad language, but it’s not universally applicable either.

Post reply on HN