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

Why Discord is switching from Go to Rust

blog.discordapp.com

Post reply on HN
Print view View original

631–640 of 670 posts

Re: Why Discord is switching from Go to Rust

#631

Post by pkolaczk »

_ph_ wrote: post #587
pkolaczk wrote: post #576

Earlier quoted context omitted.

Languages that have GC frequently rely on heap allocation by default and make plenty of allocations. Languages with good manual memory management frequently rely on stack allocation and give plenty of tools to work with data on the stack. Automatic allocation on the stack is almost always faster than the best GC.

GC languages often do and also often do not. Most modern GC languages have escape analysis. So if the compiler can deduct that an object does not escape the current scope, it is stack allocated instead of heap allocated. Modern JVMs do this and Go does this also. Furthermore, Go is way more allocation friendly than e.g. Java. In Go an array of structs is a single item on the heap (or stack). In Java, you would have a…

Escape analysis is very limited and what I found in practice, it often doesn't work in real code, where not all the things are inlined. If a method allocates an object and returns it 10 layers up, EA can't do anything.

In contrary, in e.g. C I can wrap two 32-bit fields in a struct and freely pass then anywhere with zero heap allocations.

Also, record types are not going to fix the pointer chasing problem with arrays. This is promised by Valhalla, but I'be been hearing about it for 3 years or more now.

Re: Why Discord is switching from Go to Rust

#632

Post by vips7L »

jholman wrote: post #513
vips7L wrote: post #511

Earlier quoted context omitted.

Walter Bright the author of D worked at Facebook writing a fast preprocessor for C/C++ in D.

Alexandrescu, too. They also talked about it pretty frequently. Maybe ggp's claim that D just needs a heavy hitter backing it might be misplaced.

I don't think it's misplaced. Facebook wasn't really backing D by hiring them. And it doesn't seem like that specific project is active anymore.

Re: Why Discord is switching from Go to Rust

#633

Post by pkolaczk »

mcguire wrote: post #380
pkolaczk wrote: post #322

Earlier quoted context omitted.

A high number of short lived allocations is also a bad thing in a compacting GC environment, because every allocation gets you a reference to a memory region touched very long time ago and it is likely a cache miss. You would like to do an object pool to avoid this but then you run into a pitfall with long living objects, so there is really no good way out.

??? The allocation is going to be close to the last allocation, which was touched recently, no? The first allocation after a compaction wii be far from recent allocations, but close to the compacted objects?

Close to the last allocation doesn't matter. What matters is the memory returned to the application - and this is memory that has been touched long ago and unlikely in cache. If your new generation size is larger than L3 cache it will have to be fetched from main memory for sure every time you start the next 64 bytes. I believe a smart cpu will notice the pattern and will prefetch to reduce cache miss latency. But a high allocation rate will use a lot of memory bandwidth and would thrash the caches.

An extreme case of that problem happens when using GC in an app that gets swapped out. Performance drops to virtually zero then.

Re: Why Discord is switching from Go to Rust

#634

Post by pkolaczk »

ernst_klim wrote: post #585
1propionyl wrote: post #550

Earlier quoted context omitted.

True, but it's generally better than most full GC solutions (for processes running for relatively short times without the benefit of profile-guided optimization), and worse than languages with fully statically analyzable memory usage. Note: that parenthetical is a very big caveat, because properly profile-optimized JVM executables can often achieve exceptional performance/development cost tradeoffs. In addition howev…

> but it's generally better than most full GC solutions I doubt that. It implies huge costs without giving any benefits of GC. A typical GC have compaction, nearly stack-like fast allocation [1], ability to allocate a bunch of objects at once (just bump the heap pointer once for a whole bunch). And both Perl and Swift do indeed perform abysmally, usually worse than both GC and manual languages [2]. > ARC is more of l…

It is nowhere near stack-like. Stack is hot in cache. Heap memory in tlab is cold. Bringing the lines into cache is the major cost, not bumping the pointer.

Re: Why Discord is switching from Go to Rust

#635

Post by pkolaczk »

barrkel wrote: post #580
arcticbull wrote: post #532

Earlier quoted context omitted.

Apple's ARC is not a GC in the classic sense. It doesn't stop the world and mark/sweep all of active memory. It's got "retain" and "release" calls automatically inserted and elided by the compiler to track reference counts at runtime, and when they hit zero, invoke a destructor. That's not even close to what most people think of when they think "gc". Of course it's not free, but it's deterministic.

You're using a hearsay, folklore definition of GC, not a CS one. Refcounting in the presence of threads is usually non-deterministic too.

