Greetings!
Hope to report more later, but jsut wanted to note how difficut it is
to get a fair comparison with shelter-mv as the bogey. You can look
at his macros in lsp/fast-mv.lsp, and also the note in his changelog
about this being the default someday. Indeed, it appears to be as
fast as possible (with one exception to be decribed below.) However:
1) The callee must make sure to always set the maximum number of
values, otherwise junk will be left in MVloc.
2) There is no way for the caller to tell how many values were set.
This seems designed for the case where both the callee and the caller
know that exactly n values are placed in the stack under all
circumstances. In fact, it does appear we could default to this in
this case. However, at the moment, '(values t t) means for us at most
two values, and in any case, one might want to support functions which
might return different numbers of values under different circumstances
in a general implementation.
This stuff is all driven by memory access time, AFAICT. One wants to
avoid writes wherever possible. Indeed, out current multiple-value
bind looks near optimal in this regard given the requirement that the
callee must inform the caller somehow how many values it set.
One possible improvement therefore would appear to be for the caller
to inform the callee how many values are sought, and for the callee to
set no more than this number. In fact, if no side effect status can
be reliably proapagated, then the unused values need never even be
computed, let alone written. This all requires a minimum amount of
logic in the callee, and one extra write in the caller to indicate how
much space is available. I think the logic will be insignificant
compared to the memory access potential savings.
In any case, I'm having difficulty benchmarking my implementation
against Shelter mv as it doesn't support the case for 1) the caller
wanting more values than set by the callee (i.e. others initialized to
nil), and 2) callees returning different number of values. If I could
get a good and fair bogey in a minimal realistic example, that would
be most helpful.
(defun g (x y) (values x y x y x y x y x y))
(defun h (x y) (let (q) (dotimes (i 10000000) (multiple-value-bind (x
y z w) (g x y) (setq q (and x y z w)))) q))
Take care,
Matt Kaufmann <[EMAIL PROTECTED]> writes:
> Howdy --
>
> Actually, for the times I reported, I was using mv as values, not Schelter's
> mv. But that's an interesting point; is this proclaim (or actually, the
> corresponding declaim) worth doing with stock GCL 2.6.7, say, before building
> ACL2 on top of it?
>
> THanks --
> -- Matt
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], gcl-devel@gnu.org
> From: Camm Maguire <[EMAIL PROTECTED]>
> Date: 28 Jun 2006 13:13:56 -0400
> X-SpamAssassin-Status: No, hits=-2.5 required=5.0
> X-UTCS-Spam-Status: No, hits=-240 required=200
>
> Greetings! In looking at mv performance, I just noticed one glitch
> that is currently significantly slowing down shelter mv if you are
> using it:
>
> We need this:
>
> (proclaim '(ftype (function (seqind t) t) si::set-mv))
>
> Take care,
>
> Matt Kaufmann <[EMAIL PROTECTED]> writes:
>
> > Good morning --
> >
> > I rebuilt ACL2 on the new GCL 2.7.0, fixing three very minor errors in
> > acl2-proclaim.lisp, and got the following regression results, which show
> a 19%
> > slowdown.
> >
> > Old (/projects/hvg/ACL2/v3-0-hons-jun25/make-regression.log):
> > 16925.205u 434.179s 4:55:01.49 98.0% 0+0k 0+0io 13pf+0w
> >
> > New (/projects/hvg/ACL2/v3-0-hons-jun27/make-regression.log):
> > 20271.642u 439.507s 5:50:04.01 98.6% 0+0k 0+0io 18pf+0w
> >
> > Serita, if you can stand the 19% slowdown maybe you'd be willing to do a
> > "make clean" on your books and start using
> > /projects/hvg/ACL2/v3-0-hons-jun27/saved_acl2.
> >
> > -- Matt
> > Date: Tue, 27 Jun 2006 21:09:05 -0500
> > From: Robert Boyer <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> >
> > Matt sez:
> >
> > > when you or Camm tells me that there's a new GCL 2.7.0 to
> > > build on
> >
> > Camm sez:
> >
> > > Should be cleared now
> >
> > So, a brand new big, static, ansi 2.7.0 with expanded stacks
> > but with x disabled may now be found at:
> >
> > /u/boyer/bin-override/2
> >
> > All I did was run /u/boyer/bin-override/build2.
> >
> > Let me know if you would prefer for me to flush my big
> > initial allocates in the future.
> >
> > I hope Serita can produce a reproducible bug for Camm in an
> > up-to-date acl2/hons built on 2 by you within an hour,
> > before 2.7.0 changes too much!
> >
> > Thanks very much,
> >
> > Bob
> >
> >
> >
> >
>
> --
> Camm Maguire [EMAIL
> PROTECTED]
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
>
--
Camm Maguire [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Gcl-devel mailing list
Gcl-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gcl-devel
