This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: type-checking (was: Re: thanks)


Michael Livshin <mlivshin@bigfoot.com> writes:

[snip a lot of variants on type checking]
> 
> I believe that even your proposal above is too hairy, for that matter.
> 
> <blah>
> people need to realize that Guile's performance is limited by its
> intimacy with the C world.  one reason is the stack-scanning GC.
> another reason is the necessary hairiness of any fine-grained control
> over invariant checking.  there probably are more reasons.
> </blah>
> 
> now, Dirk's idea of providing non-checking variants of Guile
> primitives seems to be a very good one, with one caveat: we need to
> find some way to automate the duplication.

I think that we're getting far too fancy here. There are two levels of
type checking that we have:

1) The macros (SCM_IMP, SCM_CONSP, etc, etc). Cheap as dirt. Really,
   remove a few conses from some point in the program , and you've
   pretty much made up for every type check of this form (and, for
   non-immediates, you've fetched the object into the cache, if you
   want to count cycles ;). These should be used liberally and wildly
   everywhere.

   As a sort of sub case of this, there's also checking that an object
   is internally consistant: this shouldn't need to be done in scm
   much (except for stuff that is exposed... mapping is a good example
   of something that needed more rigourous argument checking).

2) Checking that something's actually an object: quite expensive, this
   requires making sure that an argument is in the heap (see scm_cellp
   in the gc). This is something scm_ doesn't have to do often (except
   while conservatively scanning), because anything in the internals
   (or from the scheme repl) should not be creating an illegal
   object. However, gh_ should be doing this, probably as a run time
   option (checking that an integer is set to 1 or 0 is also not worth
   counting as a big performance sink ;). So, we should probably have
   a SCM_VERIFY(obj) macro for this purpose, which would expand to:

if(scm_verify_args_p)
  SCM_ASSERT(SCM_CELLP(obj) && scm_cellp(obj), obj, etc...);

   As an aside, I did implement mmap'ing the heap as a contiguous area
   to try to improve the performance of the scm_cellp (it becomes just
   a single bounds check, which is nice). The problem is that you have
   to mmap a fairly large chunk of memory (so you're stressing the vm
   just a little), and it tends to really put a damper on
   performance... it might be worth looking at again in the context of
   a lot of checks for illegal cells, though.

-- 
Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]