Performance de VS.NET

Hola Leonardo,

<<
Estoy deacuerdo con Tristán. Leí alguna vez que el código en funciones
matemáticas de C# era de un 90 a 95% del desempleno de las mismas funciones
en C++. Lamentablemente no encuentro la dirección donde leí esto pero si la
encuentro la publicaré en el foro. Invito a los participantes a buscar
información acerca de esto o a realizar pruebas.

Si bien es cierto que para los calculos de enteros en general el desempeño
es bastante bueno, en la parte de calculos con numeros reales el optimizador
del JIT actual todavia es bastante basico y no genera tan buen codigo como
un compilador de C++ moderno podría generar (y ciertamente no tan bueno como
el actual backend de VC++, por ejemplo). Adicionalmente, el JIT todavia usa
muy poco características avanzadas del procesador como SSE/SSE2, usando solo
unas pocas instrucciones en puntos bastante concretos.

Tomas Restrepo

Hola Federico,

<<
Hace unos dias lei un articulo sobre un bug del compilador de C++ que
me dejo pensando sobre la perfomance en general del codigo manejado.
(http://www.codeproject.com/buglist/...oolbug.asp)

En general, para los que lean el articulo, descubriran que el compilador
"se mete" entre el "ret" de un metodo y la instruccion que seguia al "call"
que llamo al metodo, haciendo "marshaling" entre los valores manejados
y los no (y, aparte, haciendolo mal como se explica en el link).

En realidad, todo este problema es ocacionado por dos elementos no tan
directamnete relacionados: el bug en el generador de codigo (que hace una
operacion incorrecta). Pero adicionalmente, entra en juego la presencia de
funciones virtuales.

Hay un asunto aqui que no es obvio, y es que en la version actual de MC++,
hay un problema de desempeño para clases __nogc que involucren metodos
virtuales, y es que invocar dichos metodos causa una transicion de codigo
manejado a codigo no manejado y de vuelta! Esto es debido a que se requiere
hacer la llamada a traves del Vtbl de la clase y esto se hace por medio de
manipulacion de punteros por "debajo de cuerdas". Esto puede causar
problemas significativos de desempeño desafortunadamente. Pero esto es mas
un problema de como genera el codigo el compilador que del propio JIT, hasta
donde entiendo.

<<
El tema de la perfomance del codigo manejado yo creo que esta dado
por:

1) ¿Cuan eficiente es el jitter? ¿Hasta donde compila el codigo intermedio
y donde comienza a llamar a helpers del framework para hacer algunas
tareas? La respuesta a esta pregunta es fundamental para poder estimar
la perfomance de un programa intensivo en calculo. Algo que nos mata,
por ejemplo, a los que algo hacemos en C++ es el manejo de los arrays
en .NET. Es MUY pesado (¿sera por el chequeo del valor del subindice?)

En terminos generales, el JIT es relativamente bueno, pero no alcanza
todavia la calidad de codigo de un backend de optimizacion completo. Esto es
en parte debido a que un JIT tiene que realizar su analisis en un periodo
muy corto de tiempo (de otra forma el costo de hacer el analisis sería
superior al costo de no optimizar la funcion!). Aunque en general el JIT
genera codigo de maquina directamente, si puede insertar en puntos
particulares llamadas internas de operaciones dentro del propio CLR (no del
*framework* como tal).

En cuanto al tema del acceso de los arrays, hay dos cosas que tener en
cuenta: dependiendo del loop que se haga, es posible que el JIT haga
array-bounds-checking-hoising, o sea que evite tener que hacer el chequeo de
fronteras por cada iteracion. Sin embargo, para que esto suceda en C#, debe
usarse un loop for() o while() para recorrerlo, y no un foreach() (con
foreach no es posible hacer esta optimizacion). La otra cosa es que
dependiendo de como se acceda el array, puede que involucre casts al accesar
los elementos, lo cual es costoso (esto sucede, por ejemplo, si se accede al
array a traves de la clase System::Array, y no del array tipado mismo)

