Re:Writing Pythonic Rust
by throwaway894345 on Tuesday May 25, 2021 @01:29PM
(#27279725)
> Yes, a GC intrinsically incurs an integer factor performance cost for many codes relative to e.g. optimized C++ (I’ve optimized both)
I'm guessing this performance difference isn't caused by GC but rather correlated with GC. I.e., GC langs tend to output relatively poorly-optimized code relative to the absolute beastly C/C++/Rust compilers or else idiomatic code results in objects scattered all over the heap (killing cache coherency) while idiomatic C, C++, Rust, etc tend to allocate coherent objects (objects which tend to be accessed in succession) next to each other in memory.
TL;DR: No doubt a GC can be slower than manually managed memory in some cases, but it's insufficient to conclude that the entire performance gap between C/C++/Rust and Java/Go/etc is attributable to GC.
Re:Writing Pythonic Rust
by jandrewrogers on Wednesday May 26, 2021 @01:48AM
(#27286840)
No, there are major classes of macro-optimizations that are impossible to implement with a GC even in theory. Some of these optimizations are idiomatic for state-of-the-art systems code. The impact on performance is integer factor.
tl;dr: there are significant GC performance problems that a borrow-checker doesn’t solve. I can imagine cases where the performance improvement is significantly less than you might hope.