LNUM 2008 patch is ready :)

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

LNUM 2008 patch is ready :)

Asko Kauppi

Hi, everyone.

I'd like to initiate discussion about number modes in Lua. It's sometimes seen on the list that people find it hard to change the default number types (they can be changed in Lua, but not all implications are in the luaconf.h file). I'd like to ask, which _needs_ people have to change the type, and which would be the best set of number modes to answer such needs.

My experience below, but first a short summary to those not familiar with LNUM patch.

LNUM patch enables integer mode number optimizations, without changing the existing Lua scripting or C API interfaces. It allows moderate to huge speed increases, depending on the system. It also makes it easy to change number modes between any combination of: float / double / long double, 32/64-bit integers, optional complex arithmetics.

The LNUM patch is now ready and tested for Lua 5.1.3, and I'd like to get feedback on how people actually use it, as well as to bring out some complexities found in making it.


To start the discussion, here's my feelings about usefulness of various number modes:

LNUM_DOUBLE + LNUM_INT32: Useful as a default, absolutely ANSI C. No portability issues.

LNUM_INT64 Useful, and rather portable though 'long long' is not ANSI C. The added integer precision should be valuable (double only has 50+ bits).

LNUM_FLOAT Problematic. Math functions not ANSI C. Limited or no support on Windows. The only benefit I see is less memory consumption on embedded devices (speedwise, not much difference with LNUM_DOUBLE+LNUM_INT32). Is anyone actually using 'float' currently, and what is the main reason you do?

LNUM_LDOUBLE	Problematic. Not ANSI C, limited or no support on Windows.
I've hit a few weird behaviours on Lua 5.1.3 when lua_Number is defined as 'long double'. OS X Intel crashes; Linux x86 gives stack warnings. The reason for these is unsolved; is someone actually using (unpatched) Lua 5.1.3 with 'long double' on such systems? On other systems (OS X PowerPC, Windows XP) long double seems to work fine.

LNUM_COMPLEX It's neat, and it works (with any number mode). Surprisingly little portability issues, but it does require C99.

-asko


News I placed to LuaForge:	http://luaforge.net/forum/forum.php?forum_id=1582
Download the patch / performance sheet:	http://luaforge.net/frs/?group_id=214



Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

Ralph Hempel
Asko Kauppi wrote:

The LNUM patch is now ready and tested for Lua 5.1.3, and I'd like to get feedback on how people actually use it, as well as to bring out some complexities found in making it.

First, let me say thanks for all the hard work that yu have put into this patch over the years. I've reviewd the patch and thought about
using it in my pbLua for the LEGO NXT, but have other issues to fix
first :-)

That being said, the mode I would actually use is:

LNUM_FLOAT + LNUM_INT32

That's because the ARM7 processor and the application
itself uses 32 bit ints as the underlying unit for
calculations.

There's no need for 64 bit ints in the application.

In a similar argument, I am using a single precision
float library to save space, so double is not useful
or even necessary for the times I need floating point
math.

I am soon going to try out the 5.1.3 source for pbLua, and then I'll
try out the LNUM patch, since my users do want to be able to get
access to floats easily...

Ralph

Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

Tony Finch
In reply to this post by Asko Kauppi
On Mon, 17 Mar 2008, Asko Kauppi wrote:
>
> LNUM_INT64	Useful, and rather portable though 'long long' is not ANSI C.

It's in C99 but not C90.

Tony.
-- 
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
SHANNON: EASTERLY 6 TO GALE 8, DECREASING 4 OR 5 LATER. ROUGH OR VERY ROUGH.
MAINLY FAIR. GOOD.

Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

Niklas Frykholm-2
In reply to this post by Asko Kauppi
LNUM_FLOAT Problematic. Math functions not ANSI C. Limited or no support on Windows. The only benefit I see is less memory consumption on embedded devices (speedwise, not much difference with LNUM_DOUBLE+LNUM_INT32). Is anyone actually using 'float' currently, and what is the main reason you do?

We're using float. Precision is good enough for our purposes and it saves memory, which also is important for us.

// Niklas

Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

