Que se lo digan a Michael Abrash  :twisted:

Abrash estaría de acuerdo conmigo probablemente. A diferencia de muchos programadores, Abrash no solo sabe muy bien assembler y las arquitecturas sino que además es muy bueno seleccionando y creando algoritmos. Además los proyectos en los que él trabaja (como Pixomatic) requieren tanta performance del CPU que es sumamente necesario elegir o crear los algoritmos más efectivos y optimizar el assembler al máximo. Abrash debe ser uno de los programadores más talentosos con los que he podido intercambiar información.

Se dará cuenta el compilador que solo es un int que quiero tratar diferente?
Hará las optimizaciones necesarias, como por ejemplo alojarlo en un registro para calculos sucesivos o para pasarlo a una función y todas esas cosas?

Depende del compilador, vas a tener que mirar el assembler generado por tu compilador para determinar eso.

He visto que los procesadores de hoy en dia trabajan con el stack en la l2 igual de rapido que con los registros.
Ya no deberia preocuparme entonces por esto?

Saludos y gracias

Hmm, no se a que te réferis con esto. Ningún tipo de arquitectura que yo conozca permite trabajar con el L2 directamente (por lo menos no es el caso en los x86, el Xenon o el Cell) y el costo de subir información del L2 al L1 depende de la arquitectura pero generalmente ronda los 40 ciclos. La realidad es que en general no te tendrías que preocupar por eso, en todo caso antes de preocuparte hace profiling y determina si realmente es un problema o no. Yo personalmente me canso de ver programadores hacerse problema por el assembler generado por el compilador cuando los problemas de performance que tienen 99% de las veces están relacionados con los algoritmos en sí.

1ra pregunta.
¿Si solamente estaré haciendo esto, se puede linkear la aplicación como single-thread?

Depende de cómo uses la run-time library y el compilador que uses. Mira la documentación de tu compilador.

2da pregunta.
¿Que overhead hay en las librerias standarts de C en su versión multi-threading?

Depende de lo que uses. En general a no ser que estés dispuesto a escribir la librería de nuevo, no es algo que realmente este en tus manos. De lo contrario, hace profiling antes de empezar a preocuparte por un problema que capaz que ni existe.

3ra pregunta.
¿Donde mas puede haber problemas?

Hay varios problemas más como false sharing (dos variables totalmente diferentes terminan en una misma línea de cache), falta de memory barriers (el CPU o compilador puede reordenar operaciones de lectura/escritura cuando el orden puede ser crítico, se resuelve justamente poniendo los memory barriers), etc.

4ta pregunta.
¿Que lectura que apunte ligeramente a mi problema conocen?

Podes mirar http://msdn2.microsoft.com/en-us/library/ms686353%28VS.85%29.aspx

5ta pregunta.
Supongo que tengo que tratar de minimizar el tiempo de bloqueo de tareas. ¿Pero que conviene mas? ¿Un solo bloqueo general de X tiempo o muchos pequeños pero que en total tengan menor tiempo de bloqueo?

Lo que buscas es minimizar el tiempo bloqueo, si es posible no bloquear la ejecución de un thread. También es importante minimizar la cantidad de datos compartidos por diferentes threads. Por ejemplo yo en ciertos casos puedo evitar o minimizar el bloqueo usando double o ring-buffering de información o usando la Interlocked API en Windows y soluciones similares en otras plataformas. Como siempre con todo lo que se refiere a performance, genera estadísticas, hace profiling. De lo contrario no vas a saber realmente cual es la mejor solución. También es importante tener en cuenta dónde vas a ejecutar tu código, no es lo mismo tener dos threads en cores separados o dos threads que se tienen que ejecutar en un solo core (en cuyo caso no son realmente concurrentes).

Desde hace ya varios años que vengo usando el DevPartner, es un producto bastante caro para los que hacen esto por hobby, pero es una herramienta sumamente útil para cualquier persona que se dedica a esto a tiempo completo.

