status: separation of expansion/optimization/memoization/execution

status: separation of expansion/optimization/memoization/execution

[Dirk Herrmann]

Hi folks,

just wanted to let you know that I have actually been working on the issue
above:  Currently I am splitting up built-in macros following the
following pattern:


Former function:

SCM
scm_m_foo (SCM expr, SCM env)
{
  /* perform syntax checking, expansion, minor optimizations and
     memoization in one step. */
  return <new_expr>;
}


New set of functions:

static SCM
expand_foo (SCM expr, SCM env)
{
  /* perform syntax checking and expansion.  After this step, the code is
     still valid scheme code.  However, not all features are used. */
  return expanded_expr;
}

static SCM
optimize_foo (SCM expr, SCM env SCM_UNUSED)
{
  /* Most optimization functions are empty upto now.  In some cases,
     minor optimizations are performed.  After this step, the code is
     still valid scheme code.  However, not all features are used.  */
  return optimized_expr;
}

static SCM
memoize_foo (SCM expr, SCM env)
{
  /* return the memoized form of foo.  In some cases, minor memoization
     related optimizations are performed.  After this step, the code is
     not valid scheme code any more, and, with the current printer and
     reader, it can not be written and re-read.  */
  return memoized_expr;
}

SCM
scm_m_foo (SCM expr, SCM env)
{
  /* first, call expand_foo.  Then, using the result, call optimize_foo.
     Then, using the result of optimize_foo, call memoize_foo. */
  return memoized_expr;
}


Basically, with the changes above everythings still works as before, that
is, expansion and friends are still executed dynamically during execution.
However, the functionality of each of the builtin-mmacros is more cleanly
separated into different tasks with different responsibilities.  And, I
have added more exhaustive syntax checks into the expand_foo functions.

Up to now I have done this only for "if", "set!", "and", "or", "case",
"cond" and "do".  I also have simplified SCM_CEVAL at those places, where
due to the more extensive syntax checks in expand_foo some execution-time
syntax checks could be eliminated.  (However, all this takes some time,
since I only manage to finish at most one macro each day.)

The effect so far is, that booting guile takes noticably longer (at least
15%), but for example executing the test-suite is almost as fast as before
(2% slower).  Unfortunately, it is not yet possible to achieve large
performance improvements.  This will only be possible when the steps are
really separated.  Then, memoizing variable locations in the memoize_foo
functions will be possible, which simply can not work at the moment:  One
reason is the re-writing of internal defines, which disallows the
memoization of variables until the expansion phase is completed.


I have, however, not taken care of keeping track of debugging information
so far.  That is, I would like to hear suggestions about how this should
be done, since I don't have looked into that issue yet.  If someone is
interested to give the stuff a review (with respect to the debugging
issues or just generally), I would be glad to send you the patches for
eval.c and eval.h.  If the debugging stuff is worked out, it could even
make sense to submit the changes so far to allow for a broader testing in
the head branch.


Best regards,
Dirk Herrmann


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

Re: status: separation of expansion/optimization/memoization/execution

[Rob Browning]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> Basically, with the changes above everythings still works as before,
> that is, expansion and friends are still executed dynamically during
> execution.  However, the functionality of each of the
> builtin-mmacros is more cleanly separated into different tasks with
> different responsibilities.  And, I have added more exhaustive
> syntax checks into the expand_foo functions.

Eeeeexcelent :>

> The effect so far is, that booting guile takes noticably longer (at least
> 15%), but for example executing the test-suite is almost as fast as before
> (2% slower).  Unfortunately, it is not yet possible to achieve large
> performance improvements.  This will only be possible when the steps are
> really separated.  Then, memoizing variable locations in the memoize_foo
> functions will be possible, which simply can not work at the moment:  One
> reason is the re-writing of internal defines, which disallows the
> memoization of variables until the expansion phase is completed.

I don't know if you *are* worrying about the performance cost right
now, but if you are, I'd say don't.  Even if guile stays 20% slower
for a while, the long term benefits (and potential speedups) of this
work far outweigh the medium-term performance cost.

BTW has anyone else played with valgrind
http://developer.kde.org/~sewardj/docs/manual.html?  I'm planning to
play with it, but so far have only had a chance to see that it doesn't
like some of our ptr manipulations.  I also wonder if cachegrind might
be able to tell us anything useful...

> I have, however, not taken care of keeping track of debugging
> information so far.  That is, I would like to hear suggestions about
> how this should be done, since I don't have looked into that issue
> yet.  If someone is interested to give the stuff a review (with
> respect to the debugging issues or just generally), I would be glad
> to send you the patches for eval.c and eval.h.

I don't really know a lot about how debugging's being handled now, so
I'm not the best person to comment here.

> If the debugging stuff is worked out, it could even make sense to
> submit the changes so far to allow for a broader testing in the head
> branch.

