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

Taming Go’s memory usage, or how we avoided rewriting our client in Rust

akitasoftware.com

Post reply on HN
Print view View original

221–230 of 231 posts

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#221

Post by Zababa »

klyrs wrote: post #151
Zababa wrote: post #101

Earlier quoted context omitted.

And Go too! It's always fun to see posts from around 2014/2015 complaining about how every submission to Hacker News is now "I wrote X in Go", while now Go is the boring stuff and Rust is the hot new thing. I wonder what will be the next Rust though.

Write it in Malbolge? Slightly less silly, modern C++ and modern Python are evergreen.

They are, but they also are too big, so at some point people will want to replace them with something simpler/smaller. Go has been used for this for some projects in C++ and Python.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#222

Post by roca »

zarzavat wrote: post #159
roca wrote: post #135

Earlier quoted context omitted.

> the side effects of making your team less productive by using Rust is a much higher price to pay than just running you Go service on more powerful hardware. This entirely depends on the ratio of development effort to deployed instances. At one end of the spectrum, lots of developers work for years on a system which is only deployed on one machine; obviously you optimize for developer effort and buy a single massive…

My problem with Rust: I'm sure that if I used it as my primary language for a couple of years, I would be able to claw the productivity loss back. But I can't find any reason to justify using it at my current productivity level. There is a vicious cycle: few projects use Rust because the productivity hit is large, and programmers do not get enough experience using Rust because few projects use it.

I don't think that vicious cycle exists. I was immediately productive with Rust, but OK, that's just an anecdote. Surveys such as Stackoverflow's Developer Survey show Rust usage growing rapidly.

If I met someone who took years to be productive with Rust, I would conclude they lack aptitude for programming. Maybe harsh, but probably true.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#223

Post by igouy »

fiddlerwoaroof wrote: post #218
igouy wrote: post #209

Earlier quoted context omitted.

> … tasks like implementing lock-free hash maps… Please be specific. You pointed to spectral-norm, what does that have to do with lock-free hash maps? The 2.java program seems to be 4x slower than the 7.rs program !

Look at 2.cl, though: the lisp solution is faster than everything except one c++ solution. (And, aside from the SIMD intrinsics, the lisp solution is fairly idiomatic) I was referring to this with the lock-free hash maps: https://twitter.com/nodefunallowed/status/137196906733924761...

> I was referring to this with the lock-free hash maps…

Well thank you for providing an actual reference.

afaict from a twitter thread, "42nd At Threadmill" and "Luckless" are both Lisp re-implementations of the same Java hashtable code.

afaict the Rust sofware is not a re-implementation of that same Java hashtable code.

afaict that chart does not show any measurements of Java software, just Lisp and Rust.

So "… Java can match or exceed Rust …" seems to be based on nothing.

> Look at 2.cl, though…

So hand-coded AVX is hand-coded AVX in any language?

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#224

Post by roca »

roca wrote: post #135
jgrant27 wrote: post #111

After using Rust for a few years professionally it's my take that people that really want to use it haven't had much experience with it on real world projects. It just doesn't live up to the hype that surrounds it. The memory and CPU savings are negligible between Go and Rust in practice no matter what people might claim in theory. However, the side effects of making your team less productive by using Rust is a much…

> the side effects of making your team less productive by using Rust is a much higher price to pay than just running you Go service on more powerful hardware. This entirely depends on the ratio of development effort to deployed instances. At one end of the spectrum, lots of developers work for years on a system which is only deployed on one machine; obviously you optimize for developer effort and buy a single massive…

I guess I wasn't clear. We were happy with Rust from almost day 1. After five years, we're still happy.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#225

Post by Brentward »

NegatioN wrote: post #189

This might be more fit for StackOverflow, but I have a related question. I have a Go application that runs in Kubernetes, where memory usage steadily increases until it's at around 90% of the cgroup limit, where it seems to stabilize. As far as I can tell, Go GC uses the container memory limits to navigate it's total memory usage (this might be the fault of the OS not reclaiming what Go has already freed(?)). However…

Since Go seems to respect the memory limit, you could try using syscall.Setrlimit to set an artificially lower limit that you know will leave enough room for your other allocations. Have you tried playing with the GOGC environment variable from the runtime package? Maybe you could also manually collect a memory profile with runtime.MemProfile and call runtime.GC() if needed, but I've never done anything like this, just throwing out ideas I would probably try

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#226

