Beating C with 70 lines of Go
ajeetdsouza.github.io
Beating C with 70 lines of Go
1–10 of 106 posts
Re: Beating C with 70 lines of Go
#2These 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.
Re: Beating C with 70 lines of Go
#3These 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.
I could be wrong, but it seems like it wouldn't be difficult to outperform these implementations with a similarly hacky C implementation. I expect that blog post in the coming days.
Re: Beating C with 70 lines of Go
#4These 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.
I could be wrong, but it seems like it wouldn't be difficult to outperform these implementations with a similarly hacky C implementation. I expect that blog post in the coming days.
Why wait?! Do your "Beating C with C" blog post and enjoy your HN fame!
Re: Beating C with 70 lines of Go
#5These 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.
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.
Re: Beating C with 70 lines of Go
#6wc 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.
Re: Beating C with 70 lines of Go
#7Another 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 trigger a code path that does not do decoding beyond the byte level, it’s much faster:
$ time wc wiki-large.txt
854100 17794000 105322200 wiki-large.txt
wc wiki-large.txt 0.42s user 0.02s system 99% cpu 0.438 total
$ time wc -l wiki-large.txt
854100 wiki-large.txt
wc -l wiki-large.txt 0.02s user 0.02s system 98% cpu 0.034 total
From a quick glance, this is also where the 'Haskell beats C' article fails. It’s comparing apples to oranges, the ByteString implementation does not do the same as GNU/macOS wc and returns incorrect results in the presence of non-ASCII punctuation. The article incorrectly states that wc will handle input as ASCII. Unless you do not use a multi-byte locale, macOS wc uses the combo of mbrtowc and iswspace.
Re: Beating C with 70 lines of Go
#8These 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.
I could be wrong, but it seems like it wouldn't be difficult to outperform these implementations with a similarly hacky C implementation. I expect that blog post in the coming days.
It's mentioned in the post https://github.com/expr-fi/fastlwc/
Re: Beating C with 70 lines of Go
#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 coreutils also tend to focus on having tons of features (compared to BSD/busybox/plan9/other), which can slow them down. If you really want to get competitive, I bet an AVX-512 implementation would be fastest, and that's more doable in C, but this is a bogus comparison in any case. It's just people doing this because they like a specific language.
Re: Beating C with 70 lines of Go
#10Earlier quoted context omitted.
I could be wrong, but it seems like it wouldn't be difficult to outperform these implementations with a similarly hacky C implementation. I expect that blog post in the coming days.
It's mentioned in the post https://github.com/expr-fi/fastlwc/
Ah, I didn't see that. Thanks!