5 ms·
Not the OP, but my guess is that rust will do well for the sort of code that would be fast in c anyway: linear operations large, contiguous arrays. For pointer
by moonchild 6y ago
Not the OP, but my guess is that rust will do well for the sort of code that would be fast in c anyway: linear operations large, contiguous arrays. For pointer-chasing code, or code with lots of small objects, the little tricks you use in c aren't available (or at least, not as accessible), and the lack of gc and flexibility wrt references harms you.
- rcxdude 6y agoCode with lots of small short-lived objects is often by default faster in something like rust, because stack allocation is very efficient (even compared to the bump allocation in a generational GC, which is much more efficient than heap allocation but worse than stack). If you have a lot of objects which can exist on the stack in your program, java will tend to do poorly in comparison. (and in general java will trade off memory for speed: modern GCs can be very efficient in execution time but will use 2x-3x as much memory in return. If you want low memory usage your code is going to run slower).
- mratsim 6y agoDoes the borrow checker interfere with memory and object pools implementation? Because if you require heap allocation for many short-lived objects, I expect this would be one of Java strengths unless you use an object pool.
- steveklabnik 6y ago"interfere" is a funny word, but you could do this in Rust. It's not super common, though the related technique of "arenas" can be, depending on domain.