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

331–340 of 418 posts

Re: Generics can make your Go code slower

#331

Post by fbkr »

josefx wrote: post #227
fbkr wrote: post #88

Earlier quoted context omitted.

> There are linker flags that allow some deduplication but those have their own drawbacks As long as you use --icf=safe I don't see any drawback, and most of the time it results in almost identical reductions to --icf=all since not many real programs compare addresses of functions.

I think that requires separate function sections, which themselves may cause bloat and data duplication.

I, along with everyone in the embedded space, have been using separate function sections forever for --gc-sections and I would be very surprised if they really cause any bloat and duplication at runtime. Do you mean bloat for intermediate files?

Re: Generics can make your Go code slower

#332

Post by zepolen »

EdwardDiego wrote: post #231
no_circuit wrote: post #129

Earlier quoted context omitted.

The article is from a database company, so I'll assume that approximates the scope. My scope for the GC discussion would include other parts that could be considered similar software: cluster-control plane (Kubernetes), other databases, and possibly the first level of API services to implement a service like an internal users/profiles or auth endpoints. The tricky thing is GC works most of the time, but if you are wo…

> A good portion of production outages are likely related to cascading failures due to too long GC pauses, and a good portion of developer time is spent testing and tuning GC parameters After 14 years in JVM dev in areas where latency and reliability are business critical, I disagree. Yes, excessive GC stop the world pauses can cause latency spikes, and excessive GC time is bad, and yes, when a new GC algorithm is re…

> After 14 years in JVM dev in areas where latency and reliability are business critical

What sort of industry/use cases are we talking here? There is business critical and mission critical and if your experience is in network applications as your next paragraph seems to imply then no offence, but you have never worked with critical systems where an nondeterministic GC pause can send billions worth of metal into the sun or kill people.

Re: Generics can make your Go code slower

#333

Post by morelisp »

randomdata wrote: post #308
hsn915 wrote: post #290

Earlier quoted context omitted.

esbuild is 100x faster than js build tools, so in general 100x speed up sounds about right.

Sucrase, written in Typescript, claims to be 2x faster than esbuild. I'll leave you to your own benchmarks.

Sucrase does this by removing some things you might expect to be table stakes, like detecting invalid parse trees and complete JS syntax. Pragmatically, esbuild can also start faster and parallelize, which means shorter wall-clock builds.

Re: Generics can make your Go code slower

#334

Post by pjmlp »

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…

Java made a huge mistake of not being like Oberon, Modula-3, Eiffel, Mesa/Cedar,....

However that doesn't make all GC languages equal and measured by Java's bad decisions at birth.

Re: Generics can make your Go code slower

#335

Post by rastignack »

mcronce wrote: post #147
svnpenn wrote: post #105

Earlier quoted context omitted.

You should probably read the rest of the comment...

Are Result and Option really the only thing? Because nesting scopes based on Err/None is rarely the right choice, just like nesting a scope based on `if err == nil` isn't typically something you want to do in Go, or `if errno == 0` in C - You can panic trivially with `.unwrap()` - You can propagate the condition up trivially with `?` - `?` doesn't work with all types, but it does work with Option, and it does work wi…

However in typical rust code bases this systematic wrapping causes a lot of unhandled panics.

Reading it feels just wrong.

Re: Generics can make your Go code slower

#336

Post by scoutt »

titzer wrote: post #128
fauigerzigerk wrote: post #116

Earlier quoted context omitted.

>I've seen this sentiment a lot, and I never see specifics. "GC is bad for systems language" is an unsupported, tribalist, firmly-held belief that is unsupported by hard data. I would argue it's not (very) hard data that we need in this case. My opinion is that the resource usage of infrastructure code should be as low as possible so that most resources are available to run applications. The economic viability of app…

> Systems/infrastructure code on the other hand is subject to very different economics. It runs all the time. The ratio of development time to runtime is incredibly small. We should optimise the heck out of infrastructure code to drive down resource usage whenever possible. I will assume by "infrastructure code" you mean things like kernels and network stacks. Unfortunately there are several intertwined issues here.…

> This software is important and needs to be memory-safe.

Let's say the GC is a binary... where is this binary? Probably somewhere in the filesystem? So now you need a filesystem written in a language that doesn't depend on the GC, just like the binary loader, scheduler, bootloader, which by the way, can boot from remote, so now you also need a network stack that doesn't use GC.

You might need to show something on the screen before the GC starts up, so you will need video drivers, bus drivers, etc. written in a language that doesn't use a GC.

And in which language is the GC written?

You get the idea.

Re: Generics can make your Go code slower

#337

Post by josefx »

fbkr wrote: post #331
josefx wrote: post #227

Earlier quoted context omitted.

I think that requires separate function sections, which themselves may cause bloat and data duplication.

I, along with everyone in the embedded space, have been using separate function sections forever for --gc-sections and I would be very surprised if they really cause any bloat and duplication at runtime. Do you mean bloat for intermediate files?

It may be limited to intermediate files, I assumed that the downside would be bigger since it is not a default and the description mentioned that some things may not be merged as well.

Re: Generics can make your Go code slower

#338

Post by fileeditview »

lultimouomo wrote: post #321
akvadrako wrote: post #236

Earlier quoted context omitted.

That could mostly be due to multithreading. That comes free with go but requires a different model in node.

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.

Re: Generics can make your Go code slower

#339

Post by xyproto »

3a2d29 wrote: post #280
xyproto wrote: post #229

Earlier quoted context omitted.

Both. It can be paused or disabled at runtime.

But then presumably if you disable it you have to have no heap allocation at any time in your program, or manually manage buffers. I feel like that's not worth it.

Sure. But it's not mandatory. And if it's about optimization, pausing the GC for critical regions can be useful, or just pre-allocating memory.

Re: Generics can make your Go code slower

#340

Post by native_samples »

socialdemocrat wrote: post #247
coder543 wrote: post #143

Earlier quoted context omitted.

Go doesn’t offer a bunch of GC tuning parameters. Really only one parameter, so your concerns about complex GC tuning here seem targeted at some other language like Java. This is a drawback in some cases, since one size never truly fits all, but it dramatically simplifies things for most applications, and the Go GC has been tuned for many years to work well in most places where Go is commonly used. The developers of…

Java _needs_ lots of GC tuning parameters because you have practically no way of tuning the way your memory is used and organized in Java code. In Go you can actually do that. You can decide how data structures are nested, you can take pointers to the inside of a a block of memory. You could make e.g. a secondary allocator, allocating objects from a contiguous block of memory. Java doesn't allow those things, and thu…

That's the Go party line but not really true.

Counter-example: The Go GC is tuned for HTTP servers at latency sensitive companies like Google. It therefore prioritizes latency over throughput to an astonishing degree, which means it is extremely bad at batch jobs - like compilers.

What language is the Go compiler written in? Go.

This isn't fixable by simply writing the code differently. What you're talking about is in the limit equivalent to not using a GCd language at all, and you can do that with Java too via the Unsafe allocators. But it's not a great idea to do that too much, because then you may as well just bite the bullet and write C++.

Java doesn't actually need lots of GC tuning parameters. Actually most of the time you can ignore them, because the defaults balance latency and throughput for something reasonable for the vast majority of companies that aren't selling ad clicks. But, if you want, you can tell the JVM more about your app to get better results like whether it's latency or throughput sensitive. The parameters are there mostly to help people with unusual or obscure workloads where Go simply gives up and says "if you have this problem, Go is not for you".

Post reply on HN