Hi Scott, Hi John, Hi Dan,

	Sorry, I couldn't get back to you all sooner. I have been a bit
busy putting a final touch on my 'double clickable FreeCell.st'. More
details in another message, though.

	Thanks for your enlightments. At John's suggestion and to give
Scott a toy to play in his optimisation effort, I made it configurable
from the initialisation file 'SqM.ini' the following parameters:

(lines with ';;' at the front are commented out).

[TuningParams]
;;  Was 4097 Now Default: 8192
;; _EXTERNAL_PRIMITIVE_TABLE_SIZE_   = 16384    

;;  Was 501 Now Default: 1024
;; _SEMAPHORES_TO_SIGNAL_SIZE_       = 512    

;;  Was 4097 Now Default: 8192
_METHOD_CACHE_SIZE_               = 16384    

;;  Was 65 Now Default: 128
;; _AT_CACHE_SIZE_                   = 35

;;  Was 26 Now Default: 64
;; _REMAP_BUFFER_SIZE_               = 16

;;  Was 2501 Now Default: 4096
;; _ROOT_TABLE_SIZE_                 = 4096

It was found that the VM will crash at different places as
_AT_CACHE_SIZE_ is reduced.

Higher _METHOD_CACHE_SIZE_ and lower _AT_CACHE_SIZE_ tend to crash the
VM.

This doesn't seem to enforce Dan's statement:

> > int atCache[65];

> Well, I just thought about what it was doing and guessed at what it
would take.
> You could try doubling it and halving it. I think it will provide most
of its
> benefit with only one entry.

Did I misunderstand this statement ?

I will leave it as an exercise for those who will take a trip in the
SqueakMobile to implement some primitives to modify these parameters to
'change the flat tires and clean the spark plugs' while zooming back to
the future. ;-)

Cheers,

PhiHo.


-----Original Message-----
From: Scott A Crosby [mailto:crosby at qwes.math.cmu.edu] 
Sent: Thursday, March 28, 2002 10:36 PM
To: PhiHo Hoang
Cc: Squeak List
Subject: Fixed limits in the image. (was Re: ...)


On Sat, 16 Mar 2002, PhiHo Hoang wrote:

> My only concern was that how were the numbers arrived at for things
> like:

> 		int atCache[65];

AFAIK, This is an optimization; it doesn't affect correctness.  But,
experimentation for different sizes might be fruitful.  Anyone know how
much the atCache affects the runtime? I may get a chance to look at it.

> 		int (*compilerHooks[16])();
> 		int externalPrimitiveTable[4097];

Don't know about these.

> 		int methodCache[4097];

This is superseeded by the new methodcache.

In any case, this is an optimization; it does not impact corrrectness.
But, experimentation for different sizes might be fruitful.

In the new methodcache, I arbitrarly chose 2048 slots (creating 8192
actual entries, and an array of size 65537 (256kb) to hold it),
believing that no inner loop in morphic or elsewhere is going to be
using more than 1000-2000 selector/class pairs at once.

> 		int remapBuffer[26];

I know nothing about this.

> 		int rootTable[2501];

With the root-table-overflow patch, a root table overflow costs an
incrgc and a tenure operation, not a fullGC. Thus, this parameter has
lost most of its importance. (For certain workloads, experimentation may
show that this number should be reduced.)

In any case, barring pathological cases, AFAIK, this parameter does not
impact correctness.

> 		int semaphoresToSignalA[501];
> 		int semaphoresToSignalB[501];

Dunno about these. Would these be a limit on the maximum number of open
sockets?


Scott