Los microprocesadores de múltiples cores ya están llegando a la masas y dejaron de ser algo exclusivos de los servidores y las supercomputadoras. La mayoría de las computadoras personales y consolas de video juegos usan microprocesadores con múltiples cores que permiten ejecutar de forma paralela varios hilos de ejecución en hardware. Por otra parte la velocidad de cada core se ha estabilizado y por lo tanto no es posible mejorar la performance de ejecución de una aplicación que se ejecuta en un solo hilo de ejecución simplemente agregando más hardware. Pero crear una arquitectura para aplicaciones interactivas en 3D que usen este hardware nuevo es un reto por la necesidad de interacción entre los diferentes subsistemas. En este artículo se muestra la arquitectura que se creó para el Chromaticity Engine, un motor 3D que fue pensado para aplicaciones interactivas. El objetivo final del articulo es mostrar los diferentes inconvenientes al crear un motor 3D multihilo para aplicaciones interactivas y como se solucionaron esos inconvenientes en el Chromaticity Engine.

El artículo es bastante simple, lo hice deliberadamente simple para que sea fácil de entender para los que no están metidos en el tema. Creo que el artículo puede ser el primer paso para los programadores que todavía siguen programando en un solo thread. Pueden ver la versión completa en http://www.pablo-zurita.com.ar/spanish/2007/07/26/arquitectura-multihilos-para-motores-3d/.

Creo que deje claro en mi post que no es necesario todo el .NET framework, solo necesitas el CRT runtime (en Vista no lo necesitas). Igual si no te gusta eso podes usar otros compiladores e IDEs.

No, no es así. No es necesario .NET usando C++ común y silvestre. Lo único que hace falta es tener las DLLs del CRT y demás. Esas DLLs están incluidas en .NET pero también están disponibles en un paquete mucho más pequeño de 2.6MBs que está en http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee

Esto tiene que ver con como son representados los floats y doubles según el standard IEEE. Si te interesa saber mas del tema lee http://docs.sun.com/source/806-3568/ncg_goldberg.html.

La especificación de la extensión tiene todos los datos que necesitas e incluso tiene una sección "Usage Examples" que tiene un par de ejemplos. La especificación esta en http://oss.sgi.com/projects/ogl-sample/registry/EXT/framebuffer_object.txt.

http://gamearchitect.net/Articles/WhyC++.html

* los motores de hoy en dia no se hacen con oop asi que tampoco es una gran pérdida ...

¿Que? ¿Podrías poner algunos ejemplos?

Yo uso TinyXml para todas mis aplicaciones internas porque es sumamente fácil de integrar y usar. El único problema que vas a tener para soportar UTF-8 UTF-16 y demás es que vas a tener que convertid a multibyte pero nada más.

Es medio curioso, la mayoría de la gente que trabajo en algún editor de mapas en ese momento termino trabajando de alguna manera u otra. El programador del BSP termino trabajando Valve como así también los programadores del Worldcraft, el programador del QERadiant es ahora el lead programmer de id Software y el lead programmer del GtkRadiant (en el cual yo también trabaje) también trabaja en id Software. Y así hay más casos, creo que tiene que ver con el hecho de que hacer un editor de mapas que la gente pueda usar le da a saber a las diferentes empresas que estas capacitado para trabajar solo y en equipo en proyectos complejos.

No es de factura española porque ninguno de los programadores son españoles. :P
Yo soy argentino y los otros dos programadores principales son de Estados Unidos.
La verdad es que fue un lindo proyecto mientras duro (que fueron varios años) hasta que GX Media compro el Qoole y contrato al programador principal. Después todos nos dedicamos a trabajar en diferentes proyectos y empresas, uno se quedo en GX Media otro entro a Paraform y yo eventualmente termine trabajando como sub-contratista para Epic Games.

No se nada de engine en si, pero algo que se es que el editor esta basando en un editor en el que trabaje hace varios años ya. El editor se llamaba Qoole y era bastante conocido en la comunidad Quake. Si me acuerdo correctamente por una módica suma les vendimos los .objs y las funciones necesarias para que puedan hacer un editor. Ahora el editor Qoole 99 es open source (para vergüenza de los programadores... que desastre que eramos).

http://www.volved.com/qsr/