2011-04-21 15 views
13

Según http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html vector<uint64>::operator[] es entre 2% y 70% más rápido en EASTL que una "versión comercial comúnmente usada de STL ".EASTL frente STL, ¿cómo puede haber una diferencia de rendimiento en std :: vector <uint64_t> :: operador []

A menos que la versión comercial de STL utilice la comprobación de rango, lo que haría la comparación injusta, ¿cómo puede ser una diferencia de velocidad tan alta para una operación tan simple?

Actualización:

parece que la respuesta es que los ingenieros de EA es simplemente engañando mediante la comparación con una versión que utiliza la verificación del rango ...

Respuesta

8

El documento indica que utilizaron VC++ 2005 para pruebas de Windows, con el cual checked iterators son enabled by default (sí, incluso para compilaciones de versiones; lo mismo vale para VC++ 2008). Sospecho que el rendimiento de operator[] no sería diferente si agregaron -D_SECURE_SCL=0 a su línea de comandos de compilación.

+0

no haría la diferencia ya que 'vector <...> :: operator []' se implementa como '{return (* (this -> _ Myfirst + _Pos)) ;} 'es decir, no hay iteradores involucrados. –

+0

@Viktor Sehr: Ese es el código que se ejecuta cuando '_SECURE_SCL' es' # define'd a '0'. Cuando '_SECURE_SCL' =' 1', como es el predeterminado, se ejecuta un código sustancialmente diferente. (También tenga en cuenta que la implementación de STL en VC++ 2010 es muy diferente a la de VC++ 2005 y 2008, por lo que mirar la implementación de 2010 no es relevante aquí.) – ildjarn

+0

¿Qué pasa con VS2010? –

4

creo que este pasaje de la documentación será crucial

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

al parecer, está inspirado en el famoso 'Hacia una mejor asignador modelo' artículo de Pablo Halpern

+4

¿Cómo afectaría un mejor asignador 'operador []'? – sharptooth

+2

Aparentemente, su asignador tiene en cuenta los requisitos de alineación y esto podría hacer que el acceso a ubicaciones específicas sea mucho más rápido utilizando patrones de acceso específicos. Sin embargo, AFAICT su método de punto de referencia preciso no está publicado (en la misma página) – sehe

Cuestiones relacionadas