> 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
