From: Markus <markus@...>
Date: 2004-10-26T23:45:37+09:00
Subject: Re: Errors in line numbers reported?





On Mon, 2004-10-25 at 22:39, Markus wrote: 
> 
>      I agree with Ara; so instead I will sign up under the always
> implicit "more foolhardy" clause in the hopes of learning a little by
> claiming less.
> 
>      I have a patch (attached).  It removes the 8k line limit on error
> tracking but increases the size of the RNODE to 36 bytes (if I calculate
> correctly) from the easier to align 32 bytes.  I suspect that this is
> where the performance hit would come from, but I have been unable to
> measure any consistent speed difference between the patched and
> unpatched versions, so I may not be testing the right cases.  It may
> also be that the savings of not having to shift the bits around makes up
> for the alignment hit somewhat, but I have not tested this idea.

On Tue, 2004-10-26 at 01:52, ts wrote:
> 
>  The game is to not change the size of R struct

     Yes, I see that.  That is why I made a point of calling out the
fact that is _does_ change the size.  But what I am trying to learn is
why we care.  I assumed (on the bases of comments about speed and my
knowledge of how processors work) that it was an alignment problem--that
changing the size would break the alignment and make it slower.  But I
was not able to measure any difference.


On Tue, 2004-10-26 at 04:21, trans. (T. Onoma) wrote:
On Tuesday 26 October 2004 07:05 am, Yukihiro Matsumoto wrote:
> 
> This has come up else where and I am wondering about the effects of 
> this.  12.5% is relative. Were talking just a couple of bytes per
> object, yes? But also that means a 12.5% increase in total memory
> footprint? How large is that footprint now, in general?
> 

     I think the 12.5% increase only applies to the generated code size,
which I suspect is only a fraction of the total memory footprint; I
think it comes to 4 bytes per node, which (estimating ~5 nodes per line,
average) comes to around 160K for a 8k line program.

> Also are there any speed issues with this increase?

     Probably, but I have not learned how to detect them.  In my 
(admittedly simple) tests, there is no consistent difference between the
patched and unpatched versions,

On Tue, 2004-10-26 at 07:04, Ara.T.Howard@noaa.gov wrote:

> how about storing the line in some word aligned bytes __behind__ nd_file?
> 
>    nd_file = "a.rb\0xxxx";
> 
> the nd_line(n) would be something like
> 
>    (unsigned long)*((unsinged long *)(nd_file + ((strlen(nd_file) + 4) % 4) - 1));
> 

     I thought of this.  The problem is that it makes the memory use
increase much faster, since you now have to duplicate the whole file
name for each node (before, it is shared).

     What would, I think, work better is to store a line number OFFSET
with the file name (but as an unsigned integer preceding the file name
rather than as text following it); this would initially be zero, but a
new name-and-offset structure would have to be allocated every 8k lines
(adding ~100*2*(file_name_length+4)/(8k*32+file_name_length) ~= 80k/256k
~= 0.3% to the memory footprint).

     I will try to work up a patch that uses this method later today,
unless someone else wants to try their hand at it.

       -- Markus


P.S. I am still interested if anyone can show a measurable speed impact
from 36 byte RNODEs ve the 32 bytes.  I'm not so interested in the
arguments that it should, in theory, make things slower--which I can
already clearly see for myself--but rather want to discover under what
circumstances this could actually be demonstrated.