Looks like clean idiomatic go code to me.
Beating C with 70 lines of Go
21–30 of 106 posts
Re: Beating C with 70 lines of Go
#22Earlier quoted context omitted.
I actually disagree. If you look at the code written in the article, it's hardly unreadable or very code golf-y as you suggest. I think the author is really just trying to say that programmers shouldn't dismiss Go as a possible systems language in favor of C just because C has a reputation of being faster in all cases.
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...
Re: Beating C with 70 lines of Go
#23These articles seem like they're playing code golf more than proving anything as a viable alternative to C. The goal is to analyze your needs and pick the language best suited to your task. The goal is not to find one language that excels at everything.
Author here. Why do you feel it is code golf? My primary focus when writing it was readability - I'm sure I could do it in much less than 70 lines if I had to. If you have any suggestions for improving the readability of my implementation, do let me know!
The version you are comparing against is ancient and assumes a low-memory footprint. It only uses something like 10KB of data. It also has a ton more features -- like command line parsing, the ability to read from a file on the command line or stdin, and locale-specific recognition of whitespace.
It's really not solving the same problem.
Re: Beating C with 70 lines of Go
#24[deleted]
Re: Beating C with 70 lines of Go
#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.
Re: Beating C with 70 lines of Go
#26Earlier quoted context omitted.
I actually disagree. If you look at the code written in the article, it's hardly unreadable or very code golf-y as you suggest. I think the author is really just trying to say that programmers shouldn't dismiss Go as a possible systems language in favor of C just because C has a reputation of being faster in all cases.
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?
In the sense that the Go authors used "systems language", i.e. for writing things like servers and command line tools, sure why not? Go's GC pauses are extremely short (under 1ms). That shouldn't really affect much.
Re: Beating C with 70 lines of Go
#27Another 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…
Author here. This is not true - I included a link to the manpage ( https://ss64.com/osx/wc.html ) in the article to avoid this confusion. I did not use GNU wc; I used the OS X one, which, by default, counts single byte characters. From the manpage: > The default action is equivalent to specifying the -c, -l and -w options. > -c The number of bytes in each input file is written to the standard output. > -m The number…
It is not about the character count, but the word count. wc decodes characters to find non-ASCII whitespace as word separators. If you read further in the same man page:
White space characters are the set of characters for which the iswspace(3) function returns true.
That your text is ASCII encoded does not matter, since ASCII is a subset of UTF-8. So at the very least, you need an extra branch to check that a byte's value is smaller than 128 (since any byte that does not start with a leading zero is a multi byte character in UTF-8).
However, if you look at the implementation at
https://opensource.apple.com/source/text_cmds/text_cmds-68/w...
You can see that in this code path it actually uses mbrtowc, so there is also the function call overhead.
Re: Beating C with 70 lines of Go
#28Another 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.
Re: Beating C with 70 lines of Go
#29Earlier quoted context omitted.
Author here. This is not true - I included a link to the manpage ( https://ss64.com/osx/wc.html ) in the article to avoid this confusion. I did not use GNU wc; I used the OS X one, which, by default, counts single byte characters. From the manpage: > The default action is equivalent to specifying the -c, -l and -w options. > -c The number of bytes in each input file is written to the standard output. > -m The number…
It is not about the character count, but the word count. wc decodes characters to find non-ASCII whitespace as word separators. If you read further in the same man page: White space characters are the set of characters for which the iswspace(3) function returns true. That your text is ASCII encoded does not matter, since ASCII is a subset of UTF-8. So at the very least, you need an extra branch to check that a byte's…
It only calls mbrtowc if domulti is set (and MB_CUR_MAX > 1), i.e. only when given the option -m.
Re: Beating C with 70 lines of Go
#30wc 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.