Absolutely.  Actually I'd even say that if the debugging info is not
worked out, but if we think it *can* be worked out within a couple of
months, and if everything else is OK, then perhaps you should go ahead
and merge.  Your work will definitely get more attention in HEAD.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

Re: status: separation of expansion/optimization/memoization/execution

[Han-Wen]

rlb@defaultvalue.org writes:
> 
> BTW has anyone else played with valgrind
> http://developer.kde.org/~sewardj/docs/manual.html?  I'm planning to
> play with it, but so far have only had a chance to see that it doesn't
> like some of our ptr manipulations.  I also wonder if cachegrind might
> be able to tell us anything useful...

Yes, I tried running it on lilypond (which is linked to GUILE). I got
a ton of warnings that was not able to suppress (it seems that the
suppressions don't work for valgrind internal functions, like
strncmp).  Running valgrind for checking is probably pointless for
GUILE, as GUILE manages its own memory; the stack scanning GC also
generates lots of spurious warnings.

I did run it through the CPU cache simulator, which indicated that
gc_mark, gc_sweep and scm_ceval are causing a lot of cache misses.  I
hope to improve the GC part when I can compile guile with GCC 3.1 ;
GCC 3.1 supports prefetch instructions, so cache misses can be
decreased by doing stuff like

	  mark_cons:
	      prefetch (cdr)
	      scm_gc_mark (car)
	      ptr = cdr;
	      goto mark_again;


probably there are some techniques to boost cache rates for eval() as
well.



This is with the java-tree GC benchmark:

--------------------------------------------------------------------------------
I1 cache:         16384 B, 32 B, 4-way associative
D1 cache:         16384 B, 32 B, 4-way associative
L2 cache:         524288 B, 32 B, 4-way associative
Command:          ./libguile/.libs/lt-guile -s /tmp/graphs.sch
Events recorded:  Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw
Events shown:     Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw
Event sort order: Ir I1mr I2mr Dr D1mr D2mr Dw D1mw D2mw
Thresholds:       99 0 0 0 0 0 0 0 0
Include dirs:     
User annotated:   
Auto-annotation:  off

--------------------------------------------------------------------------------
         Ir    I1mr   I2mr          Dr      D1mr    D2mr         Dw    D1mw   D2mw 
--------------------------------------------------------------------------------
566,304,440 177,926 22,634 214,093,739 5,330,222 439,850 60,193,298 122,340 31,098  PROGRAM TOTALS

--------------------------------------------------------------------------------
         Ir   I1mr  I2mr         Dr      D1mr    D2mr         Dw   D1mw   D2mw  file:function
--------------------------------------------------------------------------------
188,450,666 28,572 4,577 69,348,246 1,248,161   6,579 18,620,442 22,047     84  eval.c:scm_ceval
 94,460,034  1,574   368 31,701,931 1,627,987 249,416  7,924,122 14,992  1,579  gc-mark.c:scm_gc_mark_dependencies
 90,846,605  7,899   114 38,685,160   620,624 134,205  5,581,738    746      8  gc-card.c:scm_sweep_card
 36,806,561    479    76 12,092,342    63,732      79  1,526,389      0      0  eval.c:scm_ilookup
 36,027,996     92    11 11,734,622   487,301   2,201  5,880,036 14,057  1,682  gc-mark.c:scm_gc_mark
 12,369,948    642   642  5,936,102   422,488   9,297  1,083,306      0      0  weaks.c:scm_mark_weak_vector_spines
 11,620,162    652   652  4,374,134   353,606   1,097  1,193,150     47      0  weaks.c:scm_scan_weak_vectors
 11,124,410    873    37  5,781,750   106,113      38  2,669,915      7      0  ../libguile/inline.h:scm_acons
  7,826,240  6,519   337  2,201,130    67,895     173    733,710      0      0  vectors.c:scm_vector_ref
  7,241,746    448     5  3,897,614    67,863      27  1,671,236     20      0  ../libguile/inline.h:scm_cons
  7,217,944    902   232  1,740,251     4,410       4  1,332,234  3,415     10  eval.c:scm_eval_args
  6,957,761 16,749 1,561  6,956,140    54,050   2,073        702      6      6  ???:???


-- 

Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: status: separation of expansion/optimization/memoization/execution

[Dale P. Smith]

On Sat, 3 Aug 2002 00:42:21 +0200 (CEST)
Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> wrote:

> Hi folks,
> 
> just wanted to let you know that I have actually been working on the issue
> above:  Currently I am splitting up built-in macros following the
> following pattern:

Whoo Hooo!

/me cheers!

(Sorry, too much irc lately)
  -Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith@altustech.com            | http://cleveland.lug.net
440-746-9000 x339               |

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

status: separation of expansion/optimization/memoization/execution

[Han-Wen]

dirk@sallust.ida.ing.tu-bs.de writes:
> The effect so far is, that booting guile takes noticably longer (at least
> 15%), but for example executing the test-suite is almost as fast as before

How do you measure that effectively? I now installed my new-gc guile,
and starting it up takes as long as it used to (the speed up seems to
have been disappeared.) Isn't the benchmark suite a much better test?

Is there some magical command that shows the startup time? (Would be
easy to implement, just do something similar to gc-stats).

FWIW, I "installed" some of the GC benchmarks over here --pretty
trivial-- and the code is GPL, but probably not (c) assigned. We can't
accept it then, Marius (right?), so shall I try asking the guy for a
disclaimer & assignment? (I think it has a slim chance working).

BTW, on a completely different note: I realized that it should not be
difficult to maintain coverage statistics for all primitive
(implemented in C) subroutines: when they are invoked a flag is set.
Is that possible?  Wouldn't that be very good for testing the
test-suite? Any thoughts?



-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: status: separation of expansion/optimization/memoization/execution

[Dirk Herrmann]

On Sat, 3 Aug 2002, Han-Wen wrote:

> dirk@sallust.ida.ing.tu-bs.de writes:
> > The effect so far is, that booting guile takes noticably longer (at least
> > 15%), but for example executing the test-suite is almost as fast as before
> 
> How do you measure that effectively? I now installed my new-gc guile,
> and starting it up takes as long as it used to (the speed up seems to
> have been disappeared.) Isn't the benchmark suite a much better test?

I measured it using "time guile < /dev/null" and repeated it several
times.  Each time the execution time varies, thus I tried to make out a
general tendency.  And, sure, the benchmark suite would be a better test,
if it contained some relevant benchmarks.  This is, up to now, not the
case.

However, didn't you say that you had some nice benchmark application
called lilypond ;-)  If there was a significant change due to your gc
changes, I believe you would notice it, right?  However, performance
improvements are not the major objective of your current patches, at least
that's what I understand:  IMO the code cleanup is the important point
here.

Best regards,
Dirk


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

Re: status: separation of expansion/optimization/memoization/execution

[Han-Wen]

dirk@sallust.ida.ing.tu-bs.de writes:
> However, didn't you say that you had some nice benchmark application
> called lilypond ;-)  If there was a significant change due to your gc

:)

I ran some tests on the anomalous machine (50% gc time), now it's back
down to 15 to 20 % -- still a lot, but credible. Compared to the old
scheme there is some slight advantage (gc-times down from 70 to 25),
perhaps due to the new malloc trigger, but I also increased the
segment size (I fixed a silly bug in our use of putenv).


-- 
Han-Wen Nienhuys   |   hanwen@cs.uu.nl   |   http://www.cs.uu.nl/~hanwen 

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

Re: status: separation of expansion/optimization/memoization/execution

[Tom Lord]

       > IMO the code cleanup is the important point here.

Such work was rudely interrupted in the early days and, I agree, is
very important, hence, long overdue.

My bibop comment went by un-acked ---  really and truly, just from a 
schemeimplhacking perspective, look into that direction.  I used to
think -- "no gc strategy is special -- bibop advocates are
exaggerating", but after plotting out a fresh implementation in detail
-- nah, they are exactly right.  

Staggered tags and bipbop.

-t


"Rape me" -- Kurt Kobain


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

Re: status: separation of expansion/optimization/memoization/execution

[Tom Lord]

	bibop advocates are
	exaggerating", but after plotting out a fresh implementation in detail
	-- nah, they are exactly right.  

	Staggered tags and bipbop.


After all -- there's only so many small integers and bit patterns.
It's essential -- not a fasion choice.

Bye.


-t


    <td align="center" width="50%">
      <p align="left"><small><i>
        I've got to be direct;<br>
        If I'm wrong, please correct.<br>
        You're standing on my neck.</i></small>

      <p align="center"><small>-- Daria</small>
    </td>


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

for example

[Tom Lord]

ok -- these are input to simple awk scripts (couple k lines) -- though
I'm probably sending you versions that don't currently compile:

And yes --- I'm being cryptic (a side effect of trying to compress a
lot of info down to a short message) --- but the basic message is
"bye", so don't waste time complaining.

-t


!       Register Types

  This file is part of the source code for the Hackerlab C library.
  It's translated to C by the awk program "./register-tags.awk".

  VM registers have small _external tags_ so they can hold a 
  limited selection of unboxed values.

  This file declares the register tags and the union type
  for (various kinds of) register.

*> core-registers register-type scm_register 2
**> holds scm s
**> holds scm_u u
**> holds scm_i i
**> holds scm_f f



--------------


!       The Bit Tag Spec File

  A popular misconception is that a tagging system simply maps values
  to a set of densely-packed, small integer tags, each tag representing
  a type.  You'll see people write:

<<<
	struct generic_object_header;
	{
	  t_uint tag;
	  ...
	};
>>>

  but that's really _oversimplified._  A good tagging system does
  much more than that.

  For example, here is an outline that is processed automatically to
  produce `enum' declarations for a system of "staggered tags" (see
  SCM, for example), predicate functions, and case labels.

  Since scheme is important enough that we should (at least casually)
  worry about the length and complexity of the bootstrap path from
  front-panel toggle-switches to full hosting environment, this file
  is designed to processed by a small `awk' script (i.e., a script for
  a little language with hash tables, loops, conditionals, and regexps
  but not much more).

  CLS note: I'm not sure how clear this will be to people who aren't
  looking at the rest of its context.  I hope the notation is clear
  enough to be puzzled out....


*> scm-tags tags scm
**: decodes-to scm_u

  We're going to define tags with a basename "scm" for values
  of type "scm".

**> split-tag val 2

  The smallest in-line tag will be two bits.

***> tag bibop_object				 (00)
****: tags-by-mask
****: decodes-to t_scm_sptr;

  Bibop objects are the lightest weight in terms of meta-data overhead
  (e.g., they don't necessarily have reference counts) and (if a
  direct pointer representation is used) alignment requirements (they
  are 4-byte aligned)

  Bibop objects share storage with page objects (see below).

***> tag cow_bibop_object			 (..)
****: tags-by-mask
****: decodes-to t_scm_cow_sptr;

  Lazy-linear bibop objects.

  There is a one bit reference count for each bibop object.
  When the first cow reference to an object is formed, that
  reference count is 0.  If the cow reference is copied (to 
  produce a second cow reference), the count is 1.  If 
  yet another cow-copy is made, the new copy is in fact a 
  shallow-copy of the object with reference count 0 (references
  in shallow copy are cow references).  When fetching a 
  possibly cow field, programs can request a non-cow reference
  to a stable object which the field will continue to hold
  with a cow reference: if, before the fetch, the field held
  a cow reference to an object with (possibly) more than one
  cow reference, then a shallow copy is made and the field updated
  before the fetch returns.


***> split-tag heavy_pointer 2                  (..)

  Bibop pointers have the nice property of being small (if implemented
  as direct pointers) but the drawback that reclamation of objects
  weakly held by bibop pointers can not occur until a scan has updated
  all pointers to the object.

  At the opposite extreme are object-table pointers and fat pointers: 
  more or less interchangable ways to obtain cheap (in time) 
  weak references and even cheaply destroyable objects.


****> tag vm_object                             (....)
****: tags-by-mask
****: decodes-to t_scm_obj

  The heap format of an object is quite complicated and is dcoumented
  in other files.

****> tag cow_vm_object                         (....)
****: tags-by-mask
****: decodes-to t_scm_cow_obj

  Lazy-linear vm objects.  Similar to cow bibop objects,
  except that the reference count is larger.

****> tag vm_object_promise			 (....)
****: tags-by-mask
****: decodes-to t_scm_promise_obj

  Lazy, memoized, and referencer-memoized vm objects.

****> split-tag vm_page 1                       (....)
*****: tags-by-mask
*****: decodes-to t_scm_page

  A modest pool of very-large-alignment (256 bytes) types.

*****> split-tag vm_direcct_page 2		 (....)

******> tag vm_page16                           (......)
******> tag vm_page128                          (......)
******> tag vm_page512                          (......)
******> tag vm_page1024                         (......)

*****> split-tag vm_cow_page 2  		 (....)

******> tag vm_cow_page16                       (......)
******> tag vm_cow_page128                      (......)
******> tag vm_cow_page512                      (......)
******> tag vm_cow_page1024                     (......)


***> split-tag immediate 1			 (..)


  Characters want to be "unicode+bucky bits" which adds up to _at
  least_ 24 bit and more comfortably to 29.

  Numbers are weird.  Do we want one or two big-as-possible immediate
  integer types?  or do we want to cram in lots of little types
  for tiny immediate rationals and complex numbers?  How much
  of it should make sense in 16-bit environments?

  Atomic values: I don't care much about them.  `nil' is the
  0 non-immediate value.  I wouldn't horribly miss `#t' 
  or seeing it become a non-immediate -- almost nothing low-level
  ever dispatches on #t specifically.  Indeed -- it's easy for an
  allocator to create disjoint, immutable, non-referencing objects
  that can be re-used across all VM instances and have well-known
  fixed addresses per-process.  Use values of that sort
  for atomics: one extra memory fetch for eq? test (to look up
  the well-known address) but otherwise just as good.

  So it's a two way battle: numbers v. characters.  Characters have
  the stricter data-size demands: let's give them half the remaining
  values:


****> tag character				 (...)
*****: decodes-to t_unicode
*****: decodes-exp 		(t_unicode)(   ((val >> scm_tag_width_character) & (((scm)1 << scm_char_code_bits) - 1)) \
       			       		    | (val & ((((scm)1 << scm_bucky_bits) - 1) << (scm_bits - scm_bucky_bits))))

  In a 32-bit or larger environment, we get 29 bits for
  immediate characters -- enough for 21-bits of 
  Unicode plus bucky-bits {left,right}x{shift,ctl,meta,alt}.

  Sweet.

  In the expanded (at least 32-bit) form, we keep the bucky bits in
  the high-order 8 bits.


****> tag immediate_signed  	                 (111) 		signed!
*****: decodes-to scm_i


*> scm-fast-dispatchers scm

**> dispatcher is_bibop
**> return 0 for bibop_object cow_bibop_objec
**> return 1 otherwise

**> dispatcher is_vm_object
**> return 1 for vm_object cow_vm_object vm_object_promise
**> return 0 otherwise

**> dispatcher vm_obj_discipline ?
***> return cow for vm_cow_page16 vm_cow_page128 vm_cow_page512vm_cow_page1024
***> return cow for cow_vm_object cow_bibop_object
***> return promise for vm_object_promise
***> return immediate for immediate
***> return regular otherwise

	this should generate

		[extern]enum scm_vm_obj_discipline scm_vm_obj_discipline(scm? obj) { switch (scm_tag(..)) ... }

	and

		inline t_uint8 scm_vm_obj_discipline_switch(scm? obj) { return scm_tag (...); }
		#define SCM_VM_OBJ_DISCIPLINE_COW_CASE ...
		#define SCM_VM_OBJ_DISCIPLINE_PROMISE_CASE ...
		#define SCM_VM_OBJ_DISCIPLINE_IMMEDIATE_CASE ...
		#define SCM_VM_OBJ_DISCIPLINE_REGULAR_CASE ...


add a way to make pointer types for  tags (e.g. vm_object) and for any
binary dispatcher + a conversion function that return nil on "wrong
type".  (`scm_as_vm_obj(scm val) => `t_scm_vm_obj').



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

i know -- let's play bridge!

[Tom Lord]

Hey, do you think if i suck the right cock i can get my picture in
wired?


-t

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

Re: i know -- let's play bridge!

[Tom Lord]

And I don't mean tournament bridge (where partners are blinded) -- but
the fun kind....  you know, the one where you play to see who can
cheat best.

But really --- "bye" -- and please look into bibop and staggered tags
for your GNU project.    


	****TYT*****


	Take _Your_ Time.

Thanks,

-t

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

Re: i know -- let's play bridge!

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> And I don't mean tournament bridge (where partners are blinded) -- but
> the fun kind....  you know, the one where you play to see who can
> cheat best.

Uh, that's fun?  Remind me not to bother playing bridge with you.
Cheating is only fun for those who find the actual game too hard to
bother with.


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

Re: i know -- let's play bridge!

[Tom Lord]

	Tom Lord <lord@regexps.com> writes:

	> And I don't mean tournament bridge (where partners are blinded) -- but
	> the fun kind....  you know, the one where you play to see who can
	> cheat best.

	Uh, that's fun?  Remind me not to bother playing bridge with you.
	Cheating is only fun for those who find the actual game too hard to
	bother with.


Si!

-t

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

Re: i know -- let's play bridge!

[Thomas Bushnell, BSG]

Bushnell (I) said:
> Uh, that's fun?  Remind me not to bother playing bridge with you.
> Cheating is only fun for those who find the actual game too hard to
> bother with.

Tom Lord said:
> Si!

So maybe more comment is appropriate.

I take as a basic of playing games that everyone knows the rules.  So
you could easily have two games: the game of contract bridge as
generally known, and another, which Tom Lord claims to prefer, to see
"who can cheat best".  But in that latter game, of course, it's not
cheating at all to signal to your partner what your heart suit is.
Let's call these two "Real Bridge" (with limited information about
your partner's hand) and "Tom Lord Bridge" (where you can develop
whatever signalling method you like).  

Now Tom Lord Bridge has a curious property.  If everyone is playing
it, then the game rapidly becomes uninteresting.  It becomes a matter
of double-dummy bridge play.  (Actually, it's a *tad* more interesting
than that, but not by much.)  This produces a game which is not quite
as interesting as checkers.  Why bother?!

So why would Tom prefer the Tom Lord Bridge to Real Bridge, given that
the former is less interesting than checkers?

Because, I suspect, he doesn't want to play a game where everyone
knows and agrees to the rules.  I suspect he wants to play a game
where there are common and agreed rules (the rules of Real Bridge will
do), but in which Tom then proceeds to play as if the rules were
different (say, Tom Lord Bridge).  He survives in this game because of
the goodwill or simple mistake of others who think he is willing to
play by common agreed rules.

