Variables Tipo Register C++

[nsL]

 Buenas,
Tengo entendido que las variables declaradas como register se almacenan en registros de la cache (si es que hay espacio) y que por ello la cpu accede a ellas mas rapido, con el consecuente aumento de velocidad....

¿Alguien las usa? Es que no oigo a la gente hablar d ellas, y a lo mejor ya estaban en desuso o algo parecido...

La verdad que veo un poko absurdo depender operaciones que requieran velocidad de ese tipo de variables, ya que no siempre estaran disponibles...Otra cosa es que se puedan reservar...

Pues eso, simple curiosidad :P

Saludos!  B)  

[_Grey]

 con variables register conseguias que el compilador generase codigo intentando mantener "ese" valor en un registro de la CPU. Queda claro que para un bucle for o while es util, lo que pasa es que despues de las optimizaciones que se usan hoy dia no conseguiras nada.

Saludos.

[TheAzazel]

 tal y como ha dicho grey.... hoy en dia, apenas tiene sentido. Si quieres exprimir tu programa a ese nivel... utiliza un compilador como el Intel C++ (q es de lo mejorcito) o...bajate a asm y asi TE ASEGURAS que tal variable esta en tal registro, ahora, adios portabilidad jeje.

[ethernet]

 Siempre me hago la misma pregunta cuando veo algún post de este tipo: es importante este tipo de optimizaciones a estas alturas? Yo creo que no lo son para nada y es que pienso en la cantidad de lenguajes, librerías, etc que usamos y que tienen varias capas de abstracción antes de llegar al código máquina y me pregunto qué porcentaje optimizaremos (del global de la aplicación) si ponemos 100 o quizás 200 variables de tipo register o si ponemos 20 rutinas en asm (de lo que tengo mis dudas que sea más óptimo). Además, teniendo en cuenta que los procesadores actuales usan tropecientas optimizaciones y planificaciones de código veo más adecuando que sea el compilador el que se encargue de esas cosas. Al cesar lo que es del cesar.

saludos

[DraKKaR]

 Las variables de ese tipo forman parte del "pasado" de la programación. En nuestro campo, el cuello de botella de la aplicación suele estar en el procesamiento de los gráficos (toda la pipeline). Hace tiempo, cuando toda la pipeline corría por software, sí que podía resultar útil recurrir al ensamblador para rascar un poco más de rendimiento. Por ejemplo, cuando se anunció la tecnología MMX y salió el juego POD. Ahora que básicamente toda la pipeline se procesa en otro módulo físico (GPU) no tieen sentido recurrir al ensamblador y de la CPU.

Lo que hay que apurar está en la GPU, y ahí es donde puedes usar ensamblador para rascar algunos FPS de más ;)

PD: Esta última frase es cierta siempre y cuando se use el API gráfico de forma eficiente.

[TheAzazel]

 Hay una cosa q no llego a entender.... nSL pregunto si se podia utilizar esa keyword del C y tal.... no digo nada de graficos. Estoy con vosotros que cuando se trata de procesamiento grafico (en especial 3D y 2D depende como lo hagas) es un poco tonteria complicarse la vida con esas cosas pero....
hay muchas mas areas donde una buena optimizacion(ya no solo a nivel de codigo) si no del algoritmo escogido, uso de ciertos trucos y demas...q ACELERAN la aplicacion.

Eso de las API's, una sobre otra y tal y tal... pues mira, hacer un CALL o un JMP y luego otro despues...las CPU de hoy se las comen sin ningun susto(para eso esta la prediccion de saltos y todos los mecanismos asociados) luego...  por eso, podemos usar, por ejemplo, SDL que corre sobre DX(en graficos) y este a su vez sobre otras varias capas... y eso degrada el rendimiento? pues muy muy poco, casi inapreciable en las CPU actuales... pero otra historia es... ciertas cosas q son optimizables.

Personalmente, cuando he terminado algo, le paso un par de veces un profile...q el cuello es grafico y este se hace por hardware... intento enviar menos trabajo a la GPU con trucos y demas... q es alguna rutina pestiña q se ejecuta mil veces.... me meto con ella y normalmente en ASM+MMX+SSE o lo que sea. Aunq tambien, todo depende, siempre, en algun punto esta el cuello grafico por lo que, antes, cuando todo era soft podias ganar mas de un 50% de velocidad... ahora, por experiencia, tocando algunas cosillas consigues mas o menos un maximo de un 20%, ojo, q esto es muy dependiente de lo q se haga pero una media :).

Pues nada,  se q muchos de vosotros veis absurdo optimizar y teneis vuestra razon pero.... yo pienso mas a lo retro y siempre me gusta optimizar jeje.


:rolleyes:  

[ethernet]

 La optimización es la razón por la cual una gran parte de proyectos no se llegan a terminar nunca. Como decía nu libro antiguo de programación de juegos que ahora mismo no recuerdo... "cuando estés haciendo algo no pienses en lo que harás después". Aplicado a programación de juegos lo dejo como ejercicio para casa :)

saludines

[Junse]

 

"cuando estés haciendo algo no pienses en lo que harás después"