It is non deterministic, but at a much different scale.

Re: Why Discord is switching from Go to Rust

#636

Post by squarefoot »

robocat wrote: post #367
squarefoot wrote: post #325

Earlier quoted context omitted.

3x might be a bit too much today, but it's definitely slower than C. Also to be considered is the VM overhead, not just the executed code. Here are some benchmarks; I'll leave to the experts out there to confirm or dismiss them. https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

However the memory usage difference is astonishing for some of those benchmarks - using 1000x more memory is only acceptable for some situations.

Agreed, and ironically the most widely used Java platform (Android), despite its VM optimizations, is the one which would benefit the most from running only native code.

I mean, those 1GB RAM 7 years old slow as molasses phones getting dust into drawers or being littered into landfills would scream if they didn't have to run everything behind a VM.

Re: Why Discord is switching from Go to Rust

#637

Post by pjmlp »

marcosdumay wrote: post #629
pjmlp wrote: post #609

Earlier quoted context omitted.

That is what MS is doing with C#/F# and .NET Native/Xamarin AOT/CoreRT, with the experience taken from Midori. So I doubt they would sponsor D.

C# is an attempt of making Java good, F# is an attempt of making a subset of Haskell popular. .Net Native/Xamarin/CoreRT are UI frameworks. There is nothing there that would compete with C++. I don't think MS has any interest in improving C++ (look at their compiler). But that's not because of competing activities.

Except the lessons learned from Midori and .NET Native on UWP.

Visual C++ is the best commercial implementation of C++ compilers, better not be caught using xlc, aCC, TI, IAR, icc and plenty of other commercial offerings.

If C++ has span, span_view, modules, co-routines, core guidelines, lifetime profile static analyser, is it in large part to work started and heavily contributed by Microsoft on ISO, and their collaboration with Google.

As for competing with C++, it is quite clear, specially when comparing the actual software development landscape with the 90's, that C++ has lost the app development war.

Nowadays across all major consumer OSes it has been relegated to the drivers and low level OS services layer like visual compositor, graphics engine, GPGPU binding libraries.

Ironically, from those mainstream OSes, Microsoft is the only one that still cares to provide two UI frameworks directly callable from C++.

Which most Windows devs end up ignoring in favour of the .NET bindings, as Kenny Kerr mentions in one of his talks/blog posts.

Back to the D issue, Azure IoT makes use of C# and Rust, and there is Verona at MSR as well, so as much I would like to see them spend some effort on D, I don't see it happening.

Re: Why Discord is switching from Go to Rust

#638

Post by spullara »

mappu wrote: post #376
spullara wrote: post #58

Earlier quoted context omitted.

Heap caches that keep things longer than a GC cycle are terrible under GC unless you have a collector in the new style like ZGC, Azul or Shenandoah.

What feature of "the new style" makes them more suitable in this case?

They have very short pause times even for very large heaps with lots of objects in them as they don't have to crawl the entire live tree when collecting.

Re: Why Discord is switching from Go to Rust

#639

Post by Kuinox »

marcosdumay wrote: post #629
pjmlp wrote: post #609

Earlier quoted context omitted.

That is what MS is doing with C#/F# and .NET Native/Xamarin AOT/CoreRT, with the experience taken from Midori. So I doubt they would sponsor D.

C# is an attempt of making Java good, F# is an attempt of making a subset of Haskell popular. .Net Native/Xamarin/CoreRT are UI frameworks. There is nothing there that would compete with C++. I don't think MS has any interest in improving C++ (look at their compiler). But that's not because of competing activities.

CoreRT is an UI frameworks, what ?

Re: Why Discord is switching from Go to Rust

#640

Post by cryptos »

bcrosby95 wrote: post #360
marcosdumay wrote: post #328

Earlier quoted context omitted.

Those people have a really good claim to have the most optimized choice on each language. They've found Java to be 2 to 3 times slower than C and Rust (with much slower outliers). https://benchmarksgame-team.pages.debian.net/benchmarksgame/... On the real world, you won't get things as optimized in higher level languages, because optimized code looks completely unidiomatic. A 3x speedup from Java is a pretty normal c…

Speaking of, I wish there were an "idiomatic code benchmarks game". Some of us want to compare language speed for common use cases vs trying to squeeze every last piece of performance from it.

There is a lot more than the language/compiler what influences the results, but at least these benchmarks are closer to real world than solving math puzzles in micro benchmarks.

https://www.techempower.com/benchmarks/

Post reply on HN