OT: rendimiento de VFP

[Mauricio Urquijo]

Hola
Todos mis desarrollos los hago un una máquina HP con procesador Pentium E5300 (Dual-Core) con 3 Gigas de RAM y va razonablemente decente. Esta semana compré un portatil Toshiba con procesador i5 de segunda generación (2410M) y le mandé instalar 8 gigas en RAM. Vaya sorpresa cuando pruebo que dos desarrollos muy demandantes de datos corren casi que en el mismo tiempo en las dos máquinas. En el portátil mejora sólo cuatro segundos, 270 segundos contra 274 segundos de la PC de escritorio. Ambos tienen Windows 7 Home Premium de 64 bits.
Mi pregunta es si hay alguna instrucción en VFP que le pueda incluir para que aproveche las 8 gigas de RAM?
De antemano, muchas gracias por las respuestas.
Mauricio

[Mauricio Molinero,]

Hola tocayo!

Eso es debido a que VFP utiliza de a un solo núcleo del
microprocesador. No crea mas 'hilos' (threads) a los otros núcleos
para balancear la carga. Esto también es una desventaja porque los
núcleos individuales son cada vez mas chicos, entonces al comprar un
I7 en realidad estamos usando un nucleo mas pequeño. De todas formas
la arquitectura de estas pc de alto rendimiento hace que sea mucho mas
veloz con sus predecesores.

Por eso tambien MySql se vuelve tan importante ya que soporta
multiples hilos al procesador y puede aprovechar el rendimiento al
maximo.

Tambien habria que ver si hiciste la prueba en iguales condiciones o
no tienes algun otro problemita de configuracion.

Saludos!

Mauricio R. Molinero,

[Carlos Miguel FARIAS]

El vfp, por ser de arquitectura de 32 bits, no puede direccionar mas de 4 gb de memoria, o sea que mas memoria, para el no existen.
Para poder hacer la comparación ademas debes tener en cuenta que otros procesos/servicios estan corriendo en ambas maquinas, la velocidad de las placas madre, si los chips de memoria son iguales, etc.
Es mas, supongo que siendo una aplicación de vfp, prima el acceso a datos en el disco, y el desempeño entre una maquina y otra dependera de la "velocidad" con que los respectivos discos respondan.
Es mas, el solo hecho de tener datos fragmentados (o discos) puede cambiar notoriamente los tiempos de respuesta.
Saludos: Miguel

[Walter R. Ojeda Valiente]

Aunque tu compu tenga 16 cores Visual FoxPro solamente usa uno de ellos, porque en la época que salió a la luz (año 2004) aún no existían las dual-core y demás.

Claro que sería bueno que alguien le agregara esa posibilidad, porque todas las computadoras nuevas ya serán multi-core.

Saludos.

Walter.

Y por supuesto, aún sin novedades del imaginario dios de "extremo".

---

Date: Fri, 2 Sep 2011 04:39:42 -0700
From: mauro....@gmail.com
To: publice...@googlegroups.com
Subject: [vfp] OT: rendimiento de VFP

[Mario López]

@Walter:

MTmyVFP - Multi-threading VFP:

http://mtmyvfp.codeplex.com/

Saludos,
Mario

----

On Sep 2, 1:03 pm, "Walter R. Ojeda Valiente" <w...@hotmail.com>
wrote:

> Aunque tu compu tenga 16 cores Visual FoxPro solamente usa uno de ellos, porque en la época que salió a la luz (año 2004) aún no existían las dual-core y demás.
>
> Claro que sería bueno que alguien le agregara esa posibilidad, porque todas las computadoras nuevas ya serán multi-core.
>
> Saludos.
>
> Walter.
>
> Y por supuesto, aún sin novedades del imaginario dios de "extremo".
>

> Date: Fri, 2 Sep 2011 04:39:42 -0700

> From: mauro.urqu...@gmail.com

[Walter R. Ojeda Valiente]

Que bueno, alguien ya se dedicó al tema, gracias por compartir esa información.

Saludos.

Walter.

