Announcing new interface: FindProc

Announcing new interface: FindProc

[Nurdin Premji]

I've just committed a new Interface with some test methods for finding a
process.

Currently this just brute forces a refresh of the Host's procPool
(exactly as requestRefreshXXX), but this will eventually become more
specialized to find a specific pid and add it to the pool and notify the
interface upon success (or failure).

I would like some input on the design of this interface as it will
eventually be replacing most if not all references to requestRefreshXXX.

Also specific opinion: Should the FindProc be under Host.java or get its
own .java file?

Re: Announcing new interface: FindProc

[Andrew Cagney]

Nurdin,

Would it be possible to post an example of how this new interface is used?

Andrew

Nurdin Premji wrote:
> I've just committed a new Interface with some test methods for finding a
> process.
>
> Currently this just brute forces a refresh of the Host's procPool
> (exactly as requestRefreshXXX), but this will eventually become more
> specialized to find a specific pid and add it to the pool and notify the
> interface upon success (or failure).
>
> I would like some input on the design of this interface as it will
> eventually be replacing most if not all references to requestRefreshXXX.
>
> Also specific opinion: Should the FindProc be under Host.java or get its
> own .java file?
>
>   

Re: Announcing new interface: FindProc

[Nurdin Premji]

There is a test case TestFindProc that uses the interface. It's pretty
basic, just stops the eventLoop on success or fail.

It looks similar to this:

class MyFinder implements Host.FindProc
{

public void procFound(Proc Proc)
{
Manager.eventLoop.requestStop();
}

public void procFoundFailed(int pid)
{
Manager.eventLoop.requestStop();
fail();
}
}

and in the code you would write:

Host.requestFindProc(pid, new MyFinder());

On Mon, 2006-11-20 at 10:01 -0500, Andrew Cagney wrote:
> Nurdin,
> 
> Would it be possible to post an example of how this new interface is used?
> 
> Andrew
> 
> Nurdin Premji wrote:
> > I've just committed a new Interface with some test methods for finding a
> > process.
> >
> > Currently this just brute forces a refresh of the Host's procPool
> > (exactly as requestRefreshXXX), but this will eventually become more
> > specialized to find a specific pid and add it to the pool and notify the
> > interface upon success (or failure).
> >
> > I would like some input on the design of this interface as it will
> > eventually be replacing most if not all references to requestRefreshXXX.
> >
> > Also specific opinion: Should the FindProc be under Host.java or get its
> > own .java file?
> >
> >   
> 

Re: Announcing new interface: FindProc

[Andrew Cagney]

Nurdin Premji wrote:
> There is a test case TestFindProc that uses the interface. It's pretty
> basic, just stops the eventLoop on success or fail.
>
> It looks similar to this:
>
> class MyFinder implements Host.FindProc
> {
>
> public void procFound(Proc Proc)
> {
> Manager.eventLoop.requestStop();
> }
>
> public void procFoundFailed(int pid)
> {
> Manager.eventLoop.requestStop();
> fail();
> }
> }
>
> and in the code you would write:
>
> Host.requestFindProc(pid, new MyFinder());
>   

Ah, thanks!

Is a ProcId better here?
Should procFoundFailed be parameterized with what was not found?
For the names (esp. procFoundFailed), check the Java libraries, or the 
patterns book, to see if there's similar code, and hence a naming 
guildeline.

BTW, some implementation nits in the above: for the failing case, no 
need to request that the event loop stop; however fail() should be 
parameterized with more meaningful information, such as what failed, and 
say the ProcId it was looking for.  And for the found case, should it 
check that things match what was being searched for?

Andrew

> On Mon, 2006-11-20 at 10:01 -0500, Andrew Cagney wrote:
>   
>> Nurdin,
>>
>> Would it be possible to post an example of how this new interface is used?
>>
>> Andrew
>>
>> Nurdin Premji wrote:
>>     
>>> I've just committed a new Interface with some test methods for finding a
>>> process.
>>>
>>> Currently this just brute forces a refresh of the Host's procPool
>>> (exactly as requestRefreshXXX), but this will eventually become more
>>> specialized to find a specific pid and add it to the pool and notify the
>>> interface upon success (or failure).
>>>
>>> I would like some input on the design of this interface as it will
>>> eventually be replacing most if not all references to requestRefreshXXX.
>>>
>>> Also specific opinion: Should the FindProc be under Host.java or get its
>>> own .java file?
>>>
>>>   
>>>       
>
>   

Re: Announcing new interface: FindProc

[Nurdin Premji]

> Is a ProcId better here?
for procFound or procFoundFailed or both?

> Should procFoundFailed be parameterized with what was not found?
Don't understand what you mean, like the error message? I guess passing
a throwable as a parameter maybe?

> For the names (esp. procFoundFailed), check the Java libraries, or the 
> patterns book, to see if there's similar code, and hence a naming 
> guildeline.
Okay checking java libraries, anywhere specific to look? Going to start
with finding files.

Re: Announcing new interface: FindProc

[Nurdin Premji]

On Mon, 2006-11-20 at 11:08 -0500, Nurdin Premji wrote:

Here is the "final" implementation of the interface:
> 
> class MyFinder implements Host.FindProc
> {
> 
> public void procFound(ProcID procID)
> {
> Manager.eventLoop.requestStop();
> }
> 
> public void procNotFound(ProcId procID, Exception e)
> {
> Manager.eventLoop.requestStop();
> fail();
> }
> }
> 
> and in the code you would write:
> 
> Host.requestFindProc(true, new ProcId(pid), new MyFinder());
			^ boolean refreshAll: whether to refresh the tasks of the proc.


Preliminary reports show that make check times have decreased from
1m7.522s to 1m0.825s.

I also tested fstack and fcore and the results are:

fstack: down from 2.3314 to 2.2094.
fcore: up from 1.4858 to 2.0045. *

There were some weird issues with fcore as shown below by actual
numbers:

Old fstack: 2.225, 2,385, 2.184, 2,666, 2,194
New fstack: 2.305, 2.161, 2.263, 2.164, 2.154

Old fcore: 1.504, 1.389, 1.036, 1.935, 1.599, 1.440
New fcore: 1.327, 3.355*, 1.019, 4.353*, 0.996, 0.978

(So technically fcore would have been much faster but for the anomalies)

I was not running these tests in single user mode which would probably
explain the anomalies, so tomorrow morning I'm going to read up on
single user mode and try to post more accurate numbers.

Re: Announcing new interface: FindProc

[Phil Muldoon]

Nurdin Premji wrote:
>
> There were some weird issues with fcore as shown below by actual
> numbers:
>
> Old fstack: 2.225, 2,385, 2.184, 2,666, 2,194
> New fstack: 2.305, 2.161, 2.263, 2.164, 2.154
>
> Old fcore: 1.504, 1.389, 1.036, 1.935, 1.599, 1.440
> New fcore: 1.327, 3.355*, 1.019, 4.353*, 0.996, 0.978
>   
fcore is pretty hard to benchmark, especially between two code-bases' as 
there are so many external factors. The processes could have 
substantially changed between one test and the other, there may have 
been other influencing factors (caching). Did you run the test 6 times 
with fcore using the new interface, and then 6 times with the old 
interface, or did you interleave the test?

I'll look tomorrow to see if I can find the spike. This little bit of 
profiling might have uncovered a bug in fcore, too!

Regards

Phil

Re: Announcing new interface: FindProc

[Nurdin Premji]

> Preliminary reports show that make check times have decreased from
> 1m7.522s to 1m0.825s.
> 
> I also tested fstack and fcore and the results are:
> 
> fstack: down from 2.3314 to 2.2094.
> fcore: up from 1.4858 to 2.0045. *
> 
> There were some weird issues with fcore as shown below by actual
> numbers:
> 
> Old fstack: 2.225, 2,385, 2.184, 2,666, 2,194
> New fstack: 2.305, 2.161, 2.263, 2.164, 2.154
> 
> Old fcore: 1.504, 1.389, 1.036, 1.935, 1.599, 1.440
> New fcore: 1.327, 3.355*, 1.019, 4.353*, 0.996, 0.978
> 
> (So technically fcore would have been much faster but for the anomalies)
> 
> I was not running these tests in single user mode which would probably
> explain the anomalies, so tomorrow morning I'm going to read up on
> single user mode and try to post more accurate numbers.

By the way, the above tests where done on evolution.

Secondary measurements in single user mode show the following. On a
sleeping funit-child with 12 threads:

fstack: up from 1.5915 to 1.596
fcore: up from 1.039 to 1.265

which is even weirder, but the numbers show that in general new is
better than old:

Old fstack: 1.616, 1.626, 1.456* 1.616, 1.621, 1.614
New fstack: 1.593, 1.593, 1.593, 1.601, 1.598, 1.600

Except for the old fstack getting a burst of speed in the middle there,
the new method is consistently faster.

Old fcore: 0.479, 1.423*, 0.451, 0.933*, 0.968*, 1.977*
New fcore: 0.429, 0.429, 3.106*, 0.433, 2.754*, 0.437

Here again we have weird hangs at odd times. I don't know why.

Re: Announcing new interface: FindProc

[Nurdin Premji]

On Wed, 2006-11-22 at 20:11 -0600, Phil Muldoon wrote:
> Nurdin Premji wrote:
> >
> > There were some weird issues with fcore as shown below by actual
> > numbers:
> >
> > Old fstack: 2.225, 2,385, 2.184, 2,666, 2,194
> > New fstack: 2.305, 2.161, 2.263, 2.164, 2.154
> >
> > Old fcore: 1.504, 1.389, 1.036, 1.935, 1.599, 1.440
> > New fcore: 1.327, 3.355*, 1.019, 4.353*, 0.996, 0.978
> >   
> fcore is pretty hard to benchmark, especially between two code-bases' as 
> there are so many external factors. The processes could have 
> substantially changed between one test and the other, there may have 
> been other influencing factors (caching). Did you run the test 6 times 
> with fcore using the new interface, and then 6 times with the old 
> interface, or did you interleave the test?

The tests where done 6 times with old fcore, then 6 times with new
fcore.
(or was it new then old, can't remember)