13

According to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html vector<uint64>::operator[] is between 2% and 70% faster in EASTL than a "commonly used commercial version of STL".

Unless the commercial version of STL uses range checking, which would make the comparison unfair, how can it possibly be such a speed difference for such a simple operation?

Update:

Seems the answer is that the EA engineers is simply cheating by comparing with a version which uses range checking...

Viktor Sehr
  • 12,172
  • 3
  • 52
  • 78

2 Answers2

8

The document states that they used VC++ 2005 for Windows testing, with which checked iterators are enabled by default (yes, even for release builds; same goes for VC++ 2008). I suspect that the performance of operator[] wouldn't be any different if they added -D_SECURE_SCL=0 to their build command-line.

ildjarn
  • 59,718
  • 8
  • 115
  • 201
  • wouldn't make a difference as `vector<...>::operator[]` is implemented as `{return (*(this->_Myfirst + _Pos));}` i.e no iterators involved. – Viktor Sehr Apr 21 '11 at 10:47
  • @Viktor Sehr : That's the code that's executed when `_SECURE_SCL` is `#define`d to `0`. When `_SECURE_SCL` = `1`, as is the default, substantially different code is run. (Also note that the STL implementation in VC++ 2010 is vastly different than that in VC++ 2005 and 2008, so looking at 2010's implementation is not relevant here.) – ildjarn Apr 21 '11 at 10:53
  • @bruce.banner : In VC++ 2010, checked iterators are disabled by default for release builds. I.e., they're still available, but you have to enable them manually. – ildjarn Apr 23 '11 at 19:03
4

I think this passage from the documentation will be crucial

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#eastl_allocator

It is apparently inspired by the famous 'Towards a better allocator model' article by Pablo Halpern

sehe
  • 328,274
  • 43
  • 416
  • 565
  • 4
    How would a better allocator affect `operator[]`? – sharptooth Apr 21 '11 at 10:23
  • 2
    Apparently their allocator takes into consideration alignment requirements and this could make access to specific locations a lot faster using specific access patterns. However, AFAICT their precise benchmark method is not published (on the same page) – sehe Apr 21 '11 at 10:26