> Date: Fri, 2 Sep 2011 09:41:14 -0700
> Subject: [vfp] Re: OT: rendimiento de VFP
> From: guag...@gmail.com
> To: publice...@googlegroups.com

[Marco Plaza]

Hola Mauricio, ningún lenguaje por si solo implementa el multiproceso. Eso lo debe hacer el programador de la aplicación, pues la lógica de cada sistema es distinta, y a uno le toca dividir y coordinar en secciones que no interfieren entre si los procesos. Según entiendo, la diferencia entre lenguajes mas nuevos ( .net )  y vfp, es que te permiten invocar nuevos hilos sin tener que crear ( como lo hacen librerías como MtmyVfp o parallelfox ) workers separados de tu propia aplicacion. Entra en parallelfox y verás una buena explicación de joel leach acerca de ello ( en ingles ) Rick Strahl tambien aborda el tema con servidores de correo multiproceso creados en .net que puedes usar desde Vfp. Ahora, cuando se trata de manejo de datos, los rdbms si usan los cpus de forma concurrente para las tareas de indexado, ordenación y ejecucion de procesos almacenados sin que te preocupes por ello, que es lo que no hace vfp. Sin embargo, sql server o mysql no son mas rápidos accediendo a la data que vfp.

Saludos.

Marco Plaza

[Mauricio Urquijo]

Muchas gracias a todos por los aportes. Ahora creo entender que mi CPU Dual Core de 2.6 GHz está casi con las mismas capacidades de un core i5 de segunda generación de 2.3GHz. Menos mal están tan económicas las portátiles que no siento que perdí la plata. ;)
Saludos a todos
Mauricio
PD: Ya había revisado el tema de servicios y los noté muy similares.

[Luis Mata]

ummm hacer que un exe utilice lo 7 nucleos... y para que????

 

---

	Mata Figueroa, Luis A. Procesos, Tecnología de la Información y telecomunicaciones TELF: (00 51 1) 617-4613 RPC : (00 51) 993597297 FAX : (00 51 1) 617-4601 lm...@cclf.com.pe www.cclf.com.pe

 

From: Mauricio Urquijo

Sent: Friday, September 02, 2011 12:51 PM

To: publice...@googlegroups.com

Subject: [vfp] Re: OT: rendimiento de VFP

 

[Mauricio Molinero,]

Justamente del video explicativo (el cual no puedo encontrar) de
parallel fox saque esa conclusión de los microprocesadores

Ya se que el desarrollador debe manejar los 'threads', pero habría que
ver si las maquinas virtuales de .net o Java ya que son tan elaboradas
no manejan automáticamente la carga de cada núcleo para sacarle mas
provecho si al parecer esa es la idea mas nucleos mas velocidad.

Saludos!

Mauricio R. Molinero,

[Mauricio Molinero,]

Mauricio, claro que no has malgastado tu dinero, estos micros son una
maravilla! Muy veloces.
Yo tengo varios clientes con I5 y Seven 64 bits en el server y la
verdad vuela bajito.
Lastima las demas pcs de la red que no pueden aprovechar esa velocidad
ya que estan en tablas libres de VFP y el cambio del servidor no varia
mucho.

Saludos!

Mauricio R. Molinero

[Carlos Miguel FARIAS]

Tengo entendido que en c y c++ se puede hacer programacion multihilo (instruccion fork) pero solo toco de oido (y uno solo porque del izquierdo estoy casi sordo).

[Walter R. Ojeda Valiente]

Claro, esa es la idea de los múltiples núcleos, dividirse las tareas entre ellos y que el resultado final sea mayor velocidad.

Supongo que los motores SQL ya manejan ese concepto, al menos Firebird sí lo hace.

Saludos.

Walter.

> Date: Fri, 2 Sep 2011 12:01:03 -0700

> Subject: [vfp] Re: OT: rendimiento de VFP

> From: pip...@gmail.com
> To: publice...@googlegroups.com

[Marco Plaza]

