A “Better C” Benchmark

Post by igouy » Tue, Mar 30, 2021, 5:58 AM UTC

simpleguitar wrote: post #189

igouy wrote: post #187

Earlier quoted context omitted.

Non sequitur? "Go was born out of frustration with existing languages … To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection …" https://golang.org/doc/faq#creating_a_new_language https://golang.org/doc/faq#garbage_collection Seems like you wished not to show one of Go's big features?

Why can't GC coexist with memory pools? They both have good uses. It's pretty clear that Go designers wanted a GC, but also wanted control over memory. In go, it is trivial to create a slice of structs that's contiguous in memory, and built-ins like 'copy' means the language designers wanted users to use this feature. When I write go, GC is used almost always. Except when it becomes a bottleneck, at which point I tri…

There seem to be plenty of Sync.Pool blog posts, but only a sequential Sync.Pool binary-trees program that I transliterated.

Post by igouy » Tue, Mar 30, 2021, 2:51 PM UTC

axaxs wrote: post #183

igouy wrote: post #179

Earlier quoted context omitted.

https://salsa.debian.org/benchmarksgame-team/archive-alioth-... https://blog.golang.org/ismmkeynote

Thanks for the links, though I'm unsure what the second link is for. I hope my assessment is 'fair.' I used to feel more strongly than I do now, I guess. It's a weird situation. The rules say 'dont write your own memory pools', but new languages wouldn't have a popular library available. Seems it should be 'dont use them at all', or allow them for all. This puts any new language at an immediate disadvantage. Anyhow,…

Perhaps this is the example of what you meant — Sync.Pool was not available until go1.3 (June 2014).

Re: A “Better C” Benchmark

Re: A “Better C” Benchmark