[squeak-dev] Hydra benchmarking

Hi -

I was demoing Hydra at VPRI today and Yoshiki came up with a nice little
idea for a Hydra benchmark. It basically goes like this:

HydraVM doIt: 'Transcript cr; show: ''Background: '', 0 tinyBenchmarks'
at: 2.
Transcript cr; show: 'Foreground: ', 0 tinyBenchmarks.

The interesting part is that on a multi-core box it "does the right
thing" which means it basically prints the same results in roughly the
same time.

What is weird is that on a single-core box, I get the "same results" but
for the wrong reasons and apparently offset by a couple of seconds. It
behaves as if first the foreground process runs and then the background
process. Anyone having an idea how to fix the benchmark so that it comes
up with the correct numbers on a single core box?

[BTW, if you have dual-core I'm pretty sure that extending the above by
a couple more images will show similarly skewed results]

Cheers,
   - Andreas

On 26/02/2008, Andreas Raab <[hidden email]> wrote: I think it's because main thread have slightly higher priority in windows.
Try load two secondary images and use:

 (HydraInterpreter at: 2) doIt: 'Transcript cr; show: ''First: '', 0
tinyBenchmarks'.
 (HydraInterpreter at: 3) doIt: 'Transcript cr; show: ''Second: '', 0
tinyBenchmarks'.

This is results on my single core:

First: 93498904 bytecodes/sec; 2251285 sends/sec
Second: 91756272 bytecodes/sec; 2230768 sends/sec


Also, i'd do it like following:

[ HydraVM doIt: 'Transcript cr; show: ''Background: '', [ 0
tinyBenchmarks ] timeToRun'
  at: 2.
  Transcript cr; show: 'Foreground: ',  [0 tinyBenchmarks] timeToRun.
] timeToRun

On single core, sum of local+remote doit, should be roughly equivalent
to outer timeToRun.
On dual core all #timeToRun should be roughly equivalent.

>  [BTW, if you have dual-core I'm pretty sure that extending the above by
>  a couple more images will show similarly skewed results]
>
>  Cheers,
>
>    - Andreas
>
>


--
Best regards,
Igor Stasenko AKA sig.

oops, no it shouldn't work as i described :)

> --
>  Best regards,
>  Igor Stasenko AKA sig.
>


--
Best regards,
Igor Stasenko AKA sig.

> I think it's because main thread have slightly higher priority in  
> windows.

Ah, that reminds me, you cannot do UI work on anything other than the  
main thread in carbon and I think
Cocoa applications in os-x.

When we migrated from InputSensor to EventSensor I had changed th pre-
os-x (OS8.x) squeak VM to use cooperative threading which allowed us  
to run the
VM on one thread, and the UI on another.  This was changed when OS-X  
came out to run the interpret() on a pthread with the main pthread  
handing the UI.
The UI thread used some mutex semaphores to place data on the VM event  
queue. All was happy, but Apple started enforcing the rules about UI  
calls only on the main thread.

Although I had a lockUI call to swap the call or FFI call to the main  
thread which worked quite well, Sophie started getting serious about  
FFI calls to quicktime we ran into major problems
with it's usage of Open/GL.

This was fixed in 3.8.12b1 when I switch to dispatching the  
interpreter loop via a carbon event and back to a form of co-operative  
threading.
Mac Carbon 3.8.12b1 Alter VM so that the interpreter() loop is  
dispatched on the UI thread and we poll for pending UI events. This is  
to allow quicktime FFI calls to work on the main thread that contains  
the UI, and to avoid cross thread OpenG/L calls which seem to crash  
the VM

I note this because someday someone might want to make a UI related  
FFI call on a Hydra thread and then something unexpected could  
happen.  More research required to understand if this is an issue with  
Cocoa applications.
--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================