... acerca de no usar memoria al divino boton, asi es que hice que el GC comun en VisualWorks funcione hasta 35% mas rapido... importa, e importa muchisimo.
2011/6/27 Andres Valloud <[email protected]>: >> Buenio GemStone no es open source, de modo que no sabemos cómo implementa >> las transacciones. > > Si bueno, Oracle y Windows tampoco son open source, no se que tiene que ver. > >> En el caso de las bases de datos relacionales, todos los objetos "tocados" o >> "vistos" por una transacción son considerados como bloqueados o versionados, >> dependiendo del modo en que la base de datos logra la sincronización. >> imagino que GemStone podría hacer lo mismo con los objetos que viven dentro >> de su imagen (de todas formas uno podría considerar que una base de datos >> relacional también es una VM con objetos viviendo dentro, si al fin y al >> cabo una BD relacional requiere de un proceso activo en RAM al igual que una >> VM). > > En vez de imaginar, creo que es mejor que mires GemStone :). > >> Claro de 10 a 100 veces más lento, pero por otro lado, ¿cuál es el objetivo >> de una BD local? Desde hace 15 años que todas las BD son remotas con la >> tecnología cliente/servidor. > > Pero no estabamos hablando de una BD local... el tema es que la > comunicacion via sockets y que se yo ya esta implementada, se llama > GemStone. Tambien podes usar la version que ni siquiera tiene base de > datos, se llama GemFire. > > La cuestion es que, para una imagen con varios object spaces, esta > mejor no usar sockets porque estas asumiendo que todos los object > spaces estan en el mismo address space (basicamente). > >> Pero casi todo lo que hacemos "serializa". Hoy en día hasta mandar fotos de >> un dispositivo celular es rápido y supongo que en 10 años más hasta enviar >> video por celular será rápido. > > Si, y es lento. Por supuesto esta bueno hacer que el software sea > ineficiente asi necesitas un procesador mas rapido blah blah blah... > >> Creo que depende de la aplicación que estemos hablando. Incluso supongo que >> uno podría tener objetos "siempre serializados" de mod oque el caso de uso >> más común, serializar, sea rápido, mientras que lo menos común y que menos >> demora, hacer cálculos internos, tenga que recorrer el objeto serializado >> para hacer el cálculo. Puedo estar equivocado, pero la RAM será tan barata >> que mantener los objetos con ambas representaciones "serializado y no >> serializado" debería ser barato también. > > Acordate que en los CPUs de hoy en dia, importa un monton no usar > memoria al divino boton porque acceder RAM es lentisimo comparado con > los caches etc. > >>> > Separar dentro de una misma VM varios espacios de objetos me parece >>> > innecesariamente complejo. >>> >>> Si queres hacer un fork, crear otro thread seria mucho mas rapido que >>> levantar otro proceso de maquina virtual. >> >> MMmhh, sí eso ví en el paper que mandaron. Se ve genial. Ahora bien crear un >> thread es llamar a createThread y crear un nuevo proceso es llamar a fork(). >> Fork es más caro, pero siempre puedes llamar a vfork() que es tan rápido >> como createThread. > > Nono, no fork(), fork de Smalltalk. Y llamar a fork() / vfork() sera > rapidisimo y todo lo que quieras, pero inicializar una VM tarda tiempo > asi que la latencia para cosas rapidas que se benefician al usar > multicore seria un problema serio. Empezar otro thread JIT > (basicamente) es muchisimo mas rapido que levantar una VM desde cero. > > Andres. > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
