5 ms·

Why do people write their own memory allocators and put them in production software for modern desktop applications? It's not like you can eek that much more pe

Why do people write their own memory allocators and put them in production software for modern desktop applications? It's not like you can eek that much more performance out, and the steam client is already fairly buggy. Switching the views is slow, and doesn't always work.

tptacek 8y ago
The system allocator is tuned for general purpose workloads. If you know something specific about your workload, like size or frequency or lifetime, you can do better, and sometimes "better" means "by a lot". It's not like a heap overflow wouldn't have been a big deal otherwise, for what it's worth.
- asfasgasg 8y ago
  Do you really think this is why, though? It's hard to picture Steam the application being performance sensitive.
  - pvg 8y ago
    There's voice chat, a couple of different streaming doodads, other real-timey social features.
  - ManlyBread 8y ago
    It used to work really bad on low-end machines.
newnewpdro 8y ago
It's not like the bug was in their allocator, which sounds like nothing more than a free list of small fixed size objects sliced from larger chunks allocated using the system allocator. That's not a complicated thing, and it can have a significant performance impact.
jchw 8y ago
The easiest way to explain it is to go backwards and ask if a one-size-fits-all allocator can really be optimal for most of its users. The answer is probably no. At the very least, most software that has a lot of memory churn could benefit from trying to reuse memory before going down to the allocator. When it comes to particular kinds of objects, like strings, it is very clear that you can have enormous performance benefits from relatively small tweaks.
mastax 8y ago
Valve is a games company. They probably already had a stable of allocators and were used to that kind of programming. Also the Windows malloc was much slower in 2003 IIRC.
- tejasmanohar 8y ago
  I'm guessing it's more this. I can't imagine the Steam app demands that high performance.
  - kbenson 8y ago
    Well, since steam is in the background during all the games launched from it, often allows a special video overlay to browse community features while the game is running, supports chat, has an embedded browser, and can be used as an operating system overlay so you don't even have to use the OS for most things (big picture mode, for dedicated use and control with a game controller), I can imagine they probably want to make sure whatever allocator and reclamation scheme they are using has very low and predictable latency. The last thing they want to have to deal with is people reporting how running the game through steam costs a non-negligible amount of performance, or causes weird occasional lags/stalls while playing. In that respect, it's an extremely high performance application, in that it needs to be nigh unnoticeable to the type of people that overclock systems, push their graphics cards to their limits, and play games with FPS counters always showing in the corner. In that respect, it may be a textbook case of an application where you want a very specific memory allocation scheme that falls within very strict performance guidelines.
    - baud147258 8y ago
      In addition to the community features while the game is running, the Steam client has to support the screenshot and broadcast functionnalities
    - Something1234 8y ago
      It already has a large number of performance issues. The store is slow to open, and it's slow to switch to my library. Even slower to view my inventory.
xenadu02 8y ago
Why people compile without stack cookies, ASLR, or any other mitigations is another mystery. Writing your own protocol and/or memory allocator without fuzzing either is also highly dubious.
nitwit005 8y ago
Re-using buffers, and only falling back to normal allocations for large sizes is fairly normal in networking code. You see the same strategy used in code for reading things like HTTP requests, in just about every language. For example, Googling "Jetty buffer reuse" immediately popped up their ByteBufferPool class: https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/io/ByteBufferPool.html https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/ec...

tptacek 8y ago

The system allocator is tuned for general purpose workloads. If you know something specific about your workload, like size or frequency or lifetime, you can do better, and sometimes "better" means "by a lot". It's not like a heap overflow wouldn't have been a big deal otherwise, for what it's worth.

asfasgasg 8y ago
Do you really think this is why, though? It's hard to picture Steam the application being performance sensitive.
- pvg 8y ago
  There's voice chat, a couple of different streaming doodads, other real-timey social features.
- ManlyBread 8y ago
  It used to work really bad on low-end machines.

newnewpdro 8y ago

It's not like the bug was in their allocator, which sounds like nothing more than a free list of small fixed size objects sliced from larger chunks allocated using the system allocator. That's not a complicated thing, and it can have a significant performance impact.

jchw 8y ago

The easiest way to explain it is to go backwards and ask if a one-size-fits-all allocator can really be optimal for most of its users. The answer is probably no. At the very least, most software that has a lot of memory churn could benefit from trying to reuse memory before going down to the allocator. When it comes to particular kinds of objects, like strings, it is very clear that you can have enormous performance benefits from relatively small tweaks.

mastax 8y ago

Valve is a games company. They probably already had a stable of allocators and were used to that kind of programming. Also the Windows malloc was much slower in 2003 IIRC.

tejasmanohar 8y ago
I'm guessing it's more this. I can't imagine the Steam app demands that high performance.
- kbenson 8y ago
  Well, since steam is in the background during all the games launched from it, often allows a special video overlay to browse community features while the game is running, supports chat, has an embedded browser, and can be used as an operating system overlay so you don't even have to use the OS for most things (big picture mode, for dedicated use and control with a game controller), I can imagine they probably want to make sure whatever allocator and reclamation scheme they are using has very low and predictable latency. The last thing they want to have to deal with is people reporting how running the game through steam costs a non-negligible amount of performance, or causes weird occasional lags/stalls while playing. In that respect, it's an extremely high performance application, in that it needs to be nigh unnoticeable to the type of people that overclock systems, push their graphics cards to their limits, and play games with FPS counters always showing in the corner. In that respect, it may be a textbook case of an application where you want a very specific memory allocation scheme that falls within very strict performance guidelines.
  - baud147258 8y ago
    In addition to the community features while the game is running, the Steam client has to support the screenshot and broadcast functionnalities
  - Something1234 8y ago
    It already has a large number of performance issues. The store is slow to open, and it's slow to switch to my library. Even slower to view my inventory.

xenadu02 8y ago

Why people compile without stack cookies, ASLR, or any other mitigations is another mystery. Writing your own protocol and/or memory allocator without fuzzing either is also highly dubious.

nitwit005 8y ago

Re-using buffers, and only falling back to normal allocations for large sizes is fairly normal in networking code. You see the same strategy used in code for reading things like HTTP requests, in just about every language. For example, Googling "Jetty buffer reuse" immediately popped up their ByteBufferPool class: https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/eclipse/jetty/io/ByteBufferPool.html https://www.eclipse.org/jetty/javadoc/9.4.8.v20171121/org/ec...