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:
> 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? > 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. |
> 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. > oops, no it shouldn't work as i described :) > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Igor Stasenko
> 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 = = = ======================================================================== |
Free forum by Nabble | Edit this page |