Beating C with 70 lines of Go • Hacker News Board

Re: Beating C with 70 lines of Go

#101

Post by derefr » Fri, Nov 22, 2019, 5:40 PM UTC

fao_ wrote: post #50

Something I posted elsewhere: All of these articles are frustrating because they use different environments and test sets and none of the ones I’ve read have posted the test sets up. Some people use random characters, some people use existing files. Some people use files of 1 MiB, some 100 MiB, some several GiB in size. Not only that, but the people programming the replacements don’t even normalize for the difference…

> This would easily be solved by using the same distribution as a live USB, sharing testing sets, and compiling things from scratch with predefined options, but nobody seems to want to go to that much effort to get coherent comparisons.

Alternatively, you could have a sort of "shootout CI server" where people upload their compiled binaries as Docker images and the CI server runs them against several a random subset from a set of (hidden) fixed test datasets, averaging the results. (Random and hidden such that you can't just overfit against the test set; fixed so that it's still mostly measuring the same thing.)

I think the Netflix Prize sort of worked like this?

Re: Beating C with 70 lines of Go

#102

Post by Gibbon1 » Fri, Nov 22, 2019, 7:36 PM UTC

pjmlp wrote: post #100

Gibbon1 wrote: post #97

Earlier quoted context omitted.

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

Great we can have system software that's as shitty as user facing now.

Re: Beating C with 70 lines of Go

#103

Post by pjmlp » Sat, Nov 23, 2019, 7:17 AM UTC

Gibbon1 wrote: post #102

pjmlp wrote: post #100

Earlier quoted context omitted.

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

Great we can have system software that's as shitty as user facing now.

"The Singularity research codebase and design evolved to become the Midori advanced-development OS project. While never reaching commercial release, at one time Midori powered all of Microsoft’s natural language search service for the West Coast and Asia."

https://www.microsoft.com/en-us/research/project/singularity...

Re: Beating C with 70 lines of Go

#104

Post by dijit » Sun, Nov 24, 2019, 12:00 PM UTC

pjmlp wrote: post #65

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?

Yes, as proven multiple times, and being pushed forward by the likes of Apple, Google and Microsoft. Regarding using Go as a real systems language (in the same meaning as C): - 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 ot…

Coreboot is C/ASM though.

Re: Beating C with 70 lines of Go

#105

Post by zhangxp1998 » Mon, Nov 25, 2019, 4:45 PM UTC

Okay, so you are comparing single-threaded GNU wc with your multi-threaded Go implementation? That's fair.

Re: Beating C with 70 lines of Go

#106

Post by __d » Thu, Nov 28, 2019, 5:16 AM UTC

zenhack wrote: post #81

__d wrote: post #60

Earlier quoted context omitted.

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.

> but it’s not universally applicable either. Nothing is universally applicable. But yeah, I certainly wouldn't use it for hard real-time tasks. If you can't tolerate missing deadlines ever, there is a very short list of acceptable tools. But (and correct me if I'm wrong; it's not my area) HFT doesn't strike me as hard real-time? See also a sibling comment that asks about Jane Street's OCaml use. It's not like GC pau…

That's how those who use Java do it: write their code to minimize allocations, and then configure the JVM with a GC threshold that's bigger than their whole day's allocations, and manually GC at a suitable time.

Last I looked (a while ago) it seemed like there wasn't quite enough control on the Go GC to do this effectively. It's very likely that's been fixed by now.