3 ms·

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shri

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."

jstimpfle 8y ago
> Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...
- jstimpfle 8y ago
  > string-to-hash map string-to-int hash map
dralley 8y ago
Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.
- jstimpfle 8y ago
  The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.
lbrandy 8y ago
"zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message. As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).

jstimpfle 8y ago

> Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...

jstimpfle 8y ago
> string-to-hash map string-to-int hash map

dralley 8y ago

Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.

jstimpfle 8y ago
The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.

lbrandy 8y ago

"zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message. As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).