chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Nursery sizing considered stupid


From: Brandon J. Van Every
Subject: Re: [Chicken-users] Nursery sizing considered stupid
Date: Thu, 20 Jul 2006 23:39:15 -0700
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

John Cowan wrote:
Brandon J. Van Every scripsit:

  
"J'accuse!"  It is of course open source, which implies open 
responsibility.  What level of responsibility are you personally willing 
to take about this problem?  You willing to figure out what's good or 
bad about nsample?  I'm willing to implement a better stack-size.cmake 
script, and I'm doing that tonight.  But I'm not willing to dig into 
nsample or revamp it.  
    

Since I believe that the whole idea of figuring out the correct nursery
size by measuring raw code speed is fundamentally flawed, 

But what is your basis for believing that?  "nsample is flawed" does not mean the principle is flawed.

it follows that
I don't believe that tweaking the use of nsample will help, *and* I don't
believe that changing nsample to do something different will help either.
  

It would follow, but I'm challenging your axiom.  Or else, demonstrate how it is not an axiom.

My proposal is the same as it was in my original message, and is simple.
Forget the variable-size nursery altogether and go with 128K, period.
Make this tweakable in the configuration file, and for anything else,
people can use -:s.  You're already halfway there.
  

I'm not halfway there, I'm all the way there.  DETERMINE_BEST_STACK_SIZE can be turned on or off at will by the user.  The only policy decision to be made is whether ON or OFF should be the default.  Currently it is ON.  My personal view is it should remain ON until we've collected a number of field trials and have data on variance.  Defaulting to OFF means nobody will try it at all, and we'll have no basis for judgement.

I would also like to see a reasoned explanation for why nsample is deficient.  That would inform us whether it can be improved or is hopeless.


Cheers,
Brandon Van Every



reply via email to

[Prev in Thread] Current Thread [Next in Thread]