Problem with Hydra's startUp

An .image with the HydraVM-sig.8 package loaded does not startUp on a  
non-Hydra VM.

One problem is that Hydra's #startUp methods do not check for #isHydra and  
so they stumble into a #mustBeBoolean situation, another problem is that  
the .image then freezes (might be caused by something else).

Asking for (HydraVM isHydra) in the #startUp methods helped ;-)

/Klaus

On 17/02/2008, Klaus D. Witzel <[hidden email]> wrote:
> An .image with the HydraVM-sig.8 package loaded does not startUp on a
> non-Hydra VM.
>
> One problem is that Hydra's #startUp methods do not check for #isHydra and
> so they stumble into a #mustBeBoolean situation, another problem is that
> the .image then freezes (might be caused by something else).
>
> Asking for (HydraVM isHydra) in the #startUp methods helped ;-)
>

My fault, i forgot to check loading HydraVM package under non-Hydra VM.

Currently I doing major rewrite of checkForInterrupts() and all is
what around it.
With new changes, Hydra will be truly event-driven and without mess in
checkForInterrupts().

Stay in touch for the next update anytime soon :)

> /Klaus
>

--
Best regards,
Igor Stasenko AKA sig.

HydraPing depends on methods which are provided by FFI, but FFI is no  
longer in stock .images (which I'm using as all the Squeakers do ;-) So  
HydraPing DNUs on #unsignedLongAt:put:, but there are other messages in  
the #'platform independent access' category of ByteArray which can do what  
you want HydraPing to do.

On Sun, 17 Feb 2008 11:38:23 +0100, Igor Stasenko wrote:

> On 17/02/2008, Klaus D. Witzel wrote:
>> An .image with the HydraVM-sig.8 package loaded does not startUp on a
>> non-Hydra VM.
...
> My fault, i forgot to check loading HydraVM package under non-Hydra VM.
>
> Currently I doing major rewrite of checkForInterrupts() and all is
> what around it.

Did you consider the performance comparision which someone asked about,  
over in squeak-vm list?

> With new changes, Hydra will be truly event-driven and without mess in
> checkForInterrupts().
>
> Stay in touch for the next update anytime soon :)

Hurry up ! :)

>> /Klaus
>>
>

On 17/02/2008, Klaus D. Witzel <[hidden email]> wrote:
you mean mentioned 10-20% speed loss?
It's an impartial drawback of objectification, there's little what we
can do about this.
I didn't putted benchmarks in public, but i measured them.
- microBenchmarks shows about 5% bytecode crunching speed loss
- macroBenchmarks (there are 4 of different macro benchmarks which
Andreas gave me) showing about 10% speed loss on my box, interesting
that of them runs faster, without any reason :)


--
Best regards,
Igor Stasenko AKA sig.

On Sun, 17 Feb 2008 12:09:14 +0100, Igor Stasenko wrote:

Nah, what Gulik asked in the "Interrupt checking in HydraVM using event  
system" thread in squeak-vm. BTW: squeak-vm list does not show up all  
messages (for me), some I only see in NNTP's  
gmane.comp.lang.smalltalk.squeak.vm.devel ...

> It's an impartial drawback of objectification, there's little what we
> can do about this.

Yes, that's a tough one.

> I didn't putted benchmarks in public, but i measured them.
> - microBenchmarks shows about 5% bytecode crunching speed loss
> - macroBenchmarks (there are 4 of different macro benchmarks which
> Andreas gave me) showing about 10% speed loss on my box, interesting
> that of them runs faster, without any reason :)

Which ones: some as in "don't know which one"? Are they posted somewhere?

On 17/02/2008, Klaus D. Witzel <[hidden email]> wrote:
>
> Nah, what Gulik asked in the "Interrupt checking in HydraVM using event
> system" thread in squeak-vm. BTW: squeak-vm list does not show up all
> messages (for me), some I only see in NNTP's
> gmane.comp.lang.smalltalk.squeak.vm.devel ...
>

I don't expect too much speed loss with new refactorings. Instead, i'm
expecting some speedup :)
- there is no need to do checks for every N ms (or nanoseconds), since
interrupt to handle events now is possible only, when there are events
pending.
Now, the only (uniform) way to interrupt interpreter loop is by
posting event, notifying system that there is something needs to be
done beyond it.
And check for pending events is a simple read of pointer value (can't
be too much slower than decrementing interruptCheckCounter :)


--
Best regards,
Igor Stasenko AKA sig.