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

31–40 of 106 posts

Re: Beating C with 70 lines of Go

#31

Post by aikah »

ajeetdsouza wrote: post #16
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.

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!

How much memory does your program uses VS the C program? Did you profile that?

Re: Beating C with 70 lines of Go

#32

Post by [deleted] »

eMSF wrote: post #29
microtonal wrote: post #27

Earlier quoted context omitted.

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.

[deleted]

Re: Beating C with 70 lines of Go

#33

Post by [deleted] »

johnvega wrote: post #12
big_chungus wrote: post #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…

A great example of complex program written in C then ported to Go was the original Go compiler.

[deleted]

Re: Beating C with 70 lines of Go

#34

Post by aikah »

big_chungus wrote: post #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…

Furthermore this isn't "system programming", he just replaced a "user land" program with another. But I blame the Go team for turning "system programming" and "realtime programming" into useless buzzwords to promote their language.

Re: Beating C with 70 lines of Go

#35

Post by ajeetdsouza »

cjensen wrote: post #23
ajeetdsouza wrote: post #16

Earlier quoted context omitted.

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.

Argument parsing is hardly the bottleneck when you're scanning 1 GB of data. The reason I didn't implement the rest of the features was to keep the implementation light and readable, and I don't think a fully compliant wc implemented in Go with these patterns would be significantly slower.

As for having a low-memory footprint, 2 of the 4 implementations I mentioned (one single core, one multi-core) consume less memory than wc, and still run much faster.

Re: Beating C with 70 lines of Go

#36

Post by Someone »

aikah wrote: post #31
ajeetdsouza wrote: post #16

Earlier quoted context omitted.

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!

How much memory does your program uses VS the C program? Did you profile that?

FTA: ”Our parallelized implementation runs at more than 3.5x the speed of wc, while matching its memory consumption”

Re: Beating C with 70 lines of Go

#37

Post by microtonal »

eMSF wrote: post #29
microtonal wrote: post #27

Earlier quoted context omitted.

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.

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.

Re: Beating C with 70 lines of Go

#38

Post by weberc2 »

dijit wrote: post #17
manningthegoose wrote: post #5

Earlier 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?

As others mentioned "systems language" isn't well defined. If you want to define a "systems program" as one with hard real-time requirements, then no, Go isn't a very good choice; however, the article defines it differently (such that `wc` satisfies), and demonstrates that Go satisfies that definition.

That said, it's better to use terms that map better to a set of requirements, such as "hard-realtime" or "soft-realtime".

Re: Beating C with 70 lines of Go

#39

Post by strange_aeons »

aikah wrote: post #31
ajeetdsouza wrote: post #16

Earlier quoted context omitted.

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!

How much memory does your program uses VS the C program? Did you profile that?

Yes, it's the last column in all the result tables.

Re: Beating C with 70 lines of Go

#40

Post by [deleted] »

aikah wrote: post #31
ajeetdsouza wrote: post #16

Earlier quoted context omitted.

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!

How much memory does your program uses VS the C program? Did you profile that?

[deleted]
Post reply on HN