5 ms·

Isn’t this inevitable if the user allocates each time a struct/array is created, rather than allocating upfront?

masklinn 3y ago
Meh. Users not used to tracking allocations keep to the same regime (lots of allocations), but because the platform allocators are utterly terrible the allocation overhead is orders of magnitude higher than in even a relatively basic runtime, thus the program is dog slow. This is not inevitable, platforms could provide allocators which are less awful. Obviously they can’t be as fast as specialised runtime facilities but when you see the gains many applications get by just swapping in jemalloc or some such…
- PH95VuimJjqBqy 3y ago
  I would simplify it and say it's an issue with developers who don't understand manual memory management (allocating memory pools up front is just 1 such strategy for manual memory management).
  - masklinn 3y ago
    That’s not a simplification, that’s a misattribution. It’s not the beginner’s fault that most system allocators suck so hard you must do your utmost to limit their use.
    - hinkley 3y ago
      Otherwise known as Victim Blaming. C developers are that old guy who white knuckles everything and calls people weak for wanting help. Many of the features in modern programs didn’t exist in the 90’s not because they hadn’t been thought of but because people spent all their energy getting the first fifty features to work reliably. Every app had a couple cool features. Most of them are de rigeur now because we can.
    - PH95VuimJjqBqy 3y ago
      This is akin to the idea that a compiler will eventually solve performance problems. We're still waiting on that to happen. There's a difference between a developer who understands manual memory management choosing to use a tech that does it for you and a developer choosing to use a tech that does it for you so they don't have to learn manual memory management. manual memory management is table stakes for any halfway competent developer.
- wongarsu 3y ago
  Rust used to use jemalloc, which was arguably the better default. For some reason they switched it to the system allocator when they added support for specifying the global allocator
  - steveklabnik 3y ago
    jemalloc was not the default on every platform, but was on some. It adds a non-trivial amount of binary size to every program, even ones that don't need the performance boost, and that is an area Rust is often criticized vs C. That said, there are a few reasons beyond just that. For the primary sources: https://github.com/rust-lang/rust/issues/36963 https://github.com/rust-lang/rust/issues/36963
- forrestthewoods 3y ago
  > the platform allocators are utterly terrible the allocation overhead is orders of magnitude higher than in even a relatively basic runtime, thus the program is dog slow Huh. I’ve seen lots of people write slow Rust code because they didn’t realize there were allocations. But the complaint is usually “my rust program is only 5x faster than my equivalent python program instead of 100x how come”? Can you point out some good blog posts about Rust or C++ being slower than a “basic runtime” due to inferior allocator?
- hinkley 3y ago
  If rust isn’t doing escape analysis for stack vs heap allocation then what is even the fucking point of this language? I would have thought that was the first thing implemented.
  - vlovich123 3y ago
    Rust doesn’t allocate anything on the heap unless you tell it to. When you tell it too, it puts it on the heap. The target use case is as a systems language. Escape analysis as you’re alluding to isn’t needed in this model because the amount of times this helps you (ie you put it on the heap but the compiler can figure out it can live on the stack) is about 0. You need escape analysis in managed memory languages where everything is nominally a heap allocation and the compiler is responsible for clawing back performance through escape analysis.

Meh. Users not used to tracking allocations keep to the same regime (lots of allocations), but because the platform allocators are utterly terrible the allocation overhead is orders of magnitude higher than in even a relatively basic runtime, thus the program is dog slow. This is not inevitable, platforms could provide allocators which are less awful. Obviously they can’t be as fast as specialised runtime facilities but when you see the gains many applications get by just swapping in jemalloc or some such…

PH95VuimJjqBqy 3y ago
I would simplify it and say it's an issue with developers who don't understand manual memory management (allocating memory pools up front is just 1 such strategy for manual memory management).
- masklinn 3y ago
  That’s not a simplification, that’s a misattribution. It’s not the beginner’s fault that most system allocators suck so hard you must do your utmost to limit their use.
  - hinkley 3y ago
    Otherwise known as Victim Blaming. C developers are that old guy who white knuckles everything and calls people weak for wanting help. Many of the features in modern programs didn’t exist in the 90’s not because they hadn’t been thought of but because people spent all their energy getting the first fifty features to work reliably. Every app had a couple cool features. Most of them are de rigeur now because we can.
  - PH95VuimJjqBqy 3y ago
    This is akin to the idea that a compiler will eventually solve performance problems. We're still waiting on that to happen. There's a difference between a developer who understands manual memory management choosing to use a tech that does it for you and a developer choosing to use a tech that does it for you so they don't have to learn manual memory management. manual memory management is table stakes for any halfway competent developer.
wongarsu 3y ago
Rust used to use jemalloc, which was arguably the better default. For some reason they switched it to the system allocator when they added support for specifying the global allocator
- steveklabnik 3y ago
  jemalloc was not the default on every platform, but was on some. It adds a non-trivial amount of binary size to every program, even ones that don't need the performance boost, and that is an area Rust is often criticized vs C. That said, there are a few reasons beyond just that. For the primary sources: https://github.com/rust-lang/rust/issues/36963 https://github.com/rust-lang/rust/issues/36963
forrestthewoods 3y ago
> the platform allocators are utterly terrible the allocation overhead is orders of magnitude higher than in even a relatively basic runtime, thus the program is dog slow Huh. I’ve seen lots of people write slow Rust code because they didn’t realize there were allocations. But the complaint is usually “my rust program is only 5x faster than my equivalent python program instead of 100x how come”? Can you point out some good blog posts about Rust or C++ being slower than a “basic runtime” due to inferior allocator?
hinkley 3y ago
If rust isn’t doing escape analysis for stack vs heap allocation then what is even the fucking point of this language? I would have thought that was the first thing implemented.
- vlovich123 3y ago
  Rust doesn’t allocate anything on the heap unless you tell it to. When you tell it too, it puts it on the heap. The target use case is as a systems language. Escape analysis as you’re alluding to isn’t needed in this model because the amount of times this helps you (ie you put it on the heap but the compiler can figure out it can live on the stack) is about 0. You need escape analysis in managed memory languages where everything is nominally a heap allocation and the compiler is responsible for clawing back performance through escape analysis.