From explorer en joaquinferrero.com Thu May 3 08:56:56 2012 From: explorer en joaquinferrero.com (Joaquin Ferrero) Date: Thu, 03 May 2012 17:56:56 +0200 Subject: [Madrid-pm] Presentada solicitud de beca para proyecto PerlDoc-ES ante la TPF Message-ID: <4FA2AAC8.9040008@joaquinferrero.com> Buenas... En el último Hackaton que hicimos Enrique y yo en el MadridLab, elaboramos la solicitud de beca de este proyecto, para ver si con el impulso de la TPF podemos alcanzar más rápidamente el ansiado 100% de la traducción de Perl a español, y a partir de ahí, estar en sincronía con los siguientes lanzamientos. Además, las técnicas elaboradas en este proyecto servirán para otros proyectos de traducción. La propuesta acaba de ser publicada en ''The Perl Foundation'': http://news.perlfoundation.org/2012/05/2012q2-grant-proposal-spanish.html Si os parece interesante el proyecto, y que la TPF lo apoye también, pues podéis dejar vuestros comentarios en la misma página. El proyecto PerlDoc-ES está al 42% de la traducción de Perl v5.14.2 (3% revisado). Podéis seguir su evolución *en tiempo real* ;) en la página https://docs.google.com/spreadsheet/ccc?key=0AkmrG_9Q4x15dC1MNWloU0lyUjhGa2NrdTVTOG5WZVE Los archivos revisados son publicados bajo POD2::ES, y los documentos traducidos esperando revisión están en https://github.com/zipf/perldoc-es/tree/master/pod/translated Si alguien quiere colaborar, hay varias maneras: * Como lector/revisor. Si observáis algún problema en la traducción de un documento, podéis enviarnos los cambios, o creáis una nueva rama del documento en Github. * Como traductores. Hemos simplificado al límite las condiciones de instalación y configuración de la herramienta OmegaT. Ahora solo es necesario tener un sistema operativo con XWindow y un terminal SSH (fácil, ¿no?) porque todo el proceso es remoto: hemos instalado el OmegaT en un servidor externo, por lo que no hay nada más que conectarse por SSH, arrancar el OmegaT remoto, elegir un documento, y empezar a traducir. Todavía queda mucho por hacer, sobre todo en documentar todo esto y en crear herramientas de apoyo a los traductores/revisores. Saludos, -- JF^D From jjmerelo en gmail.com Sun May 27 06:13:19 2012 From: jjmerelo en gmail.com (JJ Merelo) Date: Sun, 27 May 2012 15:13:19 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina Message-ID: Hola Pregunta corta: ¿Cómo se hace para que Perl no devuelva un valor de una subrutina? Pregunta larga: en el MasterMind hay subrutinas que se llaman millones (o miles de millones) de veces. El profiler dice que, curiosamente, el devolver el valor de la misma es el cuello de botella. Igual hay otra forma de solucionarlo, como meterlas inline (la verdad, no sé como hacerlo) pero lo que he hecho ha sido declarar el prototipo como que devuelvan void y hacer que se les pase el hashref de vuelta como parámetro. Marginalmente mejora algo, pero sigue devolviendo el valor devuelto por la última función en la subrutina (un map). Añadir return; no mejora prácticamente nada, y declararla como void con prototipo tampoco. ¿Alguna idea? Saludos -- JJ ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From pancho en pancho.name Sun May 27 07:42:45 2012 From: pancho en pancho.name (pancho horrillo) Date: Sun, 27 May 2012 16:42:45 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: References: Message-ID: <20120527144245.GA7566@pancho.name> On Sun, May 27, 2012 at 03:13:19PM +0200, JJ Merelo wrote: > Hola Buenas. > Pregunta corta: ¿Cómo se hace para que Perl no devuelva un valor de una > subrutina? AFAIK, return; devuelve undef. > Pregunta larga: en el MasterMind hay subrutinas que se llaman millones (o > miles de millones) de veces. El profiler dice que, curiosamente, el > devolver el valor de la misma es el cuello de botella. Igual hay otra forma > de solucionarlo, como meterlas inline (la verdad, no sé como hacerlo) pero > lo que he hecho ha sido declarar el prototipo como que devuelvan void y > hacer que se les pase el hashref de vuelta como parámetro. Marginalmente > mejora algo, pero sigue devolviendo el valor devuelto por la última función > en la subrutina (un map). Añadir return; no mejora prácticamente nada, y > declararla como void con prototipo tampoco. ¿Alguna idea? > Se me ocurre hacer un inline manual, construyendo código programáticamente que incruste el código de la función llamada en la llamante, y luego haciendo eval de ello. No tengo tiempo de explicarlo más, cuando vuelva luego intentaré explayarme un poco más. Hope that it helps. Cheers, > Saludos > > -- > JJ > _______________________________________________ > Madrid-pm mailing list > Madrid-pm en pm.org > http://mail.pm.org/mailman/listinfo/madrid-pm -- pancho horrillo From jjmerelo en gmail.com Sun May 27 08:03:28 2012 From: jjmerelo en gmail.com (JJ Merelo) Date: Sun, 27 May 2012 17:03:28 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: <20120527144245.GA7566@pancho.name> References: <20120527144245.GA7566@pancho.name> Message-ID: El 27 de mayo de 2012 16:42, pancho horrillo escribió: > On Sun, May 27, 2012 at 03:13:19PM +0200, JJ Merelo wrote: > > Hola > Buenas. > > > Pregunta corta: ¿Cómo se hace para que Perl no devuelva un valor de una > > subrutina? > AFAIK, return; devuelve undef. > En realidad, devolver undef no es devolver nada. Es edvolver undef, y sigue tardando más o menos lo mismo que si haces return 1 o return 0. > > > Pregunta larga: en el MasterMind hay subrutinas que se llaman millones (o > > miles de millones) de veces. El profiler dice que, curiosamente, el > > devolver el valor de la misma es el cuello de botella. Igual hay otra > forma > > de solucionarlo, como meterlas inline (la verdad, no sé como hacerlo) > pero > > lo que he hecho ha sido declarar el prototipo como que devuelvan void y > > hacer que se les pase el hashref de vuelta como parámetro. Marginalmente > > mejora algo, pero sigue devolviendo el valor devuelto por la última > función > > en la subrutina (un map). Añadir return; no mejora prácticamente nada, y > > declararla como void con prototipo tampoco. ¿Alguna idea? > > > Se me ocurre hacer un inline manual, construyendo código programáticamente > que > incruste el código de la función llamada en la llamante, y luego haciendo > eval > de ello. > No vas a ganar mucho si tienes que hacer un eval. Estamos hablando de microsegundos en cada vuelta, más o menos. > > No tengo tiempo de explicarlo más, cuando vuelva luego intentaré > explayarme un > poco más. > > Hope that it helps. > > Eso siempre. Gracias. -- JJ ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From explorer en joaquinferrero.com Sun May 27 17:07:21 2012 From: explorer en joaquinferrero.com (=?UTF-8?B?Sm9hcXXDrW4gRmVycmVybw==?=) Date: Mon, 28 May 2012 02:07:21 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: References: Message-ID: <4FC2C1B9.7000902@joaquinferrero.com> El 27/05/12 15:13, JJ Merelo escribió: > Hola Pregunta corta: ¿Cómo se hace para que Perl no devuelva un valor > de una subrutina? > Pregunta larga: en el MasterMind hay subrutinas que > se llaman millones (o miles de millones) de veces. El profiler dice > que, curiosamente, el devolver el valor de la misma es el cuello de > botella. Igual hay otra forma de solucionarlo, como meterlas inline > (la verdad, no sé como hacerlo) pero lo que he hecho ha sido declarar > el prototipo como que devuelvan void y hacer que se les pase el > hashref de vuelta como parámetro. Marginalmente mejora algo, pero > sigue devolviendo el valor devuelto por la última función en la > subrutina (un map). Añadir return; no mejora prácticamente nada, y > declararla como void con prototipo tampoco. ¿Alguna idea? > > Según perlsub, no se puede: una subrutina siempre devolverá un valor, incluso aunque no pongamos un return. En ese caso, será el valor de la última instrucción ejecutada. Además, depende de en qué contexto se ejecute la subrutina, ese valor será convertido a escalar o lista. Y si no devolvemos ningún valor, aún así se creará una lista vacía (en contexto lista), el valor indefinido (en contexto escalar) o "nada" si está en contexto void. (¡Oops! ¿Nada?) JF^D From jjmerelo en gmail.com Sun May 27 22:52:08 2012 From: jjmerelo en gmail.com (JJ Merelo) Date: Mon, 28 May 2012 07:52:08 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: <4FC2C1B9.7000902@joaquinferrero.com> References: <4FC2C1B9.7000902@joaquinferrero.com> Message-ID: Finalmente, usar return; parece que es lo más rápido. Aún así, se come unos cuantos milisegundos... ¿Salir con croak merecería la pena? ¿O pillar la excepción a otro nivel se comería cualquier aumento de velocidad? -- JJ ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From sfandino en yahoo.com Mon May 28 14:00:53 2012 From: sfandino en yahoo.com (Salvador Fandino) Date: Mon, 28 May 2012 14:00:53 -0700 (PDT) Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: References: Message-ID: <1338238853.2212.YahooMailNeo@web121602.mail.ne1.yahoo.com> >________________________________ > From: JJ Merelo >To: Lista de correo de Madrid Perl Mongers >Sent: Sunday, May 27, 2012 3:13 PM >Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina > > >Hola >Pregunta corta: ¿Cómo se hace para que Perl no devuelva un valor de una subrutina? >Pregunta larga: en el MasterMind hay subrutinas que se llaman millones (o miles de millones) de veces. El profiler dice que, curiosamente, el devolver el valor de la misma es el cuello de botella. Igual hay otra forma de solucionarlo, como meterlas inline (la verdad, no sé como hacerlo) pero lo que he hecho ha sido declarar el prototipo como que devuelvan void y hacer que se les pase el hashref de vuelta como parámetro. Marginalmente mejora algo, pero sigue devolviendo el valor devuelto por la última función en la subrutina (un map). Añadir return; no mejora prácticamente nada, y declararla como void con prototipo tampoco. ¿Alguna idea? > No te creas lo que te dice tu profiler!!! Cuando se activa en Perl el profiling, lo que el interprete hace es llamar a la subrutina de profiling/debugging (DB::db) cada vez que se va a ejecutar una nueva sentencia. Normalmente, lo que se hace dentro de esta subrutina, es cronometrar el tiempo transcurrido entre llamadas sucesivas y atribuir este a la penúltima operación. Pero a veces, hay operaciones implícitas para las que no se llama DB::db entremedias y esto es lo que esta pasando en el caso que planteas. Aqui la operacion oculta es la de abandonar una subrutina (leavesub) donde se liberan las variables intermedias, se deshacen las local'izaciones, se limpia el pad, etc. "return" es la ultima llamada que se ejecuta dentro de una subrutina, y lo único que hace es meter en la pila uno o varios valores (según el contexto), es una operación muy barata. Por ejemplo:   sub foo {     return 84;   }   $a=0;   foo();   $a+=1; Lo que el profiler ve:   $a=0;        #  se empieza a ejecutar en t0, consume t1 - t0   return 84;  #  se empieza a ejecutar en t1, consume t2 - t1   $a+=1;     #  se empieza a ejecutar en t2, consume t3 - t2                  #  se acaba en t3 Y con B::Concise se puede ver lo que perl ejecuta realmente: La parte correspondiente al codigo que no esta dentro de ninguna subrutina:   $ perl -MO=Concise,-exec,-src /tmp/p.pl   1  <0> enter   # 5: $a=1;   2  <;> nextstate(main 2 p.pl:5) v:{   3  <$> const[IV 1] s   4  <#> gvsv[*a] s   5  <2> sassign vKS/2   # 6: foo();   6  <;> nextstate(main 2 p.pl:6) v:{   7  <0> pushmark s   8  <#> gv[*foo] s   9  <1> entersub[t4] vKS/TARG,1   # 7: $a+=1;   a  <;> nextstate(main 2 p.pl:7) v:{   b  <#> gvsv[*a] s   c  <$> const[IV 1] s   d  <2> add[t6] vKS/2   e  <@> leave[1 ref] vKP/REFC Y el desemsamblado de foo:   $ perl -MO=Concise,-exec,-src,foo /tmp/p.pl   main::foo:   # 2:     return 84;   1  <;> nextstate(main 1 p.pl:2) v   2  <0> pushmark s   3  <$> const[IV 84] s   4  <@> return K   5  <1> leavesub[1 ref] K/REFC,1    <==== Aquí es donde va el tiempo oculto! Por cierto, las llamadas a DB::db se hacen si no recuerdo mal en cada OP "nextstate". Conclusión: lo que estas midiendo es parte de la sobrecarga implícita de llamar a una subrutina y no hay forma de eliminarla otra que no sea insertar el código de la subrutina directamente en el punto de llamada (un "inline", vamos), pero como perl no soporta macros, esto no se puede hacer de manera automatica (bueno, creo que en las ultimas versiones si con C / XS, utilizando algunas de las nuevas APIs, pero no parece nada fácil). From sfandino en yahoo.com Mon May 28 14:07:46 2012 From: sfandino en yahoo.com (Salvador Fandino) Date: Mon, 28 May 2012 14:07:46 -0700 (PDT) Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: References: <4FC2C1B9.7000902@joaquinferrero.com> Message-ID: <1338239266.87445.YahooMailNeo@web121601.mail.ne1.yahoo.com> >________________________________ > From: JJ Merelo >To: Lista de correo de Madrid Perl Mongers >Sent: Monday, May 28, 2012 7:52 AM >Subject: Re: [Madrid-pm] Optimizando el valor de vuelta de una subrutina > > >Finalmente, usar return; parece que es lo más rápido. Aún así, se come unos cuantos milisegundos... ¿Salir con croak merecería la pena? ¿O pillar la excepción a otro nivel se comería cualquier aumento de velocidad? No se puede hacer nada, llamar a croak seria mucho peor, dado que esto implica llamar todavia a otra subrutina, si llamas a die, puedes saltar varios varios niveles de subrutina, pero Perl realizaria de todas formas las labores de limpieza de toda la cadena y por otro lado para detener la excepcion necesitas ponerlo todo dentro de un "eval" y para los "eval" se crea un contexto especial que es aun mas caro que el de llamada a una subrutina con lo cual tampoco va a compensar fuera de casos extremos (por ejemplo, devolver el control a una subrutina que esta muchos niveles por arriba). From jjmerelo en gmail.com Mon May 28 22:25:56 2012 From: jjmerelo en gmail.com (JJ Merelo) Date: Tue, 29 May 2012 07:25:56 +0200 Subject: [Madrid-pm] Optimizando el valor de vuelta de una subrutina In-Reply-To: <1338239266.87445.YahooMailNeo@web121601.mail.ne1.yahoo.com> References: <4FC2C1B9.7000902@joaquinferrero.com> <1338239266.87445.YahooMailNeo@web121601.mail.ne1.yahoo.com> Message-ID: OK; gracias. Se queda entonces con return; -- JJ ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: