Live data from Hacker News

Beating C with 70 lines of Go

ajeetdsouza.github.io

91–100 of 106 posts

Re: Beating C with 70 lines of Go

#91

Earlier quoted context omitted.

https://news.ycombinator.com/item?id=18399389 . It's been done. Performs well.

They quite literally were forced to use C for some parts because Go is not a systems programming language. They write this in the article.

> As we wanted to keep unsafe code to a minimum, we instead chose to employ the C code from the original driver as an opportunity to present cgo.

It's not for performance reasons. I think you misread. Also the driver is pure go now:

https://github.com/ixy-languages/ixy.go

Re: Beating C with 70 lines of Go

#92

Earlier quoted context omitted.

If domulti is not set, the wide char function is not called as far as I can tell. Why would it? It's explicitly meant not to do wide char stuff in that case. FWIW, when this was going around for the first time I took this Darwin version of wc and experimented with setting domulti to const 0, statically removing all paths where it might do wide character stuff. I didn't measure any performance difference to just runni…

It's about iswspace as I mentioned in the parent comment. Replace the line if (iswspace(wch)) by if (wch == L' ' || wch == L'\n' || wch == L'\t' || wch == L'\v' || wch == L'\f') And I get a ~1.7x speedup: $ time ./wc ../wiki-large.txt 854100 17794000 105322200 ../wiki-large.txt ./wc ../wiki-large.txt 0.47s user 0.02s system 99% cpu 0.490 total time ./wc2 ../wiki-large.txt 854100 17794000 105322200 ../wiki-large.txt .…

Thanks, I finally understood what you are saying. Indeed, the code uses iswspace to test all characters, wide or normal. Strange design choice. For whatever it's worth, even just changing

    if (iswspace(wch))
to something like

    if (domulti && iswspace(wch))
        ...
    else if (!domulti && isspace(wch))
        ...
got something like a 10% speedup on my machine. And replacing isspace with an explicit condition like yours is much faster still. I checked, isspace is macro-expanded to a table lookup and a mask, but apparently that's still slower than your explicit check. I'm a bit surprised by this but won't investigate further at the moment.

Re: Beating C with 70 lines of Go

#93

Earlier quoted context omitted.

It's about iswspace as I mentioned in the parent comment. Replace the line if (iswspace(wch)) by if (wch == L' ' || wch == L'\n' || wch == L'\t' || wch == L'\v' || wch == L'\f') And I get a ~1.7x speedup: $ time ./wc ../wiki-large.txt 854100 17794000 105322200 ../wiki-large.txt ./wc ../wiki-large.txt 0.47s user 0.02s system 99% cpu 0.490 total time ./wc2 ../wiki-large.txt 854100 17794000 105322200 ../wiki-large.txt .…

Thanks, I finally understood what you are saying. Indeed, the code uses iswspace to test all characters, wide or normal. Strange design choice. For whatever it's worth, even just changing if (iswspace(wch)) to something like if (domulti && iswspace(wch)) ... else if (!domulti && isspace(wch)) ... got something like a 10% speedup on my machine. And replacing isspace with an explicit condition like yours is much faster…

Thanks, I finally understood what you are saying.

I am sorry for the unclear comments. I'll stop commenting on a phone ;).

Indeed, the code uses iswspace to test all characters, wide or normal. Strange design choice.

I agree, it's really strange. This seems to be inherited by the FreeBSD version, which still does that as well:

https://github.com/freebsd/freebsd/blob/8f9d69492c3da3a8c1ea...

It has the worst of both worlds: it incorrectly counts the number of words when there is non-ASCII whitespace (since mbrtowc is not used), but it pays the penalty of using iswspace. It's also not in correspondence with POSIX, which states:

The wc utility shall consider a word to be a non-zero-length string of characters delimited by white space.

[...]

C_CTYPE

Determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments and input files) and which characters are defined as white space characters.

Re: Beating C with 70 lines of Go

#94

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 f…

Alternatively, here's my entry for "Beating GNU wc with GNU wc":

    $ dd if=/dev/urandom of=100m bs=1M count=100 2> /dev/null

    $ time wc -w 100m
    2319144 100m

    real 0m4.543s
    user 0m4.512s
    sys 0m0.029s

    $ time env LC_CTYPE=C wc -w 100m
    2308032 100m

    real 0m0.842s
    user 0m0.842s
    sys 0m0.000s
Your program is faster, though.

Re: Beating C with 70 lines of Go

#95
post #90
post #89

Earlier quoted context omitted.

Just like you can in Go, as proven by TinyGo. Or in dozen of other GC enabled systems programming languages for that matter.

Tip: Give up dude.

Exactly my tip to the anti-GC luddites.

The difference being evolution, takes care of sorting that out, like in all anti-technology groups throughout mankind history.

Re: Beating C with 70 lines of Go

#96

Earlier quoted context omitted.

They quite literally were forced to use C for some parts because Go is not a systems programming language. They write this in the article.

> As we wanted to keep unsafe code to a minimum, we instead chose to employ the C code from the original driver as an opportunity to present cgo. It's not for performance reasons. I think you misread. Also the driver is pure go now: https://github.com/ixy-languages/ixy.go

Systems language is not only about performance. Where did you get that?

Re: Beating C with 70 lines of Go

#97
post #95
post #90

Earlier quoted context omitted.

Tip: Give up dude.

Exactly my tip to the anti-GC luddites. The difference being evolution, takes care of sorting that out, like in all anti-technology groups throughout mankind history.

Seem seem to have a personal issue with this.

Re: Beating C with 70 lines of Go

#98

Earlier quoted context omitted.

> As we wanted to keep unsafe code to a minimum, we instead chose to employ the C code from the original driver as an opportunity to present cgo. It's not for performance reasons. I think you misread. Also the driver is pure go now: https://github.com/ixy-languages/ixy.go

Systems language is not only about performance. Where did you get that?

They never said that they had to use c because go is not a systems language, so your assertion looks wrong. They wanted to avoid using unsafe. In c everything is unsafe by the way, so it makes it less of a systems language?

Re: Beating C with 70 lines of Go

#99

Earlier quoted context omitted.

Systems language is not only about performance. Where did you get that?

They never said that they had to use c because go is not a systems language, so your assertion looks wrong. They wanted to avoid using unsafe. In c everything is unsafe by the way, so it makes it less of a systems language?

No Go isn't a systems language because for one you don't have direct control over memory if you need it. For instance Go doesn't even have the volatile keyword which is essential in many cases when interfacing with hardware. The paper you linked laments this as well.

Re: Beating C with 70 lines of Go

#100
post #97
post #95

Earlier quoted context omitted.

Exactly my tip to the anti-GC luddites. The difference being evolution, takes care of sorting that out, like in all anti-technology groups throughout mankind history.

Seem seem to have a personal issue with this.

To the extent that my work is open to memory corruption security exploits, with possible high monetary costs, caused by anti-GC luddites.

https://googleprojectzero.blogspot.com/2019/11/bad-binder-an...

Post reply on HN