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: New: SCM_DEBUG_CELL_ACCESSES


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

> - it seems that the checks for scm_heap_table[seg_id].valid != NULL are
>   unnecessary, since that feature is not used.  There's even a comment
>   about it not being used at the head of gc.c.  If we want to speed
>   things up, unused features should be removed.

I too wonder what this thing supposed to be for.

> - The comments about span are wrong, IMO.  It says, span is the "number of
>   SCM words per object in this segment", but it rather seems to be the
>   number of scm_cells per object:  span is 1 most of the times.

I fixed the comment, thanks!

>   However, for the sake of generalization it may be better to make
>   span be the number of SCM/scm_bits_t words: This would even allow
>   for cells with 3 entries etc.

what would 3-word (or 5-word) cells be useful for?  (they are a bad
idea from the alignment and mark-bit space consumption points of view, 
but still).

> - The initial number of stack frames when guile has started seems to be
>   very large.  As soon as the repl is reached, there are about 70 stack
>   frames (with the debugging evaluator, I haven't checked the other
>   one).  Since the size of the stack defines the time for conservative
>   stack scanning, continuation creation and calling, this is something
>   that we also should try to reduce, if possible.

I doubt that continuations go that deep, but it's worth checking...

> I have instrumented the code of scm_mark_locations with counters to see
> the relative frequencies of the different execution paths.

very interesting.  could you send your instrumentation so I can play
with it?  or maybe even check it in, conditionally?

generally, I don't know if it's a good idea to try to minimize the
number of initial stack frames (it may distort the code too much), but
I do know that the `scm_cellp' logic could be a little streamlined
(the binary search could be replaced with two array lookups,
basically).

-- 
You have a tendency to feel you are superior to most computers.

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