por eso preguntaba... aparentemente voy a usar C++ que creo que es lo mas indicado, al menos para la parte de calculos intensivos. por eso estoy bajando de un muy alto nivel a algo mas cerca de la maquina, porque una de las funciones me tarda casi 4 hs... de 3meses que tardaba antes de optimizarla todo lo que te permite vba de access. y ahora que estoy pensando reescribir toda la aplicacion, quiero hacerla en algun lenguaje potente en cuando a calculos de enteros, y que sea portable, multihilo y esas cosas. vamos, si lo voy a reescribir, lo quiero hacer bien desde el inicio java por lo que vi, no me da la impresion que tenga tanta potencia como para lo que quiero. de ultima la parte de interfase si la hago en java o algo similar... pero la parte de calculos creo que deberia ir en C, C++, C# o algun sabor distinto de "C" use access en su momento porque empezo con 6 tablas de 20 campos de 0 a 99, y unos 100 registros y poquitas lineas... y era el lenguaje mas rapido y facil para hacerlo las base de datos bien podrian ser archivos de texto plano... la interfase son unos 20 formularios/ventanas maximo... tampoco es tanta cosa el tema es la funcion que procesa los datos. necesito que sea lo mas rapido y que aproveche lo maximo los recursos. si me lleva 2 años de aprender el lenguaje y gano un porcentaje importante de rendimiento, es viable ************* Un sistema en Access es algo de muy alto nivel. C es una de las peores elecciones que podrias hacer en este caso. Mi recomendacion en base a mi experiencia seria que utilizaras Qt con C++ que tiene la GUI , base de datos (inclyendo sqlite) y lo que necesitas, o aun mejor Qt con Ruby, que hara el ambiente mas productivo. O incluso probar Qt con Java (Jambi). Con Qt funcionaria en Mac Linux y Windows, y es todo GPL (el unico problema seria si quieres redistribuir la aplicacion bajo una licencia no libre). Tambien esta http://gambas.sourceforge.net/ que es un ambiente muy similar a Visual Basic, sin embargo su estado en Windows es bastante malo. Luego tienes otras opciones de menor calidad: Gtk con glade, accesibles desde Python, Ruby, C++ (muy baja calidad), y Mono/.NET que funciona bastante bien combinado con Gtk. La otra opcion por supuesto es Java (sin Jambi) con SWT o Swing. En http://uic.sourceforge.net/ hay un compilador que convierte los forms hechos con Qt designer a Swing. Olvidate de C para ese tipo de aplicaciones. C++ y Java no tienen ningun problema con calculos pesados. Muchas veces el problema de la lentitud no esta en el lenguaje sino en el codigo que no esta optimizado. --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

en realidad la base de datos me tiene sin cuidado en el peor caso se lleva 0,5% del tiempo, asi que va a ser por "features" y no "speed" por lo que dices, posgres ----- Original Message ----- From: "Juan Erbes" To: "Juan Fogelman (JGustavo)" Cc: Sent: Monday, September 17, 2007 8:05 PM Subject: Re: [opensuse-es] eleccion de entorno de programacion Con respecto a la programación, no estoy del todo al dia, pero lo que dijo Duncan parece bastante claro. Queda pendiente el tema db, que hasta donde se, el sistema mas completo lo vas a encontrar en postgresql, e incluso por allí hay algunos utilitarios en access, para volcar la db desde access a postgres. Es cierto que en general postgres tiene la fama de no ser tan rapida como mysql, pero tiene muchos componentes como triggers y otros que mysql no tiene. Salu2 El 12/09/07, Juan Fogelman (JGustavo) escribió:

por eso preguntaba... aparentemente voy a usar C++ que creo que es lo mas indicado, al menos para la parte de calculos intensivos. por eso estoy bajando de un muy alto nivel a algo mas cerca de la maquina, porque una de las funciones me tarda casi 4 hs... de 3meses que tardaba antes de optimizarla todo lo que te permite vba de access.

y ahora que estoy pensando reescribir toda la aplicacion, quiero hacerla en algun lenguaje potente en cuando a calculos de enteros, y que sea portable, multihilo y esas cosas. vamos, si lo voy a reescribir, lo quiero hacer bien desde el inicio java por lo que vi, no me da la impresion que tenga tanta potencia como para lo que quiero.

de ultima la parte de interfase si la hago en java o algo similar... pero la parte de calculos creo que deberia ir en C, C++, C# o algun sabor distinto de "C" use access en su momento porque empezo con 6 tablas de 20 campos de 0 a 99, y unos 100 registros y poquitas lineas... y era el lenguaje mas rapido y facil para hacerlo

