Why Discord is switching from Go to Rust

Post by barrkel » Wed, Feb 05, 2020, 10:42 AM UTC

thu2111 wrote: post #561

the_duke wrote: post #442

Earlier quoted context omitted.

VMs with JIT like the JVM are only ever really fast/competitive with C in small numerical micro-benchmarks where the code can be hyper-optimized. Most code will be considerably slower due to a lot of factors. Java in particular is a very pointer-heavy language, made up of pointers to pointers to pointers everywhere, which is really bad for our modern systems that often are much more memory latency than CPU constraine…

This stuff is really hard to pin down though. I've been reading these sorts of debates forever. It's true that pointer chasing really hurts in some sorts of program and benchmark. For sure. No argument. That's why Project Valhalla exists. But it's also my view that modern C++ programming gets away with a lot of slow behaviours that people don't really investigate or talk about because they're smeared over the program…

Post by toxicafunk » Wed, Feb 05, 2020, 11:32 AM UTC

cft wrote: post #543

the-alchemist wrote: post #96

Looks like the big challenge is managing a large, LRU cache, which tends to be a difficult problem for GC runtimes. I bet the JVM, with its myriad tunable GC algorithms, would perform better, especially Shenandoah and, of course, the Azul C4. The JVM world tends to solve this problem by using off-heap caches. See Apache Ignite [0] or Ehcache [1]. I can't speak for how their Rust cache manages memory, but the thing to…

> From a purely architectural perspective, I would try to put cacheable material in something like memcache or redis You cannot use a caching server at that scale with those latency requirements. It has to be embedded

Post by ernst_klim » Wed, Feb 05, 2020, 11:40 AM UTC

1propionyl wrote: post #550

dgellow wrote: post #320

Earlier quoted context omitted.

ARC, used by Swift, has its own cost.

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…

Post by _ph_ » Wed, Feb 05, 2020, 12:10 PM UTC

pkolaczk wrote: post #576

_ph_ wrote: post #264

Earlier quoted context omitted.

In this case, as they were running into the automatic GC interval, their program did not create much, if any garbage. So the CPU overhead for the GC would have been quite small. If you do a lot of allocations, the GC overhead rises of course, but also would the effort of doing allocations/deallocations with a manual managing scheme. In the end it is a bit trade-off, what fits the problem at hand best. The nice thing…

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.

Post by nuclx » Wed, Feb 05, 2020, 12:14 PM UTC

loeg wrote: post #142

mister_hn wrote: post #119

Why not C++, if performance was an issue?

Why would you pick C++ for a new codebase in 2019 or 2020 if Rust met your needs?