Hi Carl,
Sorry it's taken me so long to reply to your message.
I believe that the mkSelect(0) nodes are introduced by the
type-class part of the compiler - all references to mkSelect(0)
are in preds.c.
I did some tests using this patch (to compiler.c:translate)
This patch replaces AP(mkSelect(0),x) with x. It runs after typechecking.
diff -C2 -r1.13 compiler.c
*** compiler.c 1997/09/05 22:02:02 1.13
--- compiler.c 1997/10/28 19:48:23
***************
*** 108,112 ****
if (fst(e)==nameId)
return translate(snd(e));
!
if (fst(e)==nameStrict)
return nameIStrict;
--- 108,115 ----
if (fst(e)==nameId)
return translate(snd(e));
! #if 0
! if (fst(e)==mkSelect(0))
! return translate(snd(e));
! #endif
if (fst(e)==nameStrict)
return nameIStrict;
Here's the result of running Hugs with and without this patch using
this command line on my 72Mb 200MHz P6 Linux box.
(Haskore is the biggest library readily to hand.)
$ time hugs Haskore < /dev/null > /dev/null
Without the patch
0.69user 0.18system 0:00.86elapsed (181major+346minor)pagefaults
0.71user 0.14system 0:00.86elapsed (139major+346minor)pagefaults
0.67user 0.18system 0:00.84elapsed (139major+346minor)pagefaults
0.66user 0.19system 0:00.84elapsed (139major+346minor)pagefaults
0.60user 0.25system 0:00.84elapsed (139major+346minor)pagefaults
0.65user 0.20system 0:00.87elapsed (139major+346minor)pagefaults
0.67user 0.17system 0:00.84elapsed (139major+346minor)pagefaults
0.66user 0.19system 0:00.84elapsed (139major+346minor)pagefaults
0.68user 0.17system 0:00.84elapsed (139major+346minor)pagefaults
0.63user 0.22system 0:00.84elapsed (139major+346minor)pagefaults
0.64user 0.21system 0:00.84elapsed (139major+346minor)pagefaults
0.64user 0.21system 0:00.86elapsed (139major+346minor)pagefaults
0.65user 0.20system 0:00.84elapsed (139major+346minor)pagefaults
With the patch
0.61user 0.18system 0:00.79elapsed (181major+343minor)pagefaults
0.60user 0.19system 0:00.78elapsed (139major+343minor)pagefaults
0.60user 0.18system 0:00.78elapsed (139major+343minor)pagefaults
0.57user 0.23system 0:00.80elapsed (139major+343minor)pagefaults
0.59user 0.20system 0:00.79elapsed (139major+343minor)pagefaults
0.55user 0.25system 0:00.79elapsed (139major+343minor)pagefaults
0.57user 0.22system 0:00.79elapsed (139major+343minor)pagefaults
0.61user 0.18system 0:00.79elapsed (139major+343minor)pagefaults
0.60user 0.19system 0:00.79elapsed (139major+343minor)pagefaults
0.58user 0.22system 0:00.80elapsed (139major+343minor)pagefaults
0.56user 0.23system 0:00.79elapsed (139major+343minor)pagefaults
0.58user 0.21system 0:00.79elapsed (139major+343minor)pagefaults
The gain seems to be about 10% user time and 5% elapsed time - not bad
for 2 lines of code!
I'll stick this change into the system.
Thanks,
Alastair
> BTW, thanks very much for Hugs! It's a wonderful system.
>
> I've been using Hugs with happy-generated parsers (from the version of
> happy included with GHC 2.08) in ":set +." mode, and I noticed that it
> seemed to pause for quite a while at a certain point in the
> compilation. I decided to see if I could track down what was going
> on, and discovered that it was dealing with some very large terms; in
> particular, it's running pmcTerm() on some nests of applications of
> select(0) which are over 1000 deep. To demonstrate what was going on,
> I made the following patch to compiler.c:
>
> --- compiler.c-ORIG Mon Oct 13 23:43:31 1997
> +++ compiler.c Mon Oct 13 23:47:13 1997
> @@ -923,7 +923,23 @@
>
> case COND : return ap(COND,pmcTriple(co,sc,snd(e)));
>
> - case AP : return pmcPair(co,sc,e);
> + case AP : {
> + if (fun(e) == mkSelect(0)) {
> + int sel_cnt = 0;
> +
> + while (whatIs(e) == AP && fun(e) == mkSelect(0)) {
> + e = arg(e);
> + sel_cnt++;
> + }
> +
> + if (sel_cnt > 50) {
> + printf("Huge select(0) nest elided: %d terms\n", sel_cnt);
> + }
> +
> + return pmcTerm(co,sc,e);
> + }
> + return pmcPair(co,sc,e);
> + }
>
> #if BIGNUMS
> case POSNUM :
>
> As you can see, this just elides applications of select(0) in
> pmcTerm(). When I load my file with this patch in place, I get:
>
> Reading file "ParseMod.hs":
> Parsing........................................................................
> Dependency analysis............................................................
> Type checking..................................................................
> Compiling....................Huge select(0) nest elided: 64 terms
> Huge select(0) nest elided: 65 terms
> [...32 lines deleted...]
> Huge select(0) nest elided: 51 terms
> ..............................Huge select(0) nest elided: 1128 terms
> Huge select(0) nest elided: 1129 terms
> [...1088 lines deleted...]
> Huge select(0) nest elided: 54 terms
> ....................
>
> I don't know what causes these select(0) nests to be generated, but I
> wonder if there's some way to avoid it; or if pmcTerm (or some earlier
> stage) should elide them (as in my patch, but without the diagnostic),
> so that at least Hugs doesn't have to make copies of these huge terms.
> (I'm running with the patch now, with the diagnostic commented out,
> and loading my module seems to be significantly faster. I haven't
> done any actual timings though.)
>
> Let me know if you want copies of the relevant source files, or if you
> need any more details.
>
> Carl Witty
> [EMAIL PROTECTED]
