MEMOIZE_LOCALS (fwd)

MEMOIZE_LOCALS (fwd)

[Dirk Herrmann]

Hi folks,

I posted this to the guile-devel list, but I think it could be of interest
to people on the guile-user list as well.  So far, I have got positive
feedback from Marius for the change indicated below.  Thus, I urge people
who disagree to this change to speak up.  Otherwise I will go ahead and
remove the MEMOIZE_LOCALS macro.

Best regards, 
Dirk Herrmann

---------- Forwarded message ----------
Date: Thu, 27 Jun 2002 07:46:23 +0200 (CEST)
From: Dirk Herrmann <dirk@ida.ing.tu-bs.de>
To: guile-devel@gnu.org
Subject: MEMOIZE_LOCALS

Hi folks,

guile supports(?) to disable caching of local variable positions by
undefining the macro MEMOIZE_LOCALS.  First, I doubt that anybody makes
use of this option.  Second, I doubt that it will actually work to simply
undefine MEMOIZE_LOCALS, since I don't think it is being tested.

I would like to simply remove this option, making caching of local
variable positions mandatory.  Comments?

Best regards,
Dirk Herrmann


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: MEMOIZE_LOCALS (fwd)

[Thien-Thi Nguyen]

   From: Dirk Herrmann <dirk@ida.ing.tu-bs.de>
   Date: Thu, 27 Jun 2002 23:24:56 +0200 (CEST)

   I posted this to the guile-devel list, but I think it could be of
   interest to people on the guile-user list as well.  So far, I have
   got positive feedback from Marius for the change indicated below.
   Thus, I urge people who disagree to this change to speak up.
   Otherwise I will go ahead and remove the MEMOIZE_LOCALS macro.

this is a good opportunity to put in place performance testing framework
so we can see what kind of impact changes like this have.  you can make
statements like "benchmarks/memoize-locals.test shows 3% degradation w/
this change in local testing".  people can then learn to judge whether
or not such a change is under their noise threshold, and over time learn
to trust your methods.  any plans to do this?

nice work on evaluation.text, btw.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: MEMOIZE_LOCALS (fwd)

[Dirk Herrmann]

On Thu, 27 Jun 2002, Thien-Thi Nguyen wrote:

>    From: Dirk Herrmann <dirk@ida.ing.tu-bs.de>
>    Date: Thu, 27 Jun 2002 23:24:56 +0200 (CEST)
> 
>    I posted this to the guile-devel list, but I think it could be of
>    interest to people on the guile-user list as well.  So far, I have
>    got positive feedback from Marius for the change indicated below.
>    Thus, I urge people who disagree to this change to speak up.
>    Otherwise I will go ahead and remove the MEMOIZE_LOCALS macro.
> 
> this is a good opportunity to put in place performance testing framework
> so we can see what kind of impact changes like this have.  you can make
> statements like "benchmarks/memoize-locals.test shows 3% degradation w/
> this change in local testing".  people can then learn to judge whether
> or not such a change is under their noise threshold, and over time learn
> to trust your methods.  any plans to do this?

While in principle a performance testing framework is a good idea, it
won't help at all in the case discussed above:  The change, if applied as
suggested above, will only remove code that (if my assumptions about
people not making use of the MEMOIZE_LOCALS macro are right) is not
compiled into guile anyway.  Thus, the intention of the change is to
simplify the code by removing a lot of dead #ifdef code parts, making the
relevant parts of the code better readable.

Apart from this, I think there has been discussion about a benchmark suite
from time to time, but I can't tell about the current state.  Personally,
I don't have any plans to work on such a thing, but I would sure
appreciate if someone else likes to do so.  Performance is certainly an
important quality for software, but it is not the only one.  My personal
interest is on code readability, architectural cleanlyness, ease of use
(by means of providing a consistent and simple API) and such qualities.

Regarding my 'methods', I don't think there is much need to justify them.
Typically I think of ways to improve guile, suggest changes and discuss
with people whether these changes will make sense or not.  If there is a
consensus and I find the time (time is the most critical part!), I will
apply the changes.  So far, there have been only few complaints :-)

Best regards
Dirk Herrmann


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: MEMOIZE_LOCALS (fwd)

[Thien-Thi Nguyen]

   From: Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de>
   Date: Fri, 28 Jun 2002 01:39:08 +0200 (CEST)

   Thus, the intention of the change is to simplify the code by removing
   a lot of dead #ifdef code parts, making the relevant parts of the
   code better readable.

yes, this is clear (from looking at eval.c).  in this case, no
performance degredation would be the expected outcome.

   Regarding my 'methods', I don't think there is much need to justify them.

(you have to justify them to yourself at least. :-)

   Typically I think of ways to improve guile, suggest changes and discuss
   with people whether these changes will make sense or not.  If there is a
   consensus and I find the time (time is the most critical part!), I will
   apply the changes.  So far, there have been only few complaints :-)

unfortunately, volume of complaints doesn't always correlate w/ quality.
i'm glad to see you involving guile-user, in any case.

thi

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: MEMOIZE_LOCALS (fwd)

[Thien-Thi Nguyen]

below are some simple scripts you might find useful: 10x and 100x.  i
use them currently to see what kind of speedup qthreads omission incurs.
they live in (new directory) test-suite/perf/ at the moment, eventually
they should be put guile-scripts (cvs module) and copied into place by
autogen.sh.  example invocations:

  cd $builddir
  100x ./pre-inst-guile -c '(quit)'
  100x ./pre-inst-guile -c '(use-modules (ice-9 threads)) (quit)'
  [repeat in guile-1.4.1 $builddir]

for pre-inst-guile, the speedup is negative since there is now another
element in the search path.  OTOH, installed shows expected results...

thi


____________________________________________
#!/bin/bash

go ()
{
    iter=$1
    shift
    for (( i=$iter ; $i > 0 ; i = $i - 1 )) ; do "$@" ; done
}

time go 10 "$@"

____________________________________________
#!/bin/bash

go ()
{
    iter=$1
    shift
    for (( i=$iter ; $i > 0 ; i = $i - 1 )) ; do "$@" ; done
}

time go 100 "$@"

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user