GrahamH
In reply to this post by Asko Kauppi

On 18/03/2008, at 12:18 AM, Asko Kauppi wrote:


LNUM_FLOAT Problematic. Math functions not ANSI C. Limited or no support on Windows. The only benefit I see is less memory consumption on embedded devices (speedwise, not much difference with LNUM_DOUBLE+LNUM_INT32). Is anyone actually using 'float' currently, and what is the main reason you do?


Agree with others, float is important from a memory perspective and to a lesser extent execution time. As a matter of interest on an ARM9 at 200MHz the difference between float on double in microsec is:

float op               float  double	
*                        12     15
/                        12     22    very significant
+                        10     13
–                        10     13
(long) to ...            10     10

Graham




Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

Asko Kauppi
In reply to this post by Niklas Frykholm-2

Do you need to suffix math functions with 'f' (s.a. 'floorf()', 'powf()') or does your compiler use right ones without the suffix?

I think in the current unpatched Lua, functions actually work with double, and then scale down to storing as floats. Each system might be different, though.

-asko


Niklas Frykholm kirjoitti 18.3.2008 kello 10:32:

LNUM_FLOAT Problematic. Math functions not ANSI C. Limited or no support on Windows. The only benefit I see is less memory consumption on embedded devices (speedwise, not much difference with LNUM_DOUBLE +LNUM_INT32). Is anyone actually using 'float' currently, and what is the main reason you do?

We're using float. Precision is good enough for our purposes and it saves memory, which also is important for us.

// Niklas


Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

BogdanM
I think so too, actually. The standard <math.h> works with doubles on all 32-bit systems I saw so far.

On Tue, Mar 18, 2008 at 11:19 AM, Asko Kauppi <[hidden email]> wrote:

Do you need to suffix math functions with 'f' (s.a. 'floorf()',
'powf()') or does your compiler use right ones without the suffix?

I think in the current unpatched Lua, functions actually work with
double, and then scale down to storing as floats. Each system might be
different, though.

-asko


Niklas Frykholm kirjoitti 18.3.2008 kello 10:32:

>> LNUM_FLOAT    Problematic. Math functions not ANSI C. Limited or no
>> support on Windows.
>>                The only benefit I see is less memory consumption on
>> embedded devices (speedwise, not much difference with LNUM_DOUBLE
>> +LNUM_INT32).
>>                Is anyone actually using 'float' currently, and what
>> is the main reason you do?
>
> We're using float. Precision is good enough for our purposes and it
> saves memory, which also is important for us.
>
> // Niklas


Reply | Threaded
Open this post in threaded view
|

Re: LNUM 2008 patch is ready :)

Asko Kauppi

Yes. One of the goals of LNUM patch has been to use the _actual_ float-type functions when available.

At least on PocketPC (embedded Visual C++ 4.0) this was an issue, if I recall right. Then again, I haven't tried LNUM on that lately. Maybe I should.

In my opinion, if floats are regarded important, Lua should compile to floats without using/needing _any_ double precision constants or functions.

-asko


Bogdan Marinescu kirjoitti 18.3.2008 kello 11:26:

I think so too, actually. The standard <math.h> works with doubles on all 32-bit systems I saw so far.

On Tue, Mar 18, 2008 at 11:19 AM, Asko Kauppi <[hidden email]> wrote:

Do you need to suffix math functions with 'f' (s.a. 'floorf()',
'powf()') or does your compiler use right ones without the suffix?

I think in the current unpatched Lua, functions actually work with
double, and then scale down to storing as floats. Each system might be
different, though.

-asko


Niklas Frykholm kirjoitti 18.3.2008 kello 10:32:

>> LNUM_FLOAT    Problematic. Math functions not ANSI C. Limited or no
>> support on Windows.
>>                The only benefit I see is less memory consumption on
>> embedded devices (speedwise, not much difference with LNUM_DOUBLE
>> +LNUM_INT32).
>>                Is anyone actually using 'float' currently, and what
>> is the main reason you do?
>
> We're using float. Precision is good enough for our purposes and it
> saves memory, which also is important for us.
>
> // Niklas