Hola Mauricio, a nosotros nos queda el trabajo de programar y planear la distribución de los procesos, pues el cpu ni windows ni el programa saben la secuencia ni dependencia de los mismos de antemano. Ningún lenguaje puede por sí solo hacer que una aplicación diseñada para 1 o dos cpus trabaje con 4 o 6 si el programador no lo previó. Un ejemplo evidente son los convertidores de video o rutinas de compresión. Descarga winrar 2.xx y compara con winrar 4 verás que el rendimiento difiere por la optimización del uso de los cpus.

Y a la pregunta de Luis, por ejemplo con multiprocesamiento si..:

Tienes 20 tablas que requieren ordenarse o indexarse, puedes dividir el proceso en 4 y reindexar 4 tablas a la vez.
Generar reportes: si necesitas enviar 1000 estados de cuenta no lo haces serialmente, puedes crear cuatro procesos simultáneos que ejecuten la tarea en menor tiempo.
Enviar correos electrónicos: no paras el servicio si un servidor tarda en responder. Otro trabajador ( como se le llama en Vfp ) toma la petición de nuevas tareas.
En programas complejos que ejecuten procesos no dependientes ( ejemplo: necesitas obtener datos de 4 fuentes distintas - convertir una hoja de excel, traer data de sql server y otra de un servicio  web ) puedes invocar a la vez la peticion y armar el resultado con un tiempo máximo igual al tiempo que tome la tarea mas larga, y no a la suma de los tiempos de todas. No tendrás lo que llamamos 'idle time' o tiempo ocioso. Las posibilidades son muchas y como dije dependen de cada aplicación en particular. Si tienes un sistema con tiempos de proceso muy pequeños tal vez no te beneficie, pero cuando se programan servidores de negocios o procesos batch es importantísimo exprimir todo el poder del cpu.
Yo tengo un proceso que requiere recalcular digamos 5.000 posiciones de estados de cuenta a una fecha en el pasado... porque ir del 1 al 5000 si puedo lanzar un proceso que ejecute del 1 al 1000 , otro al mismo tiempo del 1001 al 2000 y así... termina mucho antes!

Para los que llegan tarde, discutimos acerca de multiprocesamiento con Vfp.

El link de parallelfox está en activeVfp.:

http://vfpx.codeplex.com/wikipage?title=ParallelFox&referringTitle=Home

Saludos.

Marco Plaza

[Luis Mata]

Ahhhhh, proceso de datos!!!!!!!, eso lo programo directamente en el SQL Server con los SP, este si que distribuye perfectamente  las tareas en los procesadores y memorias. Es por eso que los servidores deben de ser unos monstruos pues.

Al final los terminales clientes son como se dice terminales tontos, en cuanto al sistema claro, para todo lo demás no creo que se requiera tanta potencia. VFP no lo hace todo pero viendo de otro ángulo, apoyándose en las Base de datos, SQL Server, Oracle, Postgress... si que la hace.

De todas formas el que distribuye el uso de tal y cual procesador es el windows al final, cuando ejecutas tu exe, no sabes cual de todos los 4 procesadores usara windows, puede que tenga en pleno uso los primero 3 y utiliza el 4, o esta en plan H y utiliza el primero

 

From: Marco Plaza

Sent: Friday, September 02, 2011 6:50 PM

To: publice...@googlegroups.com

[Marco Plaza]

Hola Luis, un SP en SQL Server se ejecutará secuencialmente en un solo cpu, no importa cuantos cpu tengas en el servidor. Sql Server realizará el balance de carga como mencionas que lo hace windows sobre los trabajos y peticiones que recibe, así como en la planeación de procedimientos internos necesarios para completar consultas. Sql Server no partirá tu proceso en fragmentos que se ejecuten al mismo tiempo. Con el proceso paralelo puedes hacer dos o mas tareas que pertenecen a un mismo proceso al mismo tiempo con cpus y recursos separados para terminar la tarea en menor tiempo. Y como digo, tiene especial aplicación en tareas de backoffice o procesos de transformación, minería de datos de grandes set de datos... depende de cada aplicación, si tu programa solo lleva y trae datos de terminales y tienes un tiempo de respuesta bueno no encontrarás beneficio en el multiproceso. Entra en el link y mira los videos de Joel donde te muestra la diferencia entre proceso simple y paralelo, y como puedes hacer que partes de una aplicacion de VFP usen cuatro o seis cpus al 90%..


