Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics can make your Go code slower

planetscale.com

Post reply on HN
Print view View original

411–418 of 418 posts

Re: Generics can make your Go code slower

#411

Post by shadowgovt »

azth wrote: post #406
shadowgovt wrote: post #364

Earlier quoted context omitted.

Why does golang need JIT when it already statically compiles to a non-virtual machine target? It could probably use some performance optimizations, but JIT would be redundant when it's already compiled.

JIT makes things like the JFR possible.

Honestly, this thread is the first I've heard of Java Flight Recorder, so while I'm sure it has uses, it doesn't seem vital.

Nice-to-have (I've certainly enjoyed something similar writing JavaScript in a browser for years), but most developers aren't writing code under tight-enough constraints to justify a profiler running under a virtual machine.

Re: Generics can make your Go code slower

#412

Post by twhitmore »

ninkendo wrote: post #239
titzer wrote: post #114

Earlier quoted context omitted.

Indeed. What really kills is extremely high allocation rates and extremely high garbage production. I've seen internal numbers from $megacorp that show that trashy C++ programs (high allocation + deallocation rates) look pretty much the same to CPUs as trashy Java programs, but are far worse in terms of memory fragmentation. Trashy C++ programs can end up spending 20+% of their execution time in malloc/free. That's a…

> I will admit that the programming culture is different for many GC'd languages' communities, sometimes encouraging a very trashy programming style, which contributes to the perception that GC itself is the problem For some languages (I’m looking at you, Java), there’s not much of a way to program that doesn't generate a bunch of garbage, because only primitives are treated as value types, and for Objects, heap allo…

You can run high-volume business and mid-level infrastructure (messaging) systems day-in day-out in Java, and struggle to see more than 0.1% CPU needed for garbage collection.

The light-bulb idea here is about reliability, security and productivity. Managing memory manually a la C/ C++ is a proven disaster in all three respects.

Maybe ten or fifteen years ago GC was costly, but these days it's highly efficient and not incomparable with programmatic allocation.

Re: Generics can make your Go code slower

#413

Post by yencabulator »

jokoon wrote: post #391
bborud wrote: post #197

Earlier quoted context omitted.

Let’s start at the beginning. What is a «systems language» and for what is it typically used?

Something that is used to write an OS, low level programming, low memory footprint, high performance/optimized.

Please accept that that's your opinion. https://en.wikipedia.org/wiki/System_software

Re: Generics can make your Go code slower

#414

Post by yencabulator »

jokoon wrote: post #410
bborud wrote: post #399

Earlier quoted context omitted.

When you say OS, do you mean kernel or kernel and the daemons?

Both. Also everything that has low memory, like embedded systems. Anything that is real time cannot have a GC, because GC are unpredictable. So everything in aircraft, space, when it has time sensitive machinery...

https://en.wikipedia.org/wiki/Tracing_garbage_collection#Rea...

Re: Generics can make your Go code slower

#415

Post by adonovan »

fileeditview wrote: post #338
lultimouomo wrote: post #321

Earlier quoted context omitted.

50000/250=200, that is a lot of cores!

That calculation assumes that Go and Node have the same performance and the only gain is by parallelism. But I agree.. the performance difference seems strange. On a 1 core basis I'd expect something like a factor 2-5 gain.

Identical algorithms (e.g. quicksort) run ~40x faster in Go than Ruby in a single thread due to more efficient CPU usage, even when you avoid the kinds of steps that would allocate objects in Ruby. Multiply by 64 cores and it’s easy to observe a 1000x improvement with very little difference in the code.

Re: Generics can make your Go code slower

#416

Post by bborud »

jokoon wrote: post #410
bborud wrote: post #399

Earlier quoted context omitted.

When you say OS, do you mean kernel or kernel and the daemons?

Both. Also everything that has low memory, like embedded systems. Anything that is real time cannot have a GC, because GC are unpredictable. So everything in aircraft, space, when it has time sensitive machinery...

Anything that can't have a gc probaly can't use a regular memory allocator either (since they aren't necessarily easy to predict). So you would be left with static allocation and stack variables.

Re: Generics can make your Go code slower

#417

Post by looshch »

skavi wrote: post #350
nunez wrote: post #176

Earlier quoted context omitted.

yeah the formatting on this article was insanely good for a technical blog post. Good job, Planetscale marketing!

The font they use for their code examples is quite nice. Does anyone happen to know what it is?

IBM Plex Mono

Re: Generics can make your Go code slower

#418

Post by geenat »

jordanlewis wrote: post #297
zachruss92 wrote: post #145

For me Go has replaced Node as my preferred backend language. The reason is because of the power of static binaries, the confidence that the code I write today can still run ten years from now, and the performance. The difference in the code I’m working with is being able to handle 250 req/s in node versus 50,000 req/s in Go without me doing any performance optimizations. From my understanding Go was written with dev…

Director of engineering for CockroachDB SQL here. One of the major pain points we have with Go is the lack of language support for monomorphization. We rely on a hand-built monomorphizing code generator [0] to compile CockroachDB's vectorized SQL engine [1]. Vectorized SQL is about producing efficient, type and operator specific code for each SQL operator. As such, we rely on true monomorphization to produce a perfor…

Underrated post. Fast generics in go in under 30 lines? Thank you.

Feels like this approach could be leveraged to get default parameters / optional parameters in Golang too! The Go AST / token lib seems ridiculously flexible.

Huge CockroachDB fan btw. Thanks for the revolution in databases!

PS: Showcase of the awesome Go AST / token lib if you're a Python fan: http://igo.herokuapp.com/

Post reply on HN