🚀 go-pugleaf

lectro@stein.u.washington.edu (Jonathan Maier) writes:

>In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu> ematias@csri.toronto.edu (Ummm... me!) writes:
>>- having 16 integer variables in the struct would work.
>>- having 32 integer variables in the struct would work.
>>- having 48 integer variables in the struct would NOT work.
>>- having 64 integer variables in the struct would work.
>>- having 80 integer variables in the struct would NOT work.
>>- having 96 integer variables in the struct would NOT work.
>>- having greater than 96 ints in the struct would NOT work.

>It looks like the number of variables should be 2 raised to some power
>(ie- 16(=2^4), 32(=2^5), 64(=2^6), etc.).  You'll probably notice that
>some things are more "efficient" if they map directly into the binary
>(base 2) scheme that the computer is based on.

Are you creating/destroying these things dynamically? (malloc/free,
new/delete)

I've noticed that heap gets allocated in paragraphs (multiples of 16 bytes)
since that's the minimum increment of a segment pointer.

Possibly there's some optimization in the allocation function which
allows it to take short cuts when the request is for exactly (2^n)*16
bytes (no that can't be right, it doesn't take into account the space
for the next-block pointer, which is included in the allocated block).

In any case, my wild guess is that setting your data up so it aligns
on exact 2^n paragraph boundaries is simplifying the segment-pointer
arthmetic somehow.  Unless there's a real nuts-and-bolts EXPERT out
there (maybe on Monday AM?), you'd have to look at the assembler code
to find out what the difference was between the fast and slow cases.
--
==Steve Watson: watson@sce.carleton.ca===Carleton University, Ottawa, Ontario==
| The above is the output of a 7th-order Markovian analysis of all posts on   |
| this group for the past month.  Not only is it not Carleton's opinion, it's |
| not even *my* opinion: it's really just a mish-mash of all YOUR opinions!   |