las base de datos bien podrian ser archivos de texto plano... la interfase son unos 20 formularios/ventanas maximo... tampoco es tanta cosa el tema es la funcion que procesa los datos. necesito que sea lo mas rapido y que aproveche lo maximo los recursos. si me lleva 2 años de aprender el lenguaje y gano un porcentaje importante de rendimiento, es viable

************* Un sistema en Access es algo de muy alto nivel. C es una de las peores elecciones que podrias hacer en este caso.

Mi recomendacion en base a mi experiencia seria que utilizaras Qt con C++ que tiene la GUI , base de datos (inclyendo sqlite) y lo que necesitas, o aun mejor Qt con Ruby, que hara el ambiente mas productivo. O incluso probar Qt con Java (Jambi). Con Qt funcionaria en Mac Linux y Windows, y es todo GPL (el unico problema seria si quieres redistribuir la aplicacion bajo una licencia no libre).

Tambien esta http://gambas.sourceforge.net/ que es un ambiente muy similar a Visual Basic, sin embargo su estado en Windows es bastante malo.

Luego tienes otras opciones de menor calidad: Gtk con glade, accesibles desde Python, Ruby, C++ (muy baja calidad), y Mono/.NET que funciona bastante bien combinado con Gtk.

La otra opcion por supuesto es Java (sin Jambi) con SWT o Swing. En http://uic.sourceforge.net/ hay un compilador que convierte los forms hechos con Qt designer a Swing.

Olvidate de C para ese tipo de aplicaciones. C++ y Java no tienen ningun problema con calculos pesados. Muchas veces el problema de la lentitud no esta en el lenguaje sino en el codigo que no esta optimizado.

--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org E-mail clasificado por el Idenfificador de Spam Inteligente. Para modificar la categoría clasificada acceda a su webmail Este mensaje ha sido verificado por el E-mail Protegido. Antivirus Actualizado en 17/09/2007 / Versión: 5.1.00/5121 __________ Información de NOD32, revisión 2535 (20070917) __________ Este mensaje ha sido analizado con NOD32 antivirus system http://www.nod32.com --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

PD: no sabía que nod32 viene para Linux!

no, si mientras que este calculando con este sistema, estoy bastante atado a windows. por suerte solo en esta pc. ahora luego de migrar a VB desde access puedo usarlo en una pc virtual, por suerte... porque me van a dar los tiempos igual. luego a medida que puedo programar y hacerlo multiplataforma, voy a dejar de necesitar esta cosa. --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org

El mié, 12-09-2007 a las 16:30 -0300, Juan Gustavo Fogelman escribió:

Una cosa es acceder y otra es calcular, si tienes un servidor donde se realizan los calculos, el acceso se puede hacer desde cualquie sistema si lo haces bien.

Si los resultados pueden tirarse a un archivo, yo dividiria el problema en dos. El servidor que calcula y el cliente para introduccion de datos y consulta de resultados.

de todas maneras los datos los cargo en matrices en memoria para agilizar el codigo.

Si los datos los cargas de una vez en memoria, no influira demasiado como se almacenen.

estoy usando enteros (2bytes) por campo. pero probe usar 8bytes por campo y el rendimiento fue de 100segundos mas, que en 4hs es despreciable asi que creo que mysql

Las maquinas actuales te daran mejor rendimiento usando los tipos basicos de la CPU Para una maquina de 32 bits usa enteros de 32 bits, para una de 64 usa 64, el compilador se ahorrara algunas instrucciones.

No me mandes codigo, eso solo representa el esfuerfo de entender como ves tu el sistema. Si quieres y puedes mandame mas descripciones para que pueda entender el problema, sin condicionarme con tu punto de vista. -- Saludos Lluis

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-09-12 a las 21:56 +0200, lluis escribió:

...

estoy usando enteros (2bytes) por campo. pero probe usar 8bytes por campo y el rendimiento fue de 100segundos mas, que en 4hs es despreciable asi que creo que mysql

Las maquinas actuales te daran mejor rendimiento usando los tipos basicos de la CPU

Para una maquina de 32 bits usa enteros de 32 bits, para una de 64 usa 64, el compilador se ahorrara algunas instrucciones.

Mmmm... no estoy seguro yo de eso. De hecho, en los procesadores que conozco por dentro, no es cierto. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG6FWStTMYHG2NR9URAvNmAJ4r5+Wg02xRxOVNmQ1OivHpGpLYwgCfYYRo iNvz4yGuUVcAlMJp8LDZyMA= =H0Hg -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-09-13 a las 20:23 +0200, lluis escribió:

...

Mmmm... no estoy seguro yo de eso. De hecho, en los procesadores que conozco por dentro, no es cierto.

Para un PC no me atrevo a juratelo, no me he mirado codigo desensamblado.

Para un hitachi SH2 de 32 bits se observa que cuando carga datos mas cortos( p.e. 16 bits) tiene que realizar la extension de signo.

Si puedes confirmar como lo hace Intel cuentamelo, es un detalle bueno de saber.

¡El signo! No se me había ocurrido pensar en eso. Ya... pero eso es porque cargas 16 bits pero usa un registro de 32, con lo que tiene que extenderlo. Entiendo... No, yo pensaba en el Motorola 68000: la duración de la instrucción de carga en ciclos de reloj es constante, o sea, independiente del dato. Y además, los registros de la cpu se pueden usar como de 8, 16 o 32 bits directamente (es big-endian). Pero existe la instrucción para extender el signo (ext). Lo que pasa es que al programar en assembler pues usas el registro como word y punto. No me había planteado que es lo que hace un compilador... A ver, instrucción ADD, suma binaria. ADD.s <ea>,Dn ADD.s Dn,<ea> ... where .s= .B, .W, or .L ... Condition codes: N set if result is negative, cleared otherwise Vale, pues la instrucción ADD puede trabajar directamente con un byte, independiemente del signo. Usa representación tipo "complemento a dos", con lo que la instrucción es la misma sea un entero con signo o sin el. Y repasando mi notas, veo que para decimales (bcd) implementa suma y extensión en una única operación (ABCD). También existe ADDX, add binary with extend, que creo que hace falta cuando se mezclan sumas de tamaños distintos en los operandos. O sea, en el caso del 68000 no se pierde tiempo por usar números de 16 bits. Pero no tengo una CPU de esas para probar :-( Intel... ¡Pues me pones en dudas! No lo se. A ver, wikipedia: http://en.wikipedia.org/wiki/Sign_extension In the x86 instruction set used by the main microprocessors of all common PCs, sign extension is done by the instructions cbw, cwd, cwde, and cdq ("convert byte to word", "c. word to doubleword", "c. w. to extended dw.", and "c. dw. to quadword", respectively; in the x86 context, a byte has 8 bits, a word 16 bits, a doubleword and extended doubleword 32 bits, and a quadword 64 bits). - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG6ZU4tTMYHG2NR9URApwMAKCIGBr4LIn3N7Jxnlo/PO9LexX1pQCdFEI1 y4dsK9c+JdACYG0zWwkl/BI= =e9tt -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-09-13 a las 23:38 +0200, lluis escribió:

El jue, 13-09-2007 a las 21:53 +0200, Carlos E. R. escribió:

...

O sea, en el caso del 68000 no se pierde tiempo por usar números de 16 bits. Pero no tengo una CPU de esas para probar :-(

Bueno, vale pero del 68000 hace unos años. Ademas, Motorola para mi gusto esta mejor.

Era muy fácil de programar. E imagino que tendrá sucesores de parecida programación.

En la epoca que nacio el 68000 yo era el soporte tecnico para Microprocesadores( solo teniamos los de Motorola) en Hispano Electronica Barcelona( Hispano era distribuidor exclusivo).

¡Vueltas que da la vida! :-) Pero yo no estaba en España cuando lo usaba.

Lo unico que tengo a medias, solo como curiosidad, es intentar implementar un 68000 en una FPGA

¿Es posible hacer eso? Ondiá.

Hay algo medio hecho en Opensources, a lo mejor tendre que dejarlo hasta que me jubile.

¿No hay ningún emulador en software? La verdad es que no lo he mirado, pero creo que hay un proyecto/s de emulador en linux. A ver, que miro... ] QEMU is an extremely well-performing CPU emulator that allows you to ] choose between simulating an entire system and running userspace ] binaries for different architectures under your native operating ] system. It currently emulates x86, ARM, PowerPC and SPARC CPUs as well ] as PC and PowerMac systems. Ah, mira este: ] ARAnyM is a multiplatform virtual machine (a software layer) for ] running Atari ST/TT/Falcon TOS/GEM applications on any hardware with ] many host operating systems. The reason for writing ARAnyM is to ] provide Atari power users with faster and better machines. The ultimate ] goal is to create a new platform where TOS/GEM applications could ] continue to live forever. ] ] Features: ] ] * 68040 CPU (including MMU040) pero no es un emulador de cpu. ] Mac-On-Linux lets you run MacOS under LinuxPPC on PowerPC based ] machines. Because it runs natively on the processor, it is very fast. ] Unlike most Mac emulators, Mac-on-Linux runs MacOS 8.6 and later ] WITHOUT A ROM IMAGE*. To run earlier versions, a ROM image is probably ] needed. arnold ] This is arguably the best Amstrad CPC emulator around. It is able to ] recreate the Amstrad models CPC 464/664/6128, 464+/6128+, and the VEB ] Mikroelektronik model KC Compact. ] Snes9x is a portable, freeware Super Nintendo Entertainment System ] (SNES) emulator. It basically allows you to play most games designed ] for the SNES and Super Famicom Nintendo game systems on your PC. ] ] Additionally, this package contains snes9express, a graphical front-end ] making the use of snes9x a lot less difficult. ] Hatari is the Linux port of WinSTon, an Atari ST emulator for Windows. Y ya me he cansado de mirar :-)

Encantado de encontrar un fan del 68000.

Fué poco tiempo, pero me encantó ese micro. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFG6cJQtTMYHG2NR9URAk/nAJ4//015s/hntrfAXKlyiTZfTUmAjgCdEGZA jeUk41iZ9CbPupSALVfC9F0= =R7Ld -----END PGP SIGNATURE-----

Ya que estamos en el tema de BBDD y memoria. Ahora se está poniendo de moda las BBDD en memoria. Un poco más arriba decías que no es obligatorio el uso de BBDD y también dices que cargas las matrices en memoria. Pues pergunta, ¿has probado a crear un RAM disk y cargar todos los ficheros en RAM y trabajar desde RAM? Ventajas -> rapidísimo Inconveniente -> si se va la luz ... pierdes lo que tenías en RAM Para "medio-solventar" lo de la pérdida de datos, se puede hacer que copie los ficheros a disco cada poco tiempo, por ejemplo. Más cosas a tener en cuenta, tu aplicación es intensiva de: ¿CPU? ¿RAM? ¿I/O? ¿Bus? Lo digo porque si por sw has pasado de 3 meses a 4 horas, a lo mejor no lo puedes estrujar más vía sw, pero vía hw sí. A lo mejor ampliando RAM consigues darle un buen empujón. Piénsalo: es más barato añadir hw que horas de programación. OJO!! No quiero decir que cuando haya problemas se compre más hardware siempre. Sólo digo que es más barato y que a veces el código ya está optimizado y se puede hacer poco desde el punto de vista sw. ************** al principio era muy dependiente de I/O lo solucione pasando de una sola vez todas las tablas a matrices. ahora no es mas dependiente de I/O probe primero con el raid de raptor 2x74 raid0 eso ayudo muchisimo... luego con ramdrive, eso ayudo tambien muchisimo... luego por ultimo probe de pasar desde el raid a matrices y se termino el problema I/O tengo un c2q con 4GB de ram... estoy tirando 4 instancias de access simultaneas, para aprovechar los 4 cores. con 1,2GB de ram me sobra, incluso para tener todas las tablas en matrices. asi que voy a sacar 2GB y dejarlo para usar en un sistema de 32bits, que va algo mas rapido, con access claro... en este momento, creo, tira mas que nada de cpu y cache. trate de armar los bucles para que entren dentro de una cache de 1MB. en un amd64 de 1MB por nucleo va casi 3 veces mas rapido que en uno de 512K por nucleo. en un C2duo esta de fiesta. la velocidad de memoria no es importante. probe de poner la memoria en single channel en 400, en vez de dual channel en 800 y el rendimiento bajó 5% si se corta la luz, tengo ups... y aparte las tablas se leen una vez y solo se genera un registro con 5000 campos... todo lo demas es almacenamiento temporal, para ayudar a hacer los calculos que siguen. el tema es que quiero dejar access y pasar a algo mas efectivo, y no tan de alto nivel... se nota que esta pensado para ser facil, pero de eficiente nada. voy a ir por partes... esto me va a llevar un año largo pasar todo... asi que he optado por ir por partes primero lo paso todo a VB que es rapido de migrar, y me va a dar un 80% mas de rendimiento, asi por las pruebas preliminares y de a poco voy armando las funciones mas pesadas en C o C++. en C por lo poco que pude simular, tengo 3 veces el rendimiento que en VB... asi que estaria multiplicando por 5 mas o menos el rendimiento total. de todas maneras, hay partes que en C se pueden optimizar muchisimo, porque me da la opcion de procesar varios datos por sse en un ciclo de reloj. cuando termine eso, ya lo tendria casi casi listo para compilar para el sistema que sea, al menos la parte de calculos. y ahi recien podre ponerlo multiplataforma. yo queria hacerlo multiplataforma ya, pero es que no puedo sacarlo de produccion. Gracias a todos por su ayuda. me dejaron las cosas mucho mas claras de lo que hacer... porque me fueron tirando pequeñas cosas que me hicieron ver el problema en una forma mas amplia, y creo que pude encontrar la mejor solucion ahora es solo cuestion de tiempo para programarlo- --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org