yo coincido en eso  (ole)
pero tambien es cierto que eso se aplica solo si  el trabajo de diseño previo esta bien realizado, o sea que si uno quiere ir haciendo las cosas sobre la marcha, en programacion y en otros campos  :rolleyes:
tiene que saber de antemano que va a tener distintos problemas en su desarrollo, los cuales pueden ser de rendimiento, funcionamiento o tal.
Aunque creo que ethernet se referia a otra cosa con esa cita es valida la aclaración.

[Astharoth]

 
Hola.

Bueno, hoy por hoy es mas eficiente planificar bien el codigo (usar buenos algoritmos, buenas estructuras de datos,etc) que bajarse (aun en las rutinas criticas) al ensamblador.
Yo pertenezco a la epoca de hacerse los polyfilllers en ensamblador, rascando ciclos de cpu en el inner loop y a toda esa parafernalia (si, hasta el 97/98 yo solo programaba 100% ensamblador).

Tal y como estan las cosas hoy en dia, optimizar algo en ensamblador te puede suponer un 30% mas de tiempo de curro y la ganancia puede ser del 0,01% (excepto en casos criticos, como un inner loop de "algo" como por ejemplo un descompresor de video o similar donde SI merezca la pena tirar de SSE2/SSE/3DNow,etc para paralelizar el proceso).

Si se tira de VC/GCC y demas, quizas se vuelve interesante en algunos puntos hacer algunas rutinas que paralelicen el codigo.

Por ejemplo, supongamos que tenemos una funcion de libreria (propia) para multiplicar un vector por una matriz y dicha funcion debera ser llamada "muchas" veces debido a que hacemos calculos N intensivos con la CPU. Bien, en este caso currandose la rutina en ensamblador vectorizando el codigo podemos obtener un buen empujon.

Sin embargo, si usamos otros compiladores que vectorizan codigo (como el vectorc, el de intel) de esa tarea se supone que tambien se encarga el compilador (nunca he probado a desensamblar el codigo generado por alguno de estos dos compiladores en alguna de estas dos circunstancias.. pero por los benchmarcks que lei el de intel daba una buena patada a los demas)

De todas formas pensad que no solo ya es vuestro proceso, que son las llamadas a sistema (por ejemplo, un fopen pasa por la libc, de ahi a createfile de kernel32 de ahi a zwcreatefile/ntcreatefile de ntdll.dll y de ahi callgate a ring0 a la zwcreatefile de ntoskrnl.exe y asi con todas.. eventos, mutex, secciones criticas,etc)

Por otra parte las llamadas a directx/opengl (tres cuartas partes de lo mismo.. en directx .. d3d9.dll , d3d8thk.dll, ntoskrnl.exe, win32ksys.sys, driver de la tarjeta) ...

Ademas, el propio scheduler tambien se tiene que ejecutar (el del sistema) atender las interrupciones de pagefault (para cargar las paginas de memoria en disco si son necesarias) y se tienen que ejecutar el resto de procesos.

En definitiva.. que si pillaramos un PC de hoy en dia y lo gastaramos con UN solo codigo (sin ceder proceso a nadie) ... no veias como tiraria ;) (para muestra un boton, mirar la xbox con un simple 733)

Asi que.. buena algoritmia, buen diseño y a rascar en cosas faciles (si no usas c++ desactivar las excepciones, asi quitas todos los push fs, mov fs:[ ... para fijar los exceptions handlers,etc) y solo en casos puntuales y despues de un buen profiling optimizar ese N en ensamblador (si la ganancia compensa el tiempo empleado).

Un Saludete.

[ethernet]

 Yo antes estaba preocupado por algunas cosas como el activar el rtti, las excepciones, etc en c++ pero a medida que vas teniendo más experiencia y vas viendo más códigos te das cuenta que es un error garrafal. Para muestra solo hay que mirar un poco en este foro:

- Glest: usa excepciones y  para renderizar algunas veces usar glVertex y me parece un juego excepcional
- Haddd: usa C# que me apuesto el cuello que lleva unas cuantas capas de RTTI, excepciones y otras cosas (además de toda la VM, etc.. ) y el motor va bien como hemos podido comprobar en los diferentes videos.
- War3d: No he visto nada que optimice absolutamente nada y ahí está
- Juegos del amigo zwitter: Están hecho con fenix, sistema de desarrollo que siempre está en el punto de mira de los programadores tradicionales, así como blitz3d, etc,  y no creo que tengan nada que envidiar a otros juegos


La moraleja de todo esto es que para hacer buenos juegos, tanto gráficamente,en jugabilidad y otras cuestiones importantes en un juego no es necesario para nada obsesionarse y, digo más, nisiquiera pararse a pensar en otras optimizaciones que no sean las que surgen del propio sentido común al programar. Otra cosa es estar programando un doom3.. :)

un saludo

[Pogacha]

 

Otra cosa es estar programando un doom3..

Ni lo menciones ... , [spam] proxima beta de pogacha engine 2 probara soporte para NV1x y GF2x con la misma velocidad y casi la misma calidad grafica, estoy con el ATI 8500 y GLSL, y si logro estabilizar la parte de fisica también [/spam], tiempo critico ... ja!, hasta las listas son borradas item a item ... si no haces todas estas cosas no te da el tiempo y punto, resultado 10 fps ...
Eso de pasar trabajo del GPU al CPU para optimizar mmmh... ganas en placas como la tuya o inferiores pero pierdes en placas mas nuevas ... no se ...
Saludos