Consulta sobre uso de memoria y performance en arrays en VW

> Consulta: tengo que diseñar un objeto que va a trabajar con una matriz
> de bits. Para la matriz de bits planeo usar un bytearray subyacente,
> usando máscaras para setear/leer los bits. Ahora bien, conviene usar un
> solo array (potencialmente gigante) o una array de arrays? Mi
> preocupación tiene obviamente que ver con el GC y la forma en la que VW
> maneja los objetos pesados.
>
> Un poco de contexto:
> - Las matrices pueden ser de diversos tamaños y no sería extraño algo
> tipo 1000x1000 (o sea que no sería loco pensar en un byte array de 250K).
> - Es posible que se creen y destruyan muchas matrices durante el proceso
> de cómputo (y honestamente preferiría no tener que limpiar y cachear a
> mano).
>
> En principio me incliné por un array de arrays, me parece mas fácil a la
> hora de manejar chunks de memoria, pero por otro lado los objetos tipo
> Image están implementados con un byte array gigante y ahí me surgió la
> duda. Alguien hizo algún tipo de benchmarking en el tema de
> alocar/desalocar objetos de esos tamaños?
>
> --
> Saludos y gracias,
>        Andrés
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

> Consulta: tengo que diseñar un objeto que va a trabajar con una matriz
> de bits. Para la matriz de bits planeo usar un bytearray subyacente,
> usando máscaras para setear/leer los bits. Ahora bien, conviene usar un
> solo array (potencialmente gigante) o una array de arrays? Mi
> preocupación tiene obviamente que ver con el GC y la forma en la que VW
> maneja los objetos pesados.
>
> Un poco de contexto:
> - Las matrices pueden ser de diversos tamaños y no sería extraño algo
> tipo 1000x1000 (o sea que no sería loco pensar en un byte array de 250K).
> - Es posible que se creen y destruyan muchas matrices durante el proceso
> de cómputo (y honestamente preferiría no tener que limpiar y cachear a
> mano).
>
> En principio me incliné por un array de arrays, me parece mas fácil a la
> hora de manejar chunks de memoria, pero por otro lado los objetos tipo
> Image están implementados con un byte array gigante y ahí me surgió la
> duda. Alguien hizo algún tipo de benchmarking en el tema de
> alocar/desalocar objetos de esos tamaños?
>
> --
> Saludos y gracias,
>        Andrés
>
> --
> To post to this group, send email to [hidden email]
> To unsubscribe from this group, send email to
> [hidden email]
>
> http://www.clubSmalltalk.org

> Agranda large space (fijate en ObjectMemory class>>sizesAtStartup)
> para que esos objetos enormes siempre entren ahi.  Para mas
> informacion, bajate VW 7.7.1 y lee doc/technotes/vwmemorymgmt.pdf.
> Tambien podes usar el package MemoryMonitor en el public store
> repository para ver lo que anda sucediendo.  Acordate que hoy (pero no
> mañana, eh? :)...) el GC no mueve objetos a large space si se cayeron
> a old space.
>
> Andres.
>
> 2010/10/21 andres <[hidden email]>:
>> Consulta: tengo que diseñar un objeto que va a trabajar con una matriz
>> de bits. Para la matriz de bits planeo usar un bytearray subyacente,
>> usando máscaras para setear/leer los bits. Ahora bien, conviene usar un
>> solo array (potencialmente gigante) o una array de arrays? Mi
>> preocupación tiene obviamente que ver con el GC y la forma en la que VW
>> maneja los objetos pesados.
>>
>> Un poco de contexto:
>> - Las matrices pueden ser de diversos tamaños y no sería extraño algo
>> tipo 1000x1000 (o sea que no sería loco pensar en un byte array de 250K).
>> - Es posible que se creen y destruyan muchas matrices durante el proceso
>> de cómputo (y honestamente preferiría no tener que limpiar y cachear a
>> mano).
>>
>> En principio me incliné por un array de arrays, me parece mas fácil a la
>> hora de manejar chunks de memoria, pero por otro lado los objetos tipo
>> Image están implementados con un byte array gigante y ahí me surgió la
>> duda. Alguien hizo algún tipo de benchmarking en el tema de
>> alocar/desalocar objetos de esos tamaños?
>>
>> --
>> Saludos y gracias,
>>        Andrés
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>

