5 ms·

also what a deque (C++) does

by cobalt 4y ago

pencilguin 4y ago
True... except in MSVC. std::deque in MSVC is cursed. Targeting MSVC, use boost::deque or something, instead. Boost containers are generally fairly good, although they are more or less unmaintained nowadays. (E.g., boost::unordered_map::reserve doesn't work.) Or, like many of us, ignore performance on MS targets because anybody who cares about performances is running something else.
- q-big 4y ago
  Why?
  - pencilguin 4y ago
    https://github.com/AcademySoftwareFoundation/openvdb/issues/1350 https://github.com/AcademySoftwareFoundation/openvdb/issues/... Longer answer is that the size of the "blocks" is limited to 512 bytes or one element, whichever is larger. So unless your elements are really tiny, it is strictly a pessimization.
- cyber_kinetist 4y ago
  Many of the STL containers in MSVC are incredibly cursed. Even std::vector is implemented in such a weird way, that you can't debug it easily with any debugger other than Visual Studio. And it's incredibly slow on Debug mode, up to the point that it's unusable... (Because of these reasons I just switched to using my own Vector<T> class recently) I think there's a very good reason why old gamedevs who were stuck with developing on Windows largely ignored the STL and made their own containers / utility functions: MSVC's STL was just awful.
  - brantonb 4y ago
    I always wondered why we weren’t allowed to use the STL in the Windows division in the 00’s. This probably explains it.
    - pencilguin 4y ago
      There was a lot of BS, as well. It is impossible to tease out which was what.
  - simplotek 4y ago
    > Many of the STL containers in MSVC are incredibly cursed. Even std::vector is implemented in such a weird way, that you can't debug it easily with any debugger other than Visual Studio. And it's incredibly slow on Debug mode, up to the point that it's unusable... (Because of these reasons I just switched to using my own Vector<T> class recently) Here's a link to an old HN discussion that offers some insight on the performance of MSVC's STL in debug. https://news.ycombinator.com/item?id=18939260 https://news.ycombinator.com/item?id=18939260 The "cursed" keyword hand-waves over the problem and suggests it originates in the acritical propagation of ignorant beliefs. Sometimes clarifying these is just a Google search away.
    - cyber_kinetist 4y ago
      Yes, I know that already. And good luck with dealing all the linker/ABI issues from changing that setting.
- ahtihn 4y ago
  > ignore performance on MS targets because anybody who cares about performances is running something else. That's a strange take. Surely games still represent a significant chunk of the demand for C++ developers that need to care about performance?
  - pencilguin 4y ago
    Thus, "many". Game coders would not be among those.

also what a deque (C++) does

by cobalt 4y ago

also what a deque (C++) does

True... except in MSVC. std::deque in MSVC is cursed. Targeting MSVC, use boost::deque or something, instead. Boost containers are generally fairly good, although they are more or less unmaintained nowadays. (E.g., boost::unordered_map::reserve doesn't work.) Or, like many of us, ignore performance on MS targets because anybody who cares about performances is running something else.

q-big 4y ago
Why?
- pencilguin 4y ago
  https://github.com/AcademySoftwareFoundation/openvdb/issues/1350 https://github.com/AcademySoftwareFoundation/openvdb/issues/... Longer answer is that the size of the "blocks" is limited to 512 bytes or one element, whichever is larger. So unless your elements are really tiny, it is strictly a pessimization.
cyber_kinetist 4y ago
Many of the STL containers in MSVC are incredibly cursed. Even std::vector is implemented in such a weird way, that you can't debug it easily with any debugger other than Visual Studio. And it's incredibly slow on Debug mode, up to the point that it's unusable... (Because of these reasons I just switched to using my own Vector<T> class recently) I think there's a very good reason why old gamedevs who were stuck with developing on Windows largely ignored the STL and made their own containers / utility functions: MSVC's STL was just awful.
- brantonb 4y ago
  I always wondered why we weren’t allowed to use the STL in the Windows division in the 00’s. This probably explains it.
  - pencilguin 4y ago
    There was a lot of BS, as well. It is impossible to tease out which was what.
- simplotek 4y ago
  > Many of the STL containers in MSVC are incredibly cursed. Even std::vector is implemented in such a weird way, that you can't debug it easily with any debugger other than Visual Studio. And it's incredibly slow on Debug mode, up to the point that it's unusable... (Because of these reasons I just switched to using my own Vector<T> class recently) Here's a link to an old HN discussion that offers some insight on the performance of MSVC's STL in debug. https://news.ycombinator.com/item?id=18939260 https://news.ycombinator.com/item?id=18939260 The "cursed" keyword hand-waves over the problem and suggests it originates in the acritical propagation of ignorant beliefs. Sometimes clarifying these is just a Google search away.
  - cyber_kinetist 4y ago
    Yes, I know that already. And good luck with dealing all the linker/ABI issues from changing that setting.
ahtihn 4y ago
> ignore performance on MS targets because anybody who cares about performances is running something else. That's a strange take. Surely games still represent a significant chunk of the demand for C++ developers that need to care about performance?
- pencilguin 4y ago
  Thus, "many". Game coders would not be among those.