4 ms·

Interesting, could you elaborate on this software and what it does? At work, we also offer two backends for the same kind of functionality. One is the industry

by doteka 6y ago

Interesting, could you elaborate on this software and what it does? At work, we also offer two backends for the same kind of functionality. One is the industry standard Java implementation, one is a homegrown Rust implementation. We find that for this usecase (essentially text processing, string manipulation and statistical algorithms), the rust version is much faster while using less memory. However, it is not as feature-rich.

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 ago
  Code 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 ago
    Does 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.
deleted 6y ago
[deleted]

by doteka 6y ago

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 ago
Code 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 ago
  Does 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.

deleted 6y ago

[deleted]