Marco Plaza

[Luis Mata]

Al parecer este tema es muy amplio e interesante

 

Cuanto mas poder mucho mejor, pero insisto la potencia debe residir en el Server si no cual seria la lógica de Cliente servidor?

[Mauricio Urquijo]

Marco, leyendo tu comentario me intriga algo que de pronto nos puedes enseñar: " porque ir del 1 al 5000 si puedo lanzar un proceso que ejecute del 1 al 1000 , otro al mismo tiempo del 1001 al 2000 y así... termina mucho antes!"
Yo siempre programo del 1 al 5000 cómo dices tú pero me gustaría mucho ver un ejemplo de algo programado de la otra forma para ver si estoy desperdiciando técnicas de programación que hacen al software más potente.
Muchas gracias
Mauricio

[Carlos Miguel FARIAS]

Si tenes 100 procesadores y un disco pedorro, el tiempo total va a depender del disco y no si tenes 100 procesadores.
Cuando se analiza como mejorar el desempeño de un trabajo, hay que analizar todos los factores en juego, no se gana nada con tener multiprocesamiento (se en una maquina o maquinas distribuidas) el cuello de botella va a depender de cual es el elemento mas lento.
Justamente la tecnologia de procesadores RISC se fundamenta en que aún en los calculos "cientificos" la mayor cantidad de tiempo de proceso implica un uso del procesador trivial, y entonces buscan hacer mas rapido lo trivial en lugar de hacer rapido lo complejo.
Salvo casos excepcionales, si tenes una tabla de 5000 registros y mandas cinco hilos para procesar las partes, evidentemente los datos estarian en el mismo disco, por lo que cuando lees registros para un hilo, no podes leer para el otro, por lo que hacerlos por separado, no te beneficia en nada (es mas, forzas al disco a pegar mas saltos de posicionamiento).
Si esos 5000 registros tenes que imprimirlos y tenes una sola impresora, que lo manejes todos juntos o separados, no te sirve de mucho, porque en definitiva el cuello de botella que te fija el tiempo total es la impresora (o el "tu dos pelos" de operador, que se olvida de controlar que no se atasque el papel).

[Marco Plaza]

Hola Miguel, que bueno que podemos discutir acerca de esto..  la memoria caché permite que una vez que se lea la data del disco ésta sea tratata desde memoria, no tiene que ser leída de nuevo ( de hecho muchos han recomendado el flush en algunos casos de pérdida de datos ). Está  el caché del propio disco duro ( la mayoría trae 16 - 32 -64 mb hoy en día ). Por eso es bueno que el servidor de bd no tenga otras aplicaciones corriendo. Existe el caché que implementa el propio motor de Bd ( Vfp o Sql Server etc.. ) para sus operciones.

En Sql Server el indice Clustered mantiene en orden físico los datos por la clave que mas se usa, para recuperar tal vez en una sola vuelta del disco todo el segmento buscado. De hecho ese analisis que haces lo hace Sql Server y con algo llamado nivel de paralelismo, y determina si vale la pena ( y se puede ) ejecutar la lectura y ejecución en paralelo Ej. 5.000 registros de 128 bytes no valdrá la pena, pero si el registro tiene un largo digamos de 1560k y necesitas unir el set de resultados con otro tal vez si, pero como dices es algo que se determina en el plan de ejecución, ( tal vez no hay recursos de memoria o tiempo de cpu disponible ).

En Vfp puedes evitar los 'saltos' si regularmente haces un sort en tus dbfs por la clave primaria. Pero ese es un tema de optimización de el almacenamiento de datos.

En el ejemplo que puse de 5000 registros, seguro que dices bueno 5000 registros se procesan en un abrir y cerrar de ojos.. pero no es la lectura de la data lo que nos preocupa, sino un proceso largo que debamos hacer sobre la misma: Aqui entro con un ej. práctico:

