Integer Maths vs floating point - page 4 - Script Writing - CHDK Forum
« previous next »
Pages: 1 2 3 [4] 5   Go Down

Integer Maths vs floating point

  • 40 Replies
  • 10685 Views
*

Offline reyalp

  • ******
  • 14140
Re: Integer Maths vs floating point
« Reply #30 on: 27 / April / 2021, 17:10:09 »
Advertisements
One obvious question is how much slower this is than normal Lua math, or implementing more of it in C, so I revisited my tests in https://chdk.setepontos.com/index.php?topic=12451.msg129505#msg129505

The following results are from g7x (edit: digic 4 D10 is about 1/3 the speed of g7x, as expected).

Addition:
Code: [Select]
=local a=fmath.new(1700000) local b=fmath.new(3) local z set_yield(-1,-1) t0=get_tick_count() for i=0,100000 do z=a+b end return get_tick_count() - t0
5:return:2400

Multiplication:
Code: [Select]
=local a=fmath.new(1700000) local b=fmath.new(3) local z set_yield(-1,-1) t0=get_tick_count() for i=0,100000 do z=a*b end return get_tick_count() - t0
8:return:2420

Division:
Code: [Select]
=local a=fmath.new(1700000) local b=fmath.new(3) local z set_yield(-1,-1) t0=get_tick_count() for i=0,100000 do z=a/b end return get_tick_count() - t0
9:return:2710
These results were fairly repeatable, with add and multiply in the 2400-2500 range, and division around 2700.

Conclusions:
1) The native Lua number results were all around 100, so fmath is about 25x slower than Lua numbers. 40 kflops is not fast (wikipedia tells me the original 8087 did 50), but if you aren't doing iterative calculations with thousands of steps, it shouldn't be a concern.

2) The earlier C tests show that much of the difference is Lua overhead, rather than the inherent cost of using doubles.

I wondered if calling a C function directly rather than going through metatables would help, but it was pretty similar

Code: [Select]
=local fadd=getmetatable(fmath.new(1)).__add local a=fmath.new(1700000) local b=fmath.new(3) local z set_yield(-1,-1) t0=get_tick_count() for i=0,100000 do z=fadd(a,b) end return get_tick_count() - t0
11:return:2440

You might be able to optimize it by implementing the ability to modify fmath values in-place (notionally x:add(y) to increment fmath value x by y, but in practice you'd want to use local functions which would be uglier), but unless someone shows a compelling need I don't think this would be worthwhile.


Another question how error conditions are are handled:
Quote
=x=-fmath.new(1)/fmath.new(0) return x:int()
3:return:-2147483648
=x=-fmath.new(1)/fmath.new(0) return x:tostr()
4:return:'-inf'
 =x=-fmath.new(0)/fmath.new(0) return x:int()
5:return:0
This mirrors the behavior of Lua numbers in our implementation, which is probably the right thing.  On digic 6 we had to add special code to avoid exceptions on integer division by 0 http://chdk.setepontos.com/index.php?topic=11316.msg124951#msg124951
« Last Edit: 27 / April / 2021, 18:20:49 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline pigeonhill

  • *****
  • 1164
Re: Integer Maths vs floating point
« Reply #31 on: 27 / April / 2021, 17:23:52 »
@reyalp @philmoz

I obviously can’t speak for all use cases, but in my case I will likely limit the fmath calculations to where they are needed.

For example, calculate near and far depths of field using fmath, then convert them to integers. Thus, in my case, the fmath overhead will not be an issue.

But, as I say, I can’t speak for all use cases, eg repeatedly inverting a large matrix in an iterative loop  ;)
« Last Edit: 27 / April / 2021, 17:47:44 by pigeonhill »
Logged
*

Offline reyalp

  • ******
  • 14140
Re: Integer Maths vs floating point
« Reply #32 on: 27 / April / 2021, 19:31:20 »
@philmoz:
I noticed on vxworks A540 and D10 through elph130 (dry r52), fmath.tostr() only returns the literal string 'f'.

This is presumably because the underlying Canon function doesn't include float support. Implementing the full range of printf format specifiers ourselves probably isn't worth it, but would be nice to have a basic conversion at least.

elph180 (dryos r58) supports '%f', so it this is at least partly dryos version rather than CPU architecture related. I haven't determined the exact cutoff or how to identify the difference in disassembly yet. This is somewhat annoying since modules aren't allowed to have ifdefs beyond CPU architecture, so we'd probably want something like a format_float function ifdef'd in the core and exported.