> Ah... si usas el array de arrays, para bytearrays y otras colecciones
> que no apuntan a otros objetos entonces te conviene usar un solo array
> porque si no vas a tener que hacer dos at: en vez de uno.
>
> 2010/10/21 andres <[hidden email]>:
>> Consulta: tengo que diseñar un objeto que va a trabajar con una matriz
>> de bits. Para la matriz de bits planeo usar un bytearray subyacente,
>> usando máscaras para setear/leer los bits. Ahora bien, conviene usar un
>> solo array (potencialmente gigante) o una array de arrays? Mi
>> preocupación tiene obviamente que ver con el GC y la forma en la que VW
>> maneja los objetos pesados.
>>
>> Un poco de contexto:
>> - Las matrices pueden ser de diversos tamaños y no sería extraño algo
>> tipo 1000x1000 (o sea que no sería loco pensar en un byte array de 250K).
>> - Es posible que se creen y destruyan muchas matrices durante el proceso
>> de cómputo (y honestamente preferiría no tener que limpiar y cachear a
>> mano).
>>
>> En principio me incliné por un array de arrays, me parece mas fácil a la
>> hora de manejar chunks de memoria, pero por otro lado los objetos tipo
>> Image están implementados con un byte array gigante y ahí me surgió la
>> duda. Alguien hizo algún tipo de benchmarking en el tema de
>> alocar/desalocar objetos de esos tamaños?
>>
>> --
>> Saludos y gracias,
>>        Andrés
>>
>> --
>> To post to this group, send email to [hidden email]
>> To unsubscribe from this group, send email to
>> [hidden email]
>>
>> http://www.clubSmalltalk.org
>

> Buenasssss...
>
> 2010/10/21 andres <[hidden email]>:
>> Que hacés Valloud, sabía que ibas a responder :).
>
> Pero como se te ocurre semejante cosa!??!?!... jajajaja!!!
>
>> No se si cambió algo en 7.7.1 (estoy con 7.6 por ahora),
>
> Y, mas o menos... basicamente reimplemente MemoryPolicy.  Fijate en el
> doc de 7.7.1 porque ese archivo tambien esta re-escrito...
>
>> Ahora, desde el punto de vista teórico, que debería suceder?
>
> Si los objetos esos se quedan en large space, entonces el compacting
> GC (o el data compactor) no los tiene que andar moviendo de aca para
> alla.
>
>> Digo, así uno
>> aprende un poco mas sobre el GC. Recuerdo en algunas cosas que implementé
>> que VW andaba como piña en eso de reusar objetos "muertos" del mismo tamaño
>> (lease, dejar de referenciar un array de 10 slots y crear uno nuevo de ese
>> tamaño era mas barato que cachearlo a mano, cosa que me sorpendió bastante).
>
> Puede ser, pero si eso sucede demasiado frecuentemente entonces hay
> que contabilizar el costo del scavenge y del IGC para boletear el
> objeto viejo.
>
>> La pregunta es, eso funca igual en large space? En las pasadas de scavenge
>> del GC hasta debería ser mas rápido un array solo (ya que sólo queda el
>> header en eden/survivor) lo que me da un poco de miedo es que se termine
>> llamando al compacting gc muchas veces por la creación de muchas matrices.
>
> Pero eso va a suceder solo si empezas a usar mucho old space, con lo
> que si large space es suficientemente grande, listo.
>
> Dicho sea de paso, la configuracion por defecto de 7.7.1 es muchisimo
> mejor que todo lo anterior por dos razones.  Primero, no hay mas
> colgazos de la VM porque MemoryPolicy no cumple sus responsabilidades
> (principalmente: asegurarse de que el scavenge siempre es posible),
> tampoco hay memory emergencies que no son tales, y si el IGC aborta
> entonces el IGC ahora puede recuperarse (fijate referencias a los
> simbolos #aborted y #aborting).  Segundo, tu amigo tocayo se gasto
> escribiendo tests y otras yerbas, con los cuales el susodicho optimizo
> la configuracion por defecto en terminos de velocidad.  Por ejemplo,
> antes de todo este trabajo los stress tests terminaban en ~2.25 horas
> (si terminaban, claro).  Ahora terminan en ~20 minutos...
>
> En fin.  De esto y otras cosas trata mi propuesta de charla para
> Smalltalks 2010.  Vamos a ver si me meto en el schedule, las charlas
> que hay son grosas.  Ya sabes como es esto, no hay hijo del vecino que
> valga...
>
> Andres.
>