Tenemos un proveedor que nos pone a disposición en su servidor actualizaciones de precios y nuevos productos.

El proveedor pone a nuestra disposición en su servidor:

una tabla con precios tabla pPrecios
una tabla con imagenes tabla pImagenes
una tabla con especificaciones tabla pEspecifica
una tabla con brochures en pdf tabla pPdfs

Queremos:
1-Descargar la imagen y especificaciones en PDF de los  productos nuevos.
2-Descargar un campo XML que contiene tres cursores: especificaciones del producto , presentaciones y no se.. dimesiones
3-Actualizar nuestra lista de precios
4-Enviar a los clientes suscritos la nueva lista de precios y productos por correo.

como ves, eso llevará alguito y no se resuelve solo en el lado del servidor.

Ahora miren esto: resulta que el servidor ( su carga y velocidad de respuesta )  no es uniforme... ahora tarda medio segundo para un registro y otras veces puede devolverme hasta 10 por segundo... pero mi proceso del 1 al 3 tarda 0.25 segundos. No podré aprovechar el momento de rendimiento de mi conexión, solo proceso 4 x segundo. Necesitas abrir 2 procesos, ahí entra el paralelismo. Pero claro no puedes mandar la lista de precios ( paso 4 ) hasta que 1-3 terminen.

Ahí necesitas MtmyVfp o ParallelFox . Son fáciles de usar...Podemos colocar ejemplos de como usar ParallelFox. en español ( los que trae ) y tal vez otros con casos de dia dia para que vean como una aplicación de Vfp puede llevar un logo que diga Habilitado para MultiCore! eso si es traer a Vfp al 2011.!

Saludos.

Marco Plaza

[Marco Plaza]

Hola Mauricio, en el caso de arriba actualmente hariamos algo como:

*-------------------------------
scan
  paso 1
  paso 2
  paso 3
endscan
paso 4
*-----------------------

Ahora, nada me obliga a empezar por el 1 y terminar en 5.000 o viceversa, de hecho no me importa ni siquiera como esta ordenado el set de datos a procesar.

Eso me dice que puedo hacer lo siguiente ( en puro vfp sin usar parallelFox todavía )
( Por favor recuerden que es un ejemplo para exponer el concepto, no voy a optimizar o usar funciones complicadas que devíen la atención. )

Crear un programa con los pasos1 2 y 3 que reciba un parámetro de rango de registros a procesar y compilarlo como un servidor multiproceso.


*******************************************
misProcesosParalelos.prg
*******************************************

DEFINE CLASS funciones as custom olepublic
estado = 0

*---------------------------------------------------------------------------------------------
Function procesarRango ( regDesde as integer, regHasta as integer ) as integer
*---------------------------------------------------------------------------------------------

scan for recno() > regDesde and recno() < regHasta
 paso 1
 paso 2
 paso 3
endscan

estado = 1


endfunc

*----------------------------
function error
*----------------------------
estado = -1

*-----------------------------
enddefine
*-----------------------------

luego en mi programa de vfp original:


digo:

oP1=create('misProcesosParalelos.Funciones')
oP2=create('misProcesosParalelos.Funciones')
oP3=create('misProcesosParalelos.Funciones')

oP1.procesarRango(1,2000)
oP2.procesarRango(2001,3000)
oP3.procesarRango(3001,5000)

pero como sé que terminó cada proceso?
debo interrogar a cada objeto hasta que me devuelva condicion # 0

nPlistos = 0

do while nPlistos # 3

 if oP1 # 0
 ? 'terminó p1!'
 nplistos = nplistos+1
 endif
if oP2 # 0
 ? 'terminó p2!'
  nplistos = nplistos+1
endif
if oP3 # 0
 ? 'terminó p3 '
 nplistos = nplistos+1
endif

enddo

 no voy a echar todo el código aqui.. de  errores y eso.. es el concepto.

Ahora bien todo ese envoltorio de manejo de erorres, estado etc lo hace paralellFox o mtMyvfp fácilmente, no hay que crear nuestros servidores, pues ellos existen de antemano para mandarles a hacer lo que queramos.

Saludos

