Recent changes impeded building and testing on smaller boxes

Sat Sep 25 18:39:22 UTC 2010

Howdy,

I share your concerns, Jim. Recently, parrot got a new commandline flag
called --gc-threshold, which before was only changeable by twiddling some
bits in the GC internals. The default value for this parameter, even before
it was configurable from the command-line, was 25%, until r48585, where it
was changed, in trunk, to 50%. The change was mixed in with other changes
and is very easy to miss (the actual code is bitshifting a number of
quantities) and did not involve any deprecation notice.

The GC Threshold determines how much memory we are willing to waste before
the GC says "take out the garbage!". If we "take out the garbage" too often,
we lose performance. If we don't do it enough, we waste a lot of memory.

In theory, and I have seen some benchmarks (from luben++, IIRC), wasting a
bit more memory (changing the threshold from 25 to 50%) gave nice speed
increases for some Parrot benchmarks and Rakudo. But all was not peachy: for
instance, the examples/benchmarks/stress_strings.pir benchmark got about 30%
slower at r48585. It is a pathological benchmark for the GC, so it is still
unclear how concerned about that we should be.

What was not taken into account was older boxen, with less RAM, when the
threshold was changed.

I am inclined to say that we should probably change back to our default
threshold before r48585, and add documentation about what the threshold is
and how it effects the memory and speed performance of programs.

PS: Jim, my hunch for why your machine crawled to a stop is that it needed
more memory than was physically available to the process, so you went into
waiting-for-swap-purgatory.

Duke

On Sat, Sep 25, 2010 at 6:40 AM, James E Keenan <jkeen at verizon.net> wrote:

> During development of the gc_massacre branch, I tried to build and test
> parrot on both Linux/i386 and Darwin/PPC.  I have used each of these
> machines for testing since I joined the Parrot project in late 2006. While I
> have never explicitly tracked how fast 'make' and 'make test' run on those
> boxes, I do have a general sense of how long those processes take.
>
> I noticed that when I was building and testing the gc_massacre branch on
> the Darwin/PPC box (a 6-year-old iBook G4 running Mac OS X 4.11), all other
> operations on that machine would slow to a crawl.  For example, using
> Alt-Tab to toggle among programs would work only with 30-60 seconds of
> latency.  Switching from terminal to a browser (SeaMonkey or Camino)
> sometimes took 5 minutes.  This slowdown was most noticeable in the parts of
> 'make' where './ops2c' was being run.  'make test' ground to a halt in
> 't/compilers/opsc/*.t'.
>
> Trunk was continuing to build and test satisfactorily at this time, but
> once the gc_massacre branch was merged into trunk at r49269, trunk began to
> suffer all the same problems that the branch had.  My unscientific
> impression is that 'make' now takes 10% longer to complete (e.g., 12 minutes
> version 10-1/2 minutes), though it has taken as long as 19 minutes.  But
> what is most striking is that 'make test' won't complete at all unless I
> manually delete the tests in 't/compilers/opsc/*.t' from the roster of
> tests.  The '01' test in that directory will complete ... and then I will
> get no output whatsoever from the '02' test.  If I Ctrl-C to kill the '02'
> test, the '03' test will run -- but other tests in this directory will hang
> indefinitely as well.
>
> Last night bacek was able to devote some attention to this problem.  He
> pointed to a particular line of code recently merged in from the gc_massacre
> branch and asked me to make a manual change:
>
> $ svn diff
> Index: src/gc/gc_ms2.c
> ===================================================================
> --- src/gc/gc_ms2.c     (revision 49323)
> +++ src/gc/gc_ms2.c     (working copy)
> @@ -623,7 +623,8 @@
>
>         /* Collect every 256M allocated. */
>         /* Hardcode for now. Will be configured via CLI */
> -        self->gc_threshold = 256 * 1024 * 1024;
> +/*        self->gc_threshold = 256 * 1024 * 1024; */
> +        self->gc_threshold = 64 * 1024 * 1024;
>     }
>     interp->gc_sys->gc_private = self;
>
>
> 256M happens to be amount of Physical Memory reported by 'top' for this
> machine.  Changing the gc_threshold from 256M to 64M did enable 'make test'
> to run completely (including t/compilers/opsc/*.t) and PASS in about 19
> minutes.  So the value of the gc_threshold does have a significant impact on
> whether parrot will run (in any meaningful sense) on a particular machine.
>
> Now, I know that there are some who will snigger at the thought of trying
> to test Parrot on a machine that is more than 6 years old.  "Just go out and
> buy a new laptop, kid51.  It'll be sure to have at least 10 times as much
> memory as that ancient, battered box."
>
> Needless to say, I don't accept that logic -- and not only because
> "ancient, battered box" describes the box's owner as well as the box. As I
> pointed out when voicing a similar problem with Rakudo Star, if we've been
> able to build and run a particular program (Parrot, Rakudo Perl, whatever)
> on a particular machine for years on end, and if we can no longer do so,
> then our scientific rigor ought to require us to determine *why* we can no
> longer do so, rather than sweeping the problem under the rug.  AFAICT, we
> have never specified minimum memory or other requirements for building or
> running Parrot on any particular box. Hence, it seems to me to be reasonable
> to assume that if Parrot build on a particular box in 2006, it will continue
> to do so indefinitely unless building on that box is explicitly deprecated
> by the project.  After all, it's quite possible that when Parrot runs on
> embedded devices in the future, it will have to run in an environment with
> even less memory than this ancient, battered box has.
>
> Thank you very much.
> kid51
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100925/73ccc804/attachment.html>