Otra cosa a tener en cuenta es que C# y VB.NET practicamente no hacen
optimizaciones al codigo IL generado, excepto por las basicas (eliminacion
de subexpresiones comunes por ejemplo, y folding de literales). En cambio,
el compilador de MC++ si puede pasar el IL a través del backend completo de
optimizacion del compilador antes de entregarlo al JIT (una desventaja, sin
embargo, de esto, es que es una de las razones por las que MC++ produce
codigo no-verificable).

<<
2) Como consecuencia del punto anterior, seguramente habra cosas que
son elegantemente manejadas por el jitter (como podria ser la aritmetica
entera), y otras que directamente no pueden ser eficientemente
compiladas
y se delegan en el framework (como por ejemplo, el casting y el boxing).
Esto debe ser tenido CONSTANTEMENTE en cuenta para poder escribir
codigo eficiente.

Cierto, pero no siempre es tan dificil. MC++ permite hacer algunas
optimizaciones adicionales en estas areas al programador que C# no permite,
como por ejemplo acceso directo a los boxed value types dentro del heap sin
tener que hacer unboxing.

<<
3) ¿Cuan eficiente es el framework? Para el caso de WindowsForms, por
ejemplo, a pesar de lo linda y util que sea no deja de ser otra (u
otras)
capa(s) mas entre nuestra aplicacion y windows, que ya de por si tiene
varias capas interconectadas entre si. Por ejemplo, el pintado de los
controles, actualmente, deja mucho que desear en lo que refiere a su
tiempo de ejecucion.

Con Winforms, uno de los problemas clave actualmente es el consumo de
memoria, aunque tengo entendido que se esta haciendo un trabajo bastante
agresivo en esta area...

<<
Son cosas que no conocemos o conocemos indirectamente, por lo que creo
que abra areas donde los programas funcionaran muy bien y areas donde
simplemente se arrastraran, y finalmente, como alguien dijo antes en este
hilo, todo termina dependiendo de lo que hagamos nosotros. Un archivo XML
grande se carga en mas de 2 segundos en un XmlDocument. Si cargamos
uno al inicio de la form y despues trabajos con el, no pasa nada, pero si
lo cargamos en un loop para analizar cientos de documentos que esten en
el disco, entonces estamos listos y ya podemos ir buscando una forma
distinta de hacerlo...

Este ejemplo particular quedas es un problema que ocurriría en cualquier
otra plataforma, dado que el modelo del DOM es realmente muy ineficiente.
Pero una ventaja significativa en esta área del framework es que ofrece
opciones, como el uso del XmlReader y del XPathDocument, por ejemplo en este
caso.

<<<
En lo personal, cada vez utilizo mas C#. Cambio (o cedo) un poco de
perfomance por facilidad para hacer las cosas, por la INCREIBLE cantidad
de cosas que el framework pone a nuestra disposicion y por la estabilidad
de las aplicaciones finales. Como un tipo que vive de programar, poder hacer
mas y mejores cosas en menos tiempo termina resultando en mas $ y,
finalmente, este concepto termina mandando. El cliente, que se banque una
pequeña demora adicional, mientras no sea la muerte...

Completamente de acuerdo.

Tomas Restrepo

Bueno, no había leido bien tu mensaje, lo siento, y ahora veo que ya has
comentado el tema de las comprobaciones de límites. Desde luego veo que no
puedo aprotar nada por que conoces el tema mucho más a fondo que yo :-). En
fin, un saludo y que se sigan mejorando todos los aspectos.

Realmente lo que me parece importante es eliminar la idea de que un código
ejecutado mediante jittering, tenga que ser necesariamente menos eficiente
que uno precompilado. Probablemente en esta primera versión, todavia haya
aspectos mejorables, pero desde luego a mi me parece que exceptuando la
carga incial de una aplicación winforms, en todos los demás aspectos las
prestaciones de .net son sorprendentes.

Juan Carlos Badiola
MVP - C#

Gracias por sus respuestas, algunas de las cuales son muy tecnicas y no
entiendo bien.

Les confieso que no me aclararon bien lo que originalmente pregunté. Tengo
sistemas en Visual Foxpro y en Delphi con una asombrosa estabilidad y
velocidad buenas. Mis clientes son empresas medianas y pequeñas que utilizan
PC's normales y redes W2000. Por razones de actualización (y pensando en
crecimiento, la web y el futuro) estoy aprendiendo C# para hacer o re-hacer
aplicaciones comerciales (contabilidad, facturacion, compras, bancos ,
nomina y todas esas cosas, ya saben). No requiero de cálculos muy
complejos ni matrices muy grandes.

Lo que quisiera es que me digan si realmente recomiendan .NET para este tipo
de aplicaciones. No requieren mucho soporte ?? no dan muchos bugs ?? Son
aceptablemente rápidas ??? Como dije, dando por hecho que están muy bien
programadas.

Alguno de ustedes trabaja asi como yo, desarrollando y vendiendo
aplicaciones de ese tipo para muchos clientes ?? Es bueno .NET para ese
entorno ??? para vivir de eso, como actualmente se puede con Visual Fox o
Delphi ??

Las opiniones de quien trabaje fijo empleado en una empresa, son valiosas
tambien pero obviamente no es lo mismo. Son ambientes diferentes. La
aplicacion para muchos clientes debe ser mucho mas estable y segura pues el
desarrollador no siempre está visitando los clientes.



Gracias amigos



"Carlos Rod" wrote in message
news:#

Estoy empezando en .NET . Me interesa hacer aplicaciones comerciales para
multiples clientes. Quisiera leer comentarios sobre como es el

performance

de estas aplicaciones finales, son estables ??? no dan muchos problemas
raros ??? (asumiendo que estan bien programadas, claro) Son confiables

??

no requieren mucho soporte ???

Vamos por parte.

Tengo clientes con aplicaciones en Visual Foxpro, en foxpro 2.6
y en clipper y, como andan bien y rápido y el mantenimiento que
necesitan es minimo, no pienso cambiarlas ni perder tiempo
reinventando la rueda. Ya tengo sistemas de control de stock,
facturacion, contabilidad, etc y no veo porque tenga que tirarlos
y volver a empezar, si nadie me va a pagar por esta reconstruccion.

Lo que si, lo nuevo que me va saliendo, lo hago con C#. Por
ejemplo, tenia que hacer una aplicacion para mostrar datos de
cubo olap y con vfp estaba enredado porque tenia problemas
en como vfp interactuaba con un componente com. Estos
problemas NO APARECIAN en la aplicacion c# y finalmente
quedo asi.

Actualmente, solo utilizo vfp para el mantenimiento de lo viejo
y para escribir componentes COM con lo que abro la funcionalidad
de mis sistemas a aplicaciones c#, vba de office y al web. Si tu
quieres abrir tus aplicaciones al WEB que vas a hacer? Claro que
puedes hacerlo con vfp, pero vfp no esta diseñado para eso, por
lo que te vas a encontrar dando vueltas y reinventando la rueda!

La ventaja que tenes con vfp es que lo conoces, que no es poco,
y en principio te encontraras que desarrollaras mas rapido con vfp
que con c#. Pero con la practica te garantizo que desarrollaras
mejor y mas rapido con c#. Esto supone un periodo de transicion
donde no estas haciendo las cosas como deberias, pero terminaras
haciendolo bien y rapido.

Y, por otro lado, debes ser practico. Vfp esta muy bueno, pero
desde hace varios años que lo unico que Microsoft hace con vfp
es agregarle cosas que dificilmente se utilizan a diario, y siguen por
ejemplo sin cambiarle una linea al generador de informes.

Resumiendo, mi consejo: Empieza a hacer cosas con C#, porque
es el futuro. Empieza a hacer cosas y aplicaciones revolucionarias
que antes, por utilizar vfp, no las querias hacer porque era un tema
complicadito. Pero no reinventes la rueda. Lo que funciona bien,
dejalo como esta. Lo mas probable es que vayas desactivando
modulos en tus aplicaciones viejas y reescribiendolos cuando notes
que se quedaron muy chicos.

Saludos

Federico