Now if this were just about cards, then it would be silly and stupid.
But it's bigger than that!  It's not just bridge--substitute any
common social enterprise for the word "Bridge" above, and the same
division between "Real X" and "Tom Lord X" will appear, with the same
notion that the best game is the one where you try and cheat as much
as possible out of people who don't realize that there are two very
different games going on simultaneously.

Tom, will you please tell us which rules you want to play by?  I'll
play just about any game you choose, but you seem to want to refuse to
play by *any* agreed rules!

Thomas

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

Re: i know -- let's play bridge!

[Tom Lord]

	which Tom Lord claims to prefer


So sorry --- entirely sarcasm.


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

Re: i know -- let's play bridge!

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> 	which Tom Lord claims to prefer
> 
> So sorry --- entirely sarcasm.

But this is the problem!  I belabor, perhaps, unnecessarily:

1: You post a bizzare message, without context or relevance,

2: You decline to say what it means, in any way,

3: You then say "oh, I was just kidding".

The "oh, I was just kidding" defense is itself cheating.  It's what
people say after they say the most offensive things.  Sometimes it's
true, and honest, but even then, it's not just "sarcasm".  One wonders
if the "I was just kidding" would have showed up if the perpetrator
had not been called on it.

Now, bridge is a relatively trivial thing (unless you're livelihood is
connected with the sport).  But this is not about whether Tom thinks
cheating at bridge is okay.

Indeed, Tom's later response, that "Tom Lord" should also be
understood as a variable, pretends to be a joshing tone, a lively
banter, when in fact, it's a deceptive and, well, I think malicious
attempt to discourage us from looking at the facts.  Having been,
essentialy, told off--I basically said "Tom, you're lying to us when
you pretend to be part of our community"--Tom replies "If you mean
'Tom' to be a variable, then Yes!"  But that, of course, removes the
content.  It pretends that he's "going along with us", when in fact,
he's just being destructive.

Now we can see this pattern in many ways--those of us who have known
Tom for, oh, sixteen years, have perhaps seen the pattern more
commonly than we care to repeat.  I let people fill in the details
with their own experiences.  I describe the pattern *not* because I
want to describe a pattern in the abstract, without reference to
anything, but rather, because I want to name a malicious entity in our
midst--one who simply refuses to "play nice" and to get along
pleasantly with the other kids in the sandbox.

Now, Tom could simply decide to play nice.  He doesn't need to give
any retractions, any auto-da-fe's, any claims to behave nicer in the
future.  Such would, really, not be trusted, I think.  But he can
decide to start actually playing nice.  I hold out the hope.

Indeed, I held out the hope, and periodically, I send a friendly
message to Tom in the hopes that he will play nice.  But alas, he
doesn't!  Everything is cryptic, bizarre, half-stated and mostly
unstated.  

Tom, are you going to play friendly?  Please try.  The coy routine is
tired, sad, boring.  It's not really very clever to pretend to be a
Man-O-Mystery.  It's not that clever to play tricks on other
people--to cheat--only so that you can have that smug and self-assured
confidence that you know what the "real truth" is--though, of course,
the only "real truth" is that you're cheating.

Thomas


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

Re: i know -- let's play bridge!

[Tom Lord]

	3: You then say "oh, I was just kidding".


No.


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

Re: i know -- let's play bridge!

[Tom Lord]

	> The coy routine	



Just trying my best to skirt truth past the legal bondage in which
i am intwined -- and, no, you: that particular past employer who has
the greatest gag on me, this really isn't about you.  You are just a sad
and pathetic side effect of these problems, as far as i am concerned
and, honest to god, my entire experience with you isn't reflected in
these "cryptic" notes at all.

Please guile-devel....do well with your _GNU_ project.

-t

and, as a personal aside -- tb: i think i agree with you about QM and
god (to retract a stupid statement i made when we were undergrads) but
there's a lot more thinking and research to do.


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

Re: i know -- let's play bridge!

[Tom Lord]

Taking the letters "Tom Lord" in your analysis as variables, and the
entire note as an abstraction:

Si!


