2011/6/27 Andres Valloud <[email protected]> > > ¿Y cómo determinas cuando lso JIT pueden correr en paralelo y cuando no? > > Una manera trivial de hacer eso sería tener varias VMs corriendo > > simultáneamente y comunicarlas mediante sockets. > > Si, tan trivial que se llama GemStone y existe hace ~25 años. Si esto > es en la misma maquina, podes usar memoria shareada con transacciones > y asi no tenes que usar TCP/IP... >
Buenio GemStone no es open source, de modo que no sabemos cómo implementa las transacciones. 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). > > > Por ejemplo tener una VM > > para el filesystem, una para la pantalla, otra para los dispositivos, > otra > > para cada aplicación, etc. Cuando quieres comunicarlas, necesariamente > > invocan a otra que recibe mensajes mediante sockets. La ventaja de los > > sockets es que naturalmente funcionan como una cola y serializan los > > mensajes desde el punto de vista del receptor. > > La desventaja es, me parece, el throughput, el overhead de usar TCP/IP > en vez de (esencialmente) memcpy() 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. Si lo que quieres es tener tecnología cliente/servidor pero con la velocidad de un servidor local, debes usar cachés, buffers, etc. Eso lo hacen los drivers de BD de todas maneras. (y acordate de la fragmentacion de > paquetes, blah blah blah), Eso es como de principios de los 90's. Hoy en día es normal tener en tu casa 6 Gb. En 10 años más será normal bajar películas "on demand". y tener que serializar todo. Si tenes > memoria shareada, entonces no hay que serializar. 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. Serializar y > des-serializar es costoso. > > 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. > 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. > > 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 > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