Also, FWIW, the test script could be updated to check the results are as expected with assert rather than relying on the user. This is just a general note, you don't have to implement it :)

edit:
It looks like support for '%f" can be identified from the function called by firmware vsprintf. Firmware with support has code like
Code: [Select]
cmp reg ,#0x64 // 'd'
beq ...
cmp reg ,#0x65 // 'e'
beq ...
cmp reg ,#0x66 // 'f'
bne ...

While firmware without looks like
Code: [Select]
cmp reg,#0x64 // 'd'
cmpne reg,#0x69 // 'i'
bne ...
b ...
From this, it looks like sx280 (and presumably all digic 6 and later) support, while digic <= 5, dryos54 and later support, based on elph130 not supporting, and elph140 supporting.

I've only spot checked in Ghidra though, so it's possible there's other variations.
« Last Edit: 27 / April / 2021, 21:38:55 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Integer Maths vs floating point
« Reply #33 on: 28 / April / 2021, 00:10:22 »
@pigeonhill


Here is an updated version for the M3, and an updated patch.


This includes the modulus operator (z = x % y), as well as the trig functions sin, cos, tan, asin, acos, atan, pol and rec.
The trig functions only work in radians, unlike the imath library which has functions or both degrees and radians.


One significant change that will likely affect your script is the tostr function.
As reyalp pointed out, the %f format is not supported on all cameras. I've changed the parameter of tostr from a string to an integer which specifies the number of decimal digits to output. Internally it uses integer conversion and %d formatting to create the string. It's not as flexible and won't handle very large or very small values at the moment.


Phil.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline pigeonhill

  • *****
  • 1164
Re: Integer Maths vs floating point
« Reply #34 on: 28 / April / 2021, 01:29:15 »
@philmoz @reyalp

Once again many thanks to both of you for continuing to refine the fmath implementation.

For my current needs I handle numbers to strings pretty simply myself from integers, as all I need to do is display numbers as microns, mm, cm, m. But I will look into using tostr

The fmath use is restricted to calculating the DoFs etc, where having fmath really helps.

I’ll have another refactoring session today ;-)
Logged
*

Offline pigeonhill

  • *****
  • 1164
Re: Integer Maths vs floating point
« Reply #35 on: 28 / April / 2021, 04:17:53 »
@philmoz

Unless I'm doing it wrong, I would like to suggest a tweak to the tostr function.

My suggestion is that tostr(1.23,0) = 1

At the moment I get 1.0

For example, here is a function to covert distances:

Code: [Select]
function units(xx)
    if xx:int() > 5000 then
        xx=(xx/1000):tostr(1).."m"
    elseif xx:int() > 1000 then
        xx=(xx/10):tostr(1).."cm"
    else
        xx=xx:tostr(0).."mm"
    end
    return xx
end

The mm output string should ideally be the integer value of the input, if the tostr is set to 0.

Hope that makes sense?

Cheers

Garry
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Integer Maths vs floating point
« Reply #36 on: 28 / April / 2021, 04:39:43 »
Quote from: pigeonhill on 28 / April / 2021, 04:17:53
Unless I'm doing it wrong, I would like to suggest a tweak to the tostr function.
My suggestion is that tostr(1.23,0) = 1


@pigeonhill


Good pickup - I'll fix that soon.


Phil.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Integer Maths vs floating point
« Reply #37 on: 28 / April / 2021, 05:39:43 »
Update to fix the fmath tostr(0) issue.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline pigeonhill

  • *****
  • 1164
Re: Integer Maths vs floating point
« Reply #38 on: 28 / April / 2021, 06:22:39 »
Phil

That fixed it  :)

Cheers

Garry
Logged
*

Offline pigeonhill

  • *****
  • 1164
Re: Integer Maths vs floating point
« Reply #39 on: 03 / May / 2021, 03:53:19 »
@philmoz @reyalp

As you have picked up I’m only a Lua scripter, ie not a C coder.

However, I just came across this video on the ML Discord and found it fascinating, ie bit shifting etc.

Just thought I would share it for a U.K. Bank Holiday watch.

Cheers

Garry

https://www.youtube.com/c/Nemean/videos
« Last Edit: 03 / May / 2021, 03:57:00 by pigeonhill »
Logged
Pages: 1 2 3 [4] 5   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal