Terminar sección de Viabilidad

[z.facultad/75.00/informe.git] / source / solucion.rst

diff --git a/source/solucion.rst b/source/solucion.rst
index d2184c121900aad2d1db97fe8396a39b47fb1b4f..fe9086b0f4adb51eaf69096cc63fcd90d955529f 100644 (file)
--- 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.
 
 .. Acá va lo que decidí hacer en base al análisis anterior y sus razones.

-   ESTADO: EMPEZADO
+   ESTADO: TERMINADO

 
 
 .. _solucion:
 
 
 .. _solucion:


@@ -8,13 +8,13 @@
 Solución adoptada
 ============================================================================
 
 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.
 
 * La eficiencia general de la solución no debe ser notablemente peor, en
   ningún aspecto, que la implementación actual.


@@ -1084,18 +1084,14 @@ recolector.
 Marcado preciso
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Información de tipos provista por el compilador
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


@@ -1381,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
 
 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
 
 :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


@@ -2154,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.
 
 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
 
 
 Resultados para pruebas sintizadas