Post by chakkepolja »

titzer wrote: post #60
tptacek wrote: post #39

The big wins in this article, in what I believe was the order of impact: * They do raw packet reassembly using gopacket, and gopacket keeps TCP reassembly buffers that can grow without bound when you miss a TCP segment. They capped the buffers, and the huge 5G spikes went away. * They were reading whole buffers into memory before handing them off to YAML and JSON parsers. They passed readers instead. * They were usin…

> Frankly I'm surprised Go acquitted itself as well as it did here. As opposed to, e.g. Java, which I ranted elsewhere in the thread, is a trashy mess. I programmed for over a decade in Java, and yeah, it's only gotten worse over the years. They would have done even more custom processing and bypassing of the layers underneath due to Java's typical copy-happiness.

Java the language has improved a lot IME. If you're talking about some specific library, then I don't know.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#227

Post by chakkepolja »

pjmlp wrote: post #57
oconnor663 wrote: post #46

Earlier quoted context omitted.

I think sometimes the "compiler manages memory for you" concept gets overplayed a bit. It's not as complex as that description makes it sound. If you understand C++ destructors, it's really the same thing. Objects get destroyed when they go out of scope, and any memory or other resources they own get freed. The differences come up when you look at what happens when you make a mistake, like holding a pointer to a free…

Try to implement a data structure that works across async runtimes, or a couple of GUI widgets, then you will get the point why some of us complain about the borrow checker, even with decades of experience in C and C++.

Or rather, acting as if rust is positioned to replace general purpose languages.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#228

Post by angelzen »

cormacrelf wrote: post #211
angelzen wrote: post #149

Earlier quoted context omitted.

Thanks. Saw that before, but the credibility/length ratio wasn't high enough to read it more carefully. It appears that we do have to Box/Rc/Arc nodes in a recursive datastructure. Doable, but a bit on the inconvenient side. struct Node { elem: i32, next: Option >, }

All explanations start with why without any indirection, Node would be a recursive, infinitely large type. Therefore the Node must be a pointer. Ok. But then, Rust then forces you to answer this question: who will own the data referred to by the pointer? Consequently, who will be responsible for freeing it? If you use a &mut Node as your pointer, you are attempting to answer those questions with "not me". Someone els…

Thanks for the in-depth dive. My usecase is doing transformations over an AST: trees are immutable, but may become shared or dead deep in the middle of some complex transformation. Probably Rc is the reasonable approach, as Box is too constraining.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#229

Post by fulafel »

kevingadd wrote: post #217
fulafel wrote: post #165

Earlier quoted context omitted.

They're pretty simple in many dynamic languages, eg you can just do "import os; dir(os)" in Python.

yeah, but that doesn't mean they're fast or don't make a mess of the gc heap

I hadn't heard people use messy to refer to garbage cration before!

To continue with Python, yes, you might get a new container (dict) allocated like in the above case to hold the already existing interned attribute name strings. It's still quite light since the object representing the information already exist and are used under the hood in the dynamic typing machinery.

Re: Taming Go’s memory usage, or how we avoided rewriting our client in Rust

#230

Post by pdimitar »

tptacek wrote: post #80
steveklabnik wrote: post #76

Earlier quoted context omitted.

"developer velocity" is also, in some sense, a semantic question. I am special, of course, but basically, if you include things like "time fixing bugs that would have been prevented in Rust in the first place", my velocity is higher in Rust than in many GC'd languages I've used in the past. It just depends on so many factors it's impossible to say definitively one way or another.

I have trouble believing this, at least in any generalizable way. I'm comfortable in both Go and Rust at this point (my Rust has gotten better since last year when I was griping about it on HN), and it's simply the case that I have to think more carefully about things in Rust because Go takes care of them for me. It's not a "think more carefully and you're rewarded with a program that runs more reliably and so you ma…

> it's just slower to write a Rust program, because the memory management is much fiddlier.

Really depends on what kind of programs do you write. I found that my Rust development gets slowed down only because I have to spend time to create the proper types. Memory management and lifetime problems are very few in my practice (but I can agree that they can swallow a time -- only when you are new though).

Post reply on HN