[squeak-dev] Re: [Vm-dev] MadgwickAHRS plugin and support code

David T. Lewis lewis at mail.msen.com
Tue Sep 15 00:12:04 UTC 2015


On Mon, Sep 14, 2015 at 11:33:35PM +0200, Levente Uzonyi wrote:
> We might as well have primitives which write their result into an object 
> passed as parameter, or primitives which update the receiver, like the 
> ones provided by KedamaFloatArray. But with SmallFloat64 being on the way, 
> it's not that tempting to write such primitives.
> 
> Levente

Actually, that is exactly what I did. The caller provides a pre-allocated
(and potentially reusable) FloatArray of size 4, and the primitive copies
four result values into the array fields. There is no need for allocating
Float objects within the primitive, and no need to convert float to double
in the primitive. This may or may not be useful depending on how the
primitive is used, but it does allow the user an opportunity to optimize
both by reusing an existing FloatArray instance for the results, and by
allocating new Float object only if and when the elements of that array
are actually read and used.

I would expect that FloatArray will still have 32-bit float values in
a 64-bit object memory, after all that is what it was designed to do.
The need to allocate Float objects and do conversion from single to
double floats should go away with 64-bits, so that should be a win.
I expect that updates for MadgwickAHRSPlugin should be minimal.

Dave


> 
> On Mon, 14 Sep 2015, Eliot Miranda wrote:
> 
> >Hi Herbert,
> >
> >On Sun, Sep 13, 2015 at 4:34 AM, Herbert K??nig <herbertkoenig at gmx.net> 
> >wrote:
> >      Hi,
> >
> >      Am 13.09.2015 um 06:31 schrieb David T. Lewis:
> >            Well it's basically the only convenient way to deal with float 
> >            (as opposed to double) floating point values. In Squeak, a
> >            Float is a C double, and AFIK the only thing that directly 
> >            represents single precision floats is FloatArray. You would be
> >            justified in being scared of them, especially if any of this 
> >            sounds like it makes sense. But it does work and it might be
> >            more efficient than arrays of Float (C doubles). Or maybe not, 
> >            I don't have any way to measure it. But I tried to set
> >            things up so that the FloatArray things can be reused to avoid 
> >            allocations and type conversions, so maybe it will help.
> >
> >
> >      FloatArray offers a lot of speed up as long as the operations 
> >      provided by Float array are sufficient. Getting Squeak Floats into 
> >      and
> >      out of Float Array is expensive.
> >      This:
> >      Time millisecondsToRun:
> >      ?? ?? [|array1 array2|
> >      ?? ?? array1 := (1.0 to: 10000.0 by: 0.1) asArray.
> >      ?? ?? array2 := (10000.0 to: 1.0 by: -0.1) asArray.
> >      ?? ?? 1000 timesRepeat: [|result|
> >      ?? ?? ?? ?? result := array1?? * array2]]
> >      22 seconds
> >      is not much slower than using FloatArray
> >      Time millisecondsToRun:
> >      ?? ?? [|array1 array2|
> >      ?? ?? array1 := (1.0 to: 10000.0 by: 0.1) asArray.
> >      ?? ?? array2 := (10000.0 to: 1.0 by: -0.1) asArray.
> >      ?? ?? 1000 timesRepeat: [|result|
> >      ?? ?? ?? ?? result := (array1 asFloatArray * array2 asFloatArray)]]
> >      19 seconds
> >      If you change the last line to use more operations supported by 
> >      FloatArray like:
> >      ?? ?? ?? ?? result := (array1 asFloatArray * array2 asFloatArray + 
> >      7.0 * 3.0) sum
> >      with FloatArrays you get the same speed, without the conversion to 
> >      FloatArray it takes three times as long.
> >
> >      If you need to use FloatArray>>at: and #at:put very often 
> >      FloatArrays may get slower than Arrays of Float.
> >      So benchmark and benchmark again.
> >
> >
> >That's right.?? Using FloatArray implies an object allocation on every 
> >at:, to construct the (boxed) Float result. ??64-bit Spur will change this
> >equation because most of the time the floats fetched will be immediate, 
> >instances of SmallFloat64.?? And indeed they may make it attractive to have
> >a 64-bit float array type.
> >
> >
> >      And if your values get small, FloatArray may round them to zero 
> >      which is bad for division.
> >
> >      I used FloatArray a lot for?? Audio processing and neural networks 
> >      but they need to be handled with care.
> >      I ended up using both depending on the algorithm.
> >
> >      Cheers,
> >
> >      Herbert
> >
> >
> >
> >
> >
> >
> >--
> >_,,,^..^,,,_
> >best,??Eliot
> >
> >

> 



More information about the Vm-dev mailing list