Beating C with 70 lines of Go • Hacker News Board

Re: Beating C with 70 lines of Go

#71

Post by aeyes » Wed, Nov 20, 2019, 10:47 PM UTC

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"

The GNU tools have been hand optimized for decades! If there is performance left on the table, feel free to submit a patch!

Just look at the amount of optimization that has gone into yes: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes...

Re: Beating C with 70 lines of Go

#72

Post by tom_mellior » Wed, Nov 20, 2019, 11:06 PM UTC

microtonal wrote: post #37

eMSF wrote: post #29

Earlier quoted context omitted.

It only calls mbrtowc if domulti is set (and MB_CUR_MAX > 1), i.e. only when given the option -m.

You are right! So that's a Darwin oddity, still a wide char function is called in that code path, iswspace, which adds the function call overhead in a tight loop.

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 running it unmodified.

Re: Beating C with 70 lines of Go

#73

Post by devjam » Wed, Nov 20, 2019, 11:44 PM UTC

Under the "Better parallelisation" section, you don't need to proxy methods for your sync.Mutex if you embed the type.

    type FileReader struct { 
        File            *os.File
        LastCharIsSpace bool
        sync.Mutex
    }

And your Lock() and Unlock() calls on FileReader would just work.

Re: Beating C with 70 lines of Go

#74

Post by naikrovek » Thu, Nov 21, 2019, 12:52 AM UTC

pleasecalllater wrote: post #56

zenhack wrote: post #22

Earlier quoted context omitted.

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/ .

It depends on how many things need to be collected, which is often a function of heap size.

Re: Beating C with 70 lines of Go

#75

Post by ksaj » Thu, Nov 21, 2019, 12:57 AM UTC

Speedy CPUs with lots of cores are cheap enough that the time taken for garbage collection may very well be worth it.

On the other hand, I do still love code golf and other speed/size/wonkiness competitions. It's a lot like the early demo scene whose sole effort was to show how much they could do with very limited resources.

Re: Beating C with 70 lines of Go

#76

Post by ajeetdsouza » Thu, Nov 21, 2019, 1:46 AM UTC

devjam wrote: post #73

Under the "Better parallelisation" section, you don't need to proxy methods for your sync.Mutex if you embed the type. type FileReader struct { File *os.File LastCharIsSpace bool sync.Mutex } And your Lock() and Unlock() calls on FileReader would just work.

Fixed, thank you!

Re: Beating C with 70 lines of Go

#77

Post by [deleted] » Thu, Nov 21, 2019, 2:13 AM UTC

pjmlp wrote: post #70

Gibbon1 wrote: post #44

Earlier quoted context omitted.

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…

This is not lying: - gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks - Android GPGPU debugger - Fuchsia TCP/IP stack and volume management - Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others - Coreboot firmware - Biscuit POSIX like OS But whatever, the GC-FUD is strong among C devotees.

[deleted]

Re: Beating C with 70 lines of Go

#78

Post by saghm » Thu, Nov 21, 2019, 3:02 AM UTC

manningthegoose wrote: post #5

jimbob45 wrote: post #2

These 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.

I'm not sure this proves that Go is a possible systems language, since it could be equally like that the explanation is just "wc doesn't need to be written in a systems language to be fast". For an executable that runs, processes some stuff, and then terminates in the span of a second or so, you're not going to incur much slowdown due to a GC counting references and cleaning stuff up, but for something long-running, it could make more of a difference.

Re: Beating C with 70 lines of Go

#79

Post by crematoria » Thu, Nov 21, 2019, 4:23 AM UTC

__d wrote: post #60

zenhack wrote: post #22

Earlier quoted context omitted.

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.

Strange. I know OCaml is used in HFT (thanks to all those Jane Street ads) and OCaml is also GC'd. What does OCaml have here that Go doesn't?

Re: Beating C with 70 lines of Go

#80

Post by crematoria » Thu, Nov 21, 2019, 4:26 AM UTC

IshKebab wrote: post #26

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?

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.

Source? People write CLI tools in Ruby and Node.js these days, so I really doubt that anybody would use the term "systems language" to refer to languages well-suited to building CLI tools.