(Personally, I like some variations on _tournament bridge_ --
particularly those variations where we all remember that the goal is
to gather and be happy and shapern our minds and do good works and
make our environment incrementally better in a works-and-days kind of
mode....  I think there are some other players who suffer a
disabilitating lack of trust that would make that possible, though,
and I am beyond exhaustion at trying to win them over.... at least
that's my (repeated and extensive) experience.)

-t

---
   Avoid trusting FSBs to support cool hacks.  They aren't worthy of
   that trust.


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

Re: i know -- let's play bridge!

[Tom Lord]

	> I think there are some other players who suffer a
	> disabilitating lack of trust that would make that possible, though,
	> and I am beyond exhaustion at trying to win them over.... at least
	> that's my (repeated and extensive) experience.)


First: dammit tb -- shut up.  I really want to say "bye" here on some
pithy note about how to allocate tags.  Don't drag me into politics on
this list.

Second: have you ever had a conversation with a bunch of people who
aren't wage slaves where it's painfully apparent that they are trying
to evaluate whether you can be trusted with a public spotlight that
they control?  While your family is starving and suffering and being
agreeable to such assholes is your apparent best chance?

Sorry developer's list --- tb just knows how to push my buttons.


-t


!       The Heap Type Tag Spec File

  -*-*-

* Location Tags

  This file is part of the source code for the Hackerlab C library.
  It's translated to C by the awk program "./tags.awk".

  A value of of type `scm_location_tag' holds a tag value
  (`enum scm_location_tag') that describes the physical type 
  of some location.

  A value of type `scm_location_storage' is a value of type
  `scm_location_tag' tagged with an `enum scm_location_arity'.  The
  tag indicates whether the location contains a single value or a
  pointer to a dynamic array of (homogenously typed) values.

  The type `scm_location_desc' is a `scm_location_storage_type'
  tagged with `enum scm_location_protection'.  The tag describes
  whether and under what conditions the location may be read and
  written.  Note that this is a tripple-tagged value:  when decoded,
  it yields another tagged value (using two disjoint sets of tags).
  When that second value is decoded, the final result is yet another
  tag value (in yet another disjoint set): the data type stored at
  the lcoation.

  `scm_location_storage' fits (exactly) in 8 bits.


*> heap-tags tags scm_location_desc
**: decodes-to scm_location_storage
**> split-tag protection 2
***> tag opaque 
***> tag guarded
***> tag read_only
***> tag public

*> tags scm_location_storage
**: decodes-to scm_location_type
**> split-tag arity 1
***> tag cell
***> tag array

*> tags scm_location_type
**: decodes-to t_uint
**> split-tag id 5

***> tag t_uint8
***> tag t_int8
***> tag t_uint16
***> tag t_int16
***> tag t_uint32
***> tag t_int32
***> tag t_uint64
***> tag t_int64
***> tag scm_float32
***> tag scm_float64
***> tag scm_u
***> tag scm_i
***> tag scm

***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0


***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0

***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0

***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0

***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0
***> tag unused_loc_0

\f

* Structure Tags

  A simple physical strucutre type is described 
  by an array of location tags (roughly one for each field)
  plus two parameters: alignment and allocation strategy.

  Alignment is a power of two that establishes the grid
  on which fields are aligned when in contiguous
  memory.

  The allocation strategy is: 

  	_inline_ for a flat object.
	_handle_ for a separately resizable object
	_pow2_array_ for a 
		 

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

Re: i know -- let's play bridge!

[Tom Lord]

       > Second: have you ever had a conversation 


I mean -- a very _long_ conversation.

-t

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

Re: status: separation of expansion/optimization/memoization/execution

[Marius Vollmer]

Han-Wen <hanwen@cs.uu.nl> writes:

> FWIW, I "installed" some of the GC benchmarks over here --pretty
> trivial-- and the code is GPL, but probably not (c) assigned. We can't
> accept it then, Marius (right?), so shall I try asking the guy for a
> disclaimer & assignment? (I think it has a slim chance working).

Well, I'm not really sure about this, but I would say that supporting
material does not need to be copyrighted by the FSF.  The risk is that
when some code is not (C) FSF, the FSF can not be sure that the
license really is GPL and might be forced to take the code out again.
When that happens to the benchmark suite, Guile itself is not
terminally harmed.  If you can get a disclaimer (there are several
options), so much the better.

I'm a bad thinker when it comes to licenses.  It's better to ask
<licensing@gnu.org>.

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

Re: status: separation of expansion/optimization/memoization/execution

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> Basically, with the changes above everythings still works as before, that
> is, expansion and friends are still executed dynamically during execution.
> However, the functionality of each of the builtin-mmacros is more cleanly
> separated into different tasks with different responsibilities.  And, I
> have added more exhaustive syntax checks into the expand_foo functions.

Hmm, what is the purpose of this seperation?  As far as I can see, the
important thing is the separate memoization from execution, not the
various stages of memoization itself.

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

Re: status: separation of expansion/optimization/memoization/execution

[Dirk Herrmann]

On 5 Aug 2002, Marius Vollmer wrote:

> Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:
> 
> > Basically, with the changes above everythings still works as before, that
> > is, expansion and friends are still executed dynamically during execution.
> > However, the functionality of each of the builtin-mmacros is more cleanly
> > separated into different tasks with different responsibilities.  And, I
> > have added more exhaustive syntax checks into the expand_foo functions.
> 
> Hmm, what is the purpose of this seperation?  As far as I can see, the
> important thing is the separate memoization from execution, not the
> various stages of memoization itself.

Well, I have to agree that I am not yet sure whether this separation is
actually necessary.  For me, this is a means to get a clearer idea of what
is actually going on - especially in the context of weird stuff like the
conversion of internal defines into letrecs and so on.  And, it is
actually quite simple to do this separation while doing the separation of
memoization from execution.

Maybe it makes sense to combine some of the steps later on.  But, on the
other hand, it may also be beneficial to have such a separation later, in
order to be able to insert an optional optimization step between expansion
and memoization.

Best regards,
Dirk


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

Re: status: separation of expansion/optimization/memoization/execution

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> > Hmm, what is the purpose of this seperation?  As far as I can see, the
> > important thing is the separate memoization from execution, not the
> > various stages of memoization itself.
> 
> Well, I have to agree that I am not yet sure whether this separation is
> actually necessary.  For me, this is a means to get a clearer idea of what
> is actually going on

Ok, but you are seeing a significant loss inperformance because of
them, right?  Although I think it is acceptable to make on-the-fly
compilation more expensive in order to allow ahead-of-time
compilation, we should not do it gratuitously.  It will be a long way
until we might no longer want to care about the on-the-fly compiler
since everybody compiles their important code ahead-of-time anyway.

So, cleaning up the existing lazy memoizer is a very good thing
indeed.  But I'd say you should also make sure that you don't
significantly lose performance by doing it.  That part of Guile will
be performance-critical for quite some time.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: status: separation of expansion/optimization/memoization/execution

[Dirk Herrmann]

On 10 Aug 2002, Marius Vollmer wrote:

> So, cleaning up the existing lazy memoizer is a very good thing
> indeed.  But I'd say you should also make sure that you don't
> significantly lose performance by doing it.  That part of Guile will
> be performance-critical for quite some time.

At the current state I can't decide yet, whether after the changes guile's
speed will at all differ from before.  Too many optimizations of the
scheme code are not possible yet, until the separation is complete.  If
there is a performance problem then, it will be easier to optimize the
evaluator then.  There are, however, a lot of open questions:

* in principle, memoization could memoize all variable references.  That
  would mean, the execution could be freed of all checks for symbols and
  variable lookups - this would have been done by the memoizer.

  Benefits:  
  - no symbol lookups in the executor
  - quoted symbols could be made into symbols, getting rid of one level of
    quoting

  Problems:
  - how to deal with undefined symbols?
  - should 'undefine' still be possible, and if so, how?

* should the executor ever run over an undefined symbol?  This could be
  checked during expansion and memoization.  If it is known that during
  exection all symbols are defined, this eliminates one test during
  variable lookup.

Best regards,
Dirk



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

Re: status: separation of expansion/optimization/memoization/execution

[Marius Vollmer]

Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

> On 10 Aug 2002, Marius Vollmer wrote:
> 
> > So, cleaning up the existing lazy memoizer is a very good thing
> > indeed.  But I'd say you should also make sure that you don't
> > significantly lose performance by doing it.  That part of Guile will
> > be performance-critical for quite some time.
> 
> At the current state I can't decide yet, whether after the changes guile's
> speed will at all differ from before.  Too many optimizations of the
> scheme code are not possible yet, until the separation is complete.

Are there optimizations that will be possible after the separation
that are not possible now?

In any case, please proceed carefully.  Making a branch is probably a
good idea.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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

Re: status: separation of expansion/optimization/memoization/execution

[Neil Jerram]

>>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:

    Dirk> I have, however, not taken care of keeping track of
    Dirk> debugging information so far.  That is, I would like to hear
    Dirk> suggestions about how this should be done, since I don't
    Dirk> have looked into that issue yet.  If someone is interested
    Dirk> to give the stuff a review (with respect to the debugging
    Dirk> issues or just generally), I would be glad to send you the
    Dirk> patches for eval.c and eval.h.

I'd be happy to look at these.

        Neil


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

Re: status: separation of expansion/optimization/memoization/execution

[Dirk Herrmann]

On 5 Aug 2002, Neil Jerram wrote:

> >>>>> "Dirk" == Dirk Herrmann <dirk@sallust.ida.ing.tu-bs.de> writes:
> 
>     Dirk> I have, however, not taken care of keeping track of
>     Dirk> debugging information so far.  That is, I would like to hear
>     Dirk> suggestions about how this should be done, since I don't
>     Dirk> have looked into that issue yet.  If someone is interested
>     Dirk> to give the stuff a review (with respect to the debugging
>     Dirk> issues or just generally), I would be glad to send you the
>     Dirk> patches for eval.c and eval.h.
> 
> I'd be happy to look at these.

Great,  I will send a patch to you as soon as I have reached a state again
in which guile compiles :-)

Best regards,
Dirk


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