Sobre variables

"RFOG" wrote in message
news:%23$g$

[...]
Pasando por el jitter genera un código más que aceptable, [...]
00000000 push rbx
00000001 sub rsp,20h
[etc]

Pregunta: ¿cómo lo sacas? ¿Hay alguna forma no muy trabajosa de sacar
cuál es el código que se genera después de pasar por el JIT? A mí se me
ocurre rodar el NGEN y luego desensamblar el EXE, pero sería bastante
pesado.

Visual Studio 2008 tiene la opción de capturar el ejecutable después de la
pasada del jitter en Release (Supongo que en Debug también) y entonces pasa
como con el C++ optimizado: el IDE muestra cosas raras porque las líneas del
fuente en el PDB no se corresponden del todo con el código binario, pero a
veces es la única manera de depurar algunas cosas.

La opción está en Options -> Debugging -> General -> Supress JIT
optimization on module load.

La otra forma es lanzar el ejecutable y una vez corriendo, lo anexas al IDE,
con la limitación evidente.

"Alberto Poblacion" wrote
in message news:u5#

"RFOG" wrote in message
news:%23$g$

[...]
Pasando por el jitter genera un código más que aceptable, [...]
00000000 push rbx
00000001 sub rsp,20h
[etc]

Pregunta: ¿cómo lo sacas? ¿Hay alguna forma no muy trabajosa de sacar
cuál es el código que se genera después de pasar por el JIT? A mí se me
ocurre rodar el NGEN y luego desensamblar el EXE, pero sería bastante
pesado.

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y desarrollo
Los asesores son personas místicas que le piden un numero a una compañía y
luego se lo devuelven.

Pues si las llaves son como una 'subrutina' es logico creo que es preferible
poner la variable fuera y antes del bloque sobre todo si se trata de un
loop. Si la pones dentro se supone que se va a estar creando una nueva cada
vez y eso no es necesario para lo que se desea hacer.
Claro que solo debe notarse cuando el loop tiene muchas iteraciones.


<Esteban> escribió en el mensaje
news:

Hola RFOG.

En C++ es muy habitual hacer cosas así:

//Código
int vi;
//Hacer algo con v1...
{
int contador=fi(v1);
f1(contador);
//etc
}

De este modo contador entra y sale de ámbito y duración entre las llaves,
ahorrando pila.

Muy buen ejemplo para entender mi punto.

Es decir que la llave de cierre 'elimina' la variable local contador (al
menos lógicamente), tal como lo hace un método cuando termina.
Imagino que C# al ser un 'hijo' de C++ debe funcionar igual.

Respecto a lo que comentas de declarar una variable dentro de un bucle y
que se cree en cada iteración, la teoría dice que sí (lo que te ha dicho
Alberto), un compilador de C++ bueno sacará esa variable fuera por
optimización aunque a nivel sintáctico y semántico sería como si
estuviera dentro, lo que hace el C# no tengo ni idea, pero voy a
comprobarlo.

Según eso, es de suponer entonces que dejar la variable fuera del bucle
debe ser más eficiente, sobre todo si son varias las variables declaradas
dentro del bucle.

Si llegas a comprobarlo para C# favor me dices. Yo veré también como
trato de hacer algunas pruebas, ya que al venir de otros lenguajes se me
dificulta un poco entender el funcionamiento.


Gracias ;-)

On Tue, 5 May 2009 21:30:32 -0400, "Heriberto" <herib> wrote:

Pues si las llaves son como una 'subrutina' es logico creo que es preferible
poner la variable fuera y antes del bloque sobre todo si se trata de un
loop. Si la pones dentro se supone que se va a estar creando una nueva cada
vez y eso no es necesario para lo que se desea hacer.
Claro que solo debe notarse cuando el loop tiene muchas iteraciones.

Pero si la pones fuera el ámbito y visibildad quedan fuera también,
pudiendo entrar en conflicto con otras o simplemente incrementando el
gasto de pila...

Imagina por un momento que necesitaras tener un objeto nuevo en cada
vuelta de la iteración. La forma más sencilla es hacerlo en local.

Y ahora piensa que el bucle se va a ejecutar 100000 veces y que el
objeto es no trivial, con lo que la sobrecarga de
construcción/destrucción se va a notar, y el recolector de basura iba
a trabajar de lo lindo, así que lo mismo la mejor opción sería alguna
forma de "reset" del mismo...

Todo depende del momento, de lo que vayamos a hacer y cómo queramos
hacerlo, de consideraciones de rendimiento allí donde sea recomendable
(no vamos a tirarnos dos semanas pensando cómo hacer un bucle trivial
de diez vueltas que se va a ejecutar dos veces cada vez que se lance
la aplicación), etc. Y por contra sí que sería razonable tirarnos un
tiempo pensando cómo, cuándo y dónde van a estar esas mismas variables
dentro de una máquna de estados que será el corazón de nuestra
aplicación y que se va a estar ejecutando millones de veces a lo largo
del funcionamiento de la misma.

Ojalá existieran "reglas de oro" para estas cosas, en lugar de
orfebres seríamos ingenineros de verdad.

<Esteban> escribió en el mensaje
news:

Hola RFOG.

En C++ es muy habitual hacer cosas así:

//Código
int vi;
//Hacer algo con v1...
{
int contador=fi(v1);
f1(contador);
//etc
}

De este modo contador entra y sale de ámbito y duración entre las llaves,
ahorrando pila.

Muy buen ejemplo para entender mi punto.

Es decir que la llave de cierre 'elimina' la variable local contador (al
menos lógicamente), tal como lo hace un método cuando termina.
Imagino que C# al ser un 'hijo' de C++ debe funcionar igual.

Respecto a lo que comentas de declarar una variable dentro de un bucle y
que se cree en cada iteración, la teoría dice que sí (lo que te ha dicho
Alberto), un compilador de C++ bueno sacará esa variable fuera por
optimización aunque a nivel sintáctico y semántico sería como si
estuviera dentro, lo que hace el C# no tengo ni idea, pero voy a
comprobarlo.

Según eso, es de suponer entonces que dejar la variable fuera del bucle
debe ser más eficiente, sobre todo si son varias las variables declaradas
dentro del bucle.

Si llegas a comprobarlo para C# favor me dices. Yo veré también como
trato de hacer algunas pruebas, ya que al venir de otros lenguajes se me
dificulta un poco entender el funcionamiento.


Gracias ;-)

Microsoft Visual C++ MVP http://geeks.ms/blogs/rfog
Cada siete a?os se muda la condicion, la costumbre y complexion.