Alvaro Martin

Atentos a std::move :)

http://blogs.msdn.com/b/vcblog/archive/2009/06/23/stl-performance.aspx

El post habla por si solo. Simplemente tenía curiosidad por saber que había por Google sobre las STL, ya que a mi parecer aunque son Thread Safe, son lentas como contenedores. Depende de con que lo compares son extremadamente rápidas claro. Pero no hay nada como una clase Array con las funciones necesarias. Se nota el aumento de rendimiento pero claro, las STL son diseñadas para un propósito general. La duda me asaltó cuando vi en una issue de la librería de física Bullet, un parche subido con contenedores STL y alguien dijo que el uso de las STL en Bullet era totalmente inaceptable :D y claro… si buscas optimización… tiene toda la razón.

No obstante no creo que las STL sean una mala librería, para nada, pero en el mundo del programador de C/C++ nos gusta bastante optimizarlo todo, yo al menos soy bastante friki con estos temas, no como desearía pero lo soy. Con decir que me he llevado 10 años con un PC AMD Athlon XP 1500+ 640MB de memoria y programé ahí mi implementación del Deferred Rendering… xD y siempre ejecutaba todo en DEBUG, si iba mal en debug tocaba iteración de profiling y optimización.

Me encanta C/C++, si bien es cierto que como siempre digo tienes toda la cuerda para hacer lo que quieras, absolutamente todo, pero también tienes la misma cuerda para ahorcarte.

Estoy empezando a usar COLLADA, investigar, implementarlo en mi motor etc. He dado con una curiosidad en el foro de OpenCOLLADA y es que parece ser que OpenCOLLADA presume de ser el exportador / importador más optimo que existe con mucha diferencia, según los videos de youtube parece que tienen razón, pero yo aun tengo que hacer mis pruebas y sacar mis conclusiones usando 3ds Max 2011.

AutoDesk COLLADA 30 segundos

OpenCOLLADA 10 segundos

No obstante parece que tienen obsesión por adelantarse al compilador o intentar saber más que él. ¿Por qué digo esto? bueno hay ciertas macros de las STL para tener información de debug cuando el programa falla, esto provoca que se haga un “check” de ciertas cosas que obviamente consume CPU. La macro en discordia es _HAS_ITERATOR_DEBUGGING y desarrolladores que lo usan están recomendando el asignar esa macro a cero. Esta macro es bastante básica así que estaba seguro que debía estar incluida en las opciones de compilación del Visual Studio, en concreto /O2, que permite aumentar la velocidad del código en detrimento de información de Debug, cosa que en modo Release no hace falta. Así fue, en un post de Microsoft confirma que esa variable es auto-asignada con el modo de compilación /O2 por medio de otra macro mucho más interesante que la anterior, _SECURE_SCL.

Supongo que cuando a alguien le dio algún error en el código iterando por un vector u otro contenedor de las STL vio esa macro y quiso investigar, seguramente la definió en el proyecto en modo Debug y vio que el rendimiento general de la aplicación aumentó muchísimo. Yo creo que hay que tener bastante precaución con estas cosas, sobre todo y normalmente cuando asignamos las propiedades correctas en el compilador debemos fiarnos de que el equipo de programación es capaz de optimizar más y mejor con una opción que nosotros experimentando.

If you download the last version of freeglut (2.6.0) in theory haves support for Windows 7, yes, compile and link well but when you try to write any message in the window appear japanese symbols etc… :D Continue reading →

Some thing to remeber… the clean way is ZOOM_STATE = not ZOOM_STATE

1
2
3
4
5

local ZOOM_STATE = true
 
ZOOM_STATE = (ZOOM_STATE ~= ZOOM_STATE)  -- the same of not ZOOM_STATE
ZOOM_STATE = not ZOOM_STATE; print(ZOOM_STATE)
ZOOM_STATE = not ZOOM_STATE; print(ZOOM_STATE)