X-Git-Url: https://git.llucax.com/z.facultad/75.00/informe.git/blobdiff_plain/f3c0d6f79b1e27d7ac81c981c937482886ab630f..93304243d72347314f0d9c402a0632ab50550016:/source/solucion.rst?ds=sidebyside diff --git a/source/solucion.rst b/source/solucion.rst index 22cfd8e..fe9086b 100644 --- a/source/solucion.rst +++ b/source/solucion.rst @@ -1,6 +1,6 @@ .. Acá va lo que decidí hacer en base al análisis anterior y sus razones. - ESTADO: EMPEZADO + ESTADO: TERMINADO .. _solucion: @@ -8,13 +8,13 @@ Solución adoptada ============================================================================ -Como hemos visto en :ref:`dgc_bad`, la mejora del recolector de basura puede -ser abordada desde múltiples flancos. Por lo tanto, para reducir la cantidad -de posibilidades hay que tener en cuenta uno de los principales objetivos de -este trabajo: encontrar una solución que tenga una buena probabilidad de ser -adoptada por el lenguaje, o alguno de sus compiladores al menos. Para asegurar -esto, la solución debe tener un alto grado de aceptación en la comunidad, lo -que implica algunos puntos claves: +Como hemos visto en :ref:`dgc`, la mejora del recolector de basura puede ser +abordada desde múltiples flancos, con varias alternativas viables. Por lo +tanto, para reducir la cantidad de posibilidades hay que tener en cuenta uno +de los principales objetivos de este trabajo: encontrar una solución que tenga +una buena probabilidad de ser adoptada por el lenguaje, o alguno de sus +compiladores al menos. Para asegurar esto, la solución debe tener un alto +grado de aceptación en la comunidad, lo que implica algunos puntos claves: * La eficiencia general de la solución no debe ser notablemente peor, en ningún aspecto, que la implementación actual. @@ -798,7 +798,9 @@ Caché de ``Pool.findSize()`` Se crea un caché de tamaño de bloque para el método ``findSize()`` de un *pool*. Esto acelera considerablemente las operaciones que necesitan pedir el tamaño de un bloque reiteradamente, por ejemplo, al añadir nuevos elementos -a un arreglo dinámico. +a un arreglo dinámico. En esencia es una extensión a una de las optimizaciones +propuestas por Vladimir Panteleev [PAN09]_, que propone un caché global para +todo el recolector en vez de uno por *pool*. Esta mejora tampoco afecta a la corrección del algoritmo, ya que nuevamente no afecta su comportamiento a nivel lógico, solo cambia detalles en la @@ -1082,18 +1084,14 @@ recolector. Marcado preciso ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -En paralelo con este trabajo, David Simcha comienza a explorar la posibilidad -de agregar precisión parcial al recolector, generando información sobre la -ubicación de los punteros para cada tipo [DBZ3463]_. Su trabajo se limita -a una implementación a nivel biblioteca de usuario y sobre `D 2.0`_. -Desafortunadamente su trabajo pasa desapercibido por un buen tiempo. +Para agregar el soporte de marcado preciso se aprovecha el trabajo realizado +por Vincent Lang (ver :ref:`dgc_via_art`) [DBZ3463]_, dado que se basa en `D +1.0`_ y Tango_, al igual que este trabajo. Dado el objetivo y entorno común, +se abre la posibilidad de adaptar sus cambios a este trabajo, utilizando una +versión modificada de DMD_ (dado que los cambios aún no son integrados al +compilador oficial). -Luego Vincent Lang (mejor conocido como *wm4* en la comunidad de D_), retoma -este trabajo, pero modificando el compilador DMD_ y trabajando con `D 1.0`_ -y Tango_, al igual que este trabajo. Dado el objetivo y entorno común, se abre -la posibilidad de adaptar los cambios de Vincent Lang a este trabajo, -utilizando una versión modificada de DMD_ (dado que los cambios aún no son -integrados al compilador oficial). +.. TODO: Apéndice con parches a DMD y Tango? Información de tipos provista por el compilador ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -1379,11 +1377,12 @@ que la memoria sea compartida entre los procesos de forma explícita. Esto, sin embargo, no significa que la memoria física sea realmente duplicada; en general todos los sistemas operativos modernos (como Linux_) utilizan una -técnica llamada *copy-on-write* (*copiar-al-escribir* en castellano) que -retrasa la copia de memoria hasta que alguno de los dos procesos escribe en un -segmento. Recién en ese momento el sistema operativo realiza la copia de **ese -segmento solamente**. Es por esto que la operación puede ser muy eficiente, -y la copia de memoria es proporcional a la cantidad de cambios que hayan. +técnica llamada *COW* (de *copy-on-write* en inglés, *copiar-al-escribir* en +castellano) que retrasa la copia de memoria hasta que alguno de los dos +procesos escribe en un segmento. Recién en ese momento el sistema operativo +realiza la copia de **ese segmento solamente**. Es por esto que la operación +puede ser muy eficiente, y la copia de memoria es proporcional a la cantidad +de cambios que hayan. :manpage:`fork(2)` tiene otra propiedad importante de mencionar: detiene todos los hilos de ejecución en el proceso hijo. Es decir, el proceso hijo se crear @@ -2152,67 +2151,6 @@ para evaluar el este efecto en los resultados, siempre que sea posible se analizan los resultados de un gran número de corridas observando principalmente su mínima, media, máxima y desvío estándar. -.. Tamaño del ejecutable (XXX: SEGUN LAS PRUEBAS NO FUCKING CAMBIA!!!) - El tamaño del ejecutable es un factor importante. Cuanto más grande es el - ejecutable, más parecieran variar los resultados. Por ejemplo se observa un - incremento de la estabilidad de los resultados al eliminar toda información - de depuración (*debug*) del ejecutable, utilizando el comando - :manpage:`strip(1)` (*stripped*). En el cuadro :vref:`t:sol-exesize-tbgc` - se puede ver la reducción del tamaño del ejecutable para TBGC cuando se - elimina la información de depuración (4.25 veces más chico en promedio), - mientas que en el cuadro :vref:`t:sol-exesize-cdgc` se puede ver CDGC (4.6 - veces más chico en promedio). - .. ftable:: t:sol-exesize-tbgc - Reducción del tamaño del ejecutable para TBGC. - ======== ======== ======== ============== - Nombre Debug Stripped Debug/Stripped - ======== ======== ======== ============== - bh 586517 138060 4.248 - bigarr 547687 192004 2.852 - bisort 485857 115164 4.219 - conalloc 616613 149848 4.115 - concpu 616575 149848 4.115 - dil 7293277 1859208 3.923 - em3d 505019 116324 4.341 - mcore 461767 105748 4.367 - rnddata 2832935 1492588 1.898 - sbtree 526402 129860 4.054 - split 589353 144308 4.084 - tree 462009 105844 4.365 - tsp 544901 128412 4.243 - voronoi 601259 141112 4.261 - ======== ======== ======== ============== - .. ftable:: t:sol-exesize-cdgc - Reducción del tamaño del ejecutable para CDGC. - ======== ======== ======== =============== - Nombre Debug Stripped Debug/Stripped - ======== ======== ======== =============== - bh 736115 159884 4.604 - bigarr 697406 213832 3.261 - bisort 635537 136988 4.639 - conalloc 766328 171676 4.464 - concpu 766294 171676 4.464 - dil 7442657 1881028 3.957 - em3d 658827 142248 4.632 - mcore 611486 127576 4.793 - rnddata 2986736 1518512 1.967 - sbtree 680217 155784 4.366 - split 739072 166136 4.449 - tree 611728 127672 4.791 - tsp 694581 150236 4.623 - voronoi 750847 162936 4.608 - ======== ======== ======== =============== - TODO: Mostrar tiempos de corridas. - - -.. Resultados generales - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -.. Primero se presenta una visión global de los resultados, utilizando las - métricas más importantes. Para generar los gráficos se utilizan los valores - máximos (en blanco), mínimos (en negro), media y desvío estándar (en gris) - calculados en base a, como mínimo, 20 corridas (para algunos casos se hacen - hasta 50 corridas). Resultados para pruebas sintizadas