Marco Plaza

[Mauricio Molinero,]

Este tema es realmente muy amplio y conocer la teoria a fondo puede
llevar mucho tiempo, por eso creo que lo mejor siempre es prueba y
error.
Entonces tomar los procesos mas criticos y ahi probar con paralelismo.

Saludos!

Mauricio R. Molinero,

[Marco Plaza]

	yo(Marco Plaza cambiar)	Publicar respuesta 12:41 (hace 4 minutos)
	Re: [vfp] Re: Multiprocesamiento con VFP Fe de errata en el código: en el scan es >= no > : scan for recno() >= regDesde and recno() <= regHasta donde dice estado es this.estado  y en  if oP1 # 0 debe decir oP1.estado # 0 Saludos Marco Plaza

[Marco Plaza]

Bueno es sólo para dejar una muestra mas de que VPF puede crear sistemas de muy alto rendimiento en equipos de 6 u 8 cpus. Muchas veces creemos que no se puede hacer algo porque Vfp tiene una limitación, o que salió hace mucho y no soporta algunas técnicas de programación.. o que Sql Sever y Oracle o lo que sea se encargarán 'siempre' de todo mejor con SPs ... pero es cosa de estudiar bien la programación misma. Si sabemos realmente donde está el problema, podemos optimizar cada proceso en particular.

Me hace recordar cuando aprendí a jugar Ping-Pong en el colegio. teniamos un amigo de mi hermano mayor que siempre nos ganaba a todos. Y se nos dió por comprar raquetas mas caras, 'es la raqueta', con esa no nos podrá ganar! y compramos entre tres una raqueta cara.. je je .. pero el $#..: cuando nos vió con esa, tomó un cuaderno de clase de pasta dura y se dió el lujo de ganarnos usando un cuaderno del colegio!!! No crean que nos molestó.. nos divertimos mucho y aprendimos una buena lección!

Saludos.

Marco Plaza

[washington Mejia]

Estimado Marco, disculpa que me ria jajajajajajajajajaja

 

Saludos,

Washington

[Luis Mata]

Pero no te molestes pues, jajaja , solo que si algo ya esta hecho porque invertir esfuerzos en recrearlo en otra herramienta, si ese tiempo lo puedes usar en algo mas productivo.

No dudo que VFP, lo puede hacer eso es innegable.. pero hay que ser prácticos.

[Marco Plaza]

Archie creo que voy a una reunión mas tarde..! déjame anotada cual es la parte mas graciosa para echarla como un cuento!! ( no dices cual es ) tal vez te pueda dar enlaces relacionados y pases realmente un buen rato  ! te vas a matar de la risa!! je je  ;-)

Ahora voy saliendo.. !

Saludos.

Marco Plaza

Pd Luis: el prg es solo un esqueleto.. realmente no funciona así ( las llamadas serializadas se bloquearán en espera )  pero explicar los callback y objetos trabajadores es mas largo y complica el punto.

[Mauricio Urquijo]

Hola Marco. Muy buen aporte. Trataré de hacer algunas pruebas con paralellFox porque no sabía ni que existía.

Y cómo bien dice Mauricio Molinero, lo mejor es prueba y error y les voy a compartir algo de la vida real.

Un cliente nuestro (el Instituto Great Place to Work) nos contrató un desarrollo especializado que requiere de muchos cálculos matemáticos. Mandé desarrollar un módulo con la técnica de recursividad porque se requiere de procesamiento de árboles con padres, hijos, nietos, etc....
Aunque el desarrollo funcionaba perfecto me parecía muy lento el proceso. Hace un par de años nos pusimos en la tarea de prueba y error y descubrimos que NO utilizando la recursividad sino utilizando técnicas básicas de programación ganamos un 90% (si, noventa por ciento) de velocidad. Pero algo que me llamó mucho la atención es que a veces la sentencia "calculate cnt() to" era mucho más veloz que usar sentencias select * from ...
Desde ese día nuestro cliente respeta mucho más a VFP ;)

Saludos
Mauricio U
PS: Muchas gracias a todos por lo compartido.