Math.Random() always returns 0

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

Re: D3DCREATE_FPU_PRESERVE

Roberto Ierusalimschy
> I'm not really skilled enough to attempt more than a few approaches - those
> listed - and I'm not really sure I'm up to the task of creating effective
> benchmarks.  Basically, I (and others, apparently) am simply curious to know
> if anyone has checked to see exactly what impact this flag creates vs.
> changing the Lua number to float, etc.  From what I've heard everyone has
> simply adopted the flag, and damn the cost.

Do not forget these two approaches:

1) change lua_number2int in luaconf.h to this:

  #define lua_number2int(i,d)   __asm fld d   __asm fistp i

(Should have no performance penalty, but only works on selected compilers.)


2) change lua_number2int in luaconf.h to its default definition:

  #define lua_number2int(i,d)     ((i)=(int)(d))

(Should always work, but may have a performance penalty in Lua; but
how much??)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

RE: D3DCREATE_FPU_PRESERVE

Bilyk, Alex
In reply to this post by Dominic Wong
DirectX switches the FPU to single precision by default [at least used
to]. So, even though Lua number is defined as double, all one has to
work with is 23 bits of precision. This means that full 32 bit integers
are impossible to store in a Lua number under a DirectX app. On one
project [with Lua 4.x] we had discovered this only too late and resorted
to making our Lua wrapper changing FPU precission back and forth [lookup
fldcw instruction on x86 FPUs] on every Lua entry. Lua was used in a not
time cricical part of the project there. Doing this FPU massage in a
time critical part will be pretty slow as an atomic operation done over
and over every frame, but compared to searching for a single Lua key in
a table it would likely amount to nothing [benchmark it]. Anyhow, you'd
want to cache the state of FPU so you'd only change it when you need to.
Also, instead of doing it per Lua call you can do this at a higher
application level where you know you don't make any DirectX calls, but
do enter Lua. Single precision on FPU makes divides and sqrts go about
twice as fast and this is one reason to use it instead of double
precision. 

AB

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Roberto
Ierusalimschy
Sent: Thursday, May 25, 2006 8:53 AM
To: Lua list
Subject: Re: D3DCREATE_FPU_PRESERVE


> I'm not really skilled enough to attempt more than a few approaches - 
> those listed - and I'm not really sure I'm up to the task of creating 
> effective benchmarks.  Basically, I (and others, apparently) am simply

> curious to know if anyone has checked to see exactly what impact this 
> flag creates vs. changing the Lua number to float, etc.  From what 
> I've heard everyone has simply adopted the flag, and damn the cost.

Do not forget these two approaches:

1) change lua_number2int in luaconf.h to this:

  #define lua_number2int(i,d)   __asm fld d   __asm fistp i

(Should have no performance penalty, but only works on selected
compilers.)


2) change lua_number2int in luaconf.h to its default definition:

  #define lua_number2int(i,d)     ((i)=(int)(d))

(Should always work, but may have a performance penalty in Lua; but how
much??)

-- Roberto


Reply | Threaded
Open this post in threaded view
|

Re: D3DCREATE_FPU_PRESERVE

Robert Osfield
On 5/25/06, Bilyk, Alex <[hidden email]> wrote:
DirectX switches the FPU to single precision by default [at least used
to]. So, even though Lua number is defined as double, all one has to
work with is 23 bits of precision.

Is it all the DirectX components that do this?  Or is it just limited
to the likes of Direct3D?

I am curious, has an OpenGL implementations be known to do anything similiar?

I have been using OpenGL since the mid nineties and haven't a problem
like this yet, but then I still mainly work under unices of various
flavours.  I do have quite a few users of my software  under Windows
and haven't heard reports of problems yet, but it sure be nice to know
if the OpenGL driver does it to so I can plan hacks around...

Cheers,
Robert.


Reply | Threaded
Open this post in threaded view
|

RE: D3DCREATE_FPU_PRESERVE

Bilyk, Alex
In reply to this post by Dominic Wong
D3D does and I'd not be surprised if Direct Sound benefited from this
either. You can just test for where FPU flags are inside some vanilla
running D3D app or/and Direct Sound app.

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Robert Osfield
Sent: Friday, May 26, 2006 1:16 AM
To: Lua list
Subject: Re: D3DCREATE_FPU_PRESERVE


On 5/25/06, Bilyk, Alex <[hidden email]> wrote:
> DirectX switches the FPU to single precision by default [at least used

> to]. So, even though Lua number is defined as double, all one has to 
> work with is 23 bits of precision.

Is it all the DirectX components that do this?  Or is it just limited to
the likes of Direct3D?

I am curious, has an OpenGL implementations be known to do anything
similiar?

I have been using OpenGL since the mid nineties and haven't a problem
like this yet, but then I still mainly work under unices of various
flavours.  I do have quite a few users of my software  under Windows and
haven't heard reports of problems yet, but it sure be nice to know if
the OpenGL driver does it to so I can plan hacks around...

Cheers,
Robert.


Reply | Threaded
Open this post in threaded view
|

RE: D3DCREATE_FPU_PRESERVE

Richard Ranft
> D3D does and I'd not be surprised if Direct Sound benefited from this
> either. You can just test for where FPU flags are inside some vanilla
> running D3D app or/and Direct Sound app.

It wouldn't surprise me if DirectSound twiddled FPU states, but if it does
then it covers its tracks without having to be told.  D3D is the only
component that I know of that interferes with Lua - or that Lua interferes
with, if you work for Microsoft....

Disclaimer:
I have been wrong before.  Just ask my wife.

Richard


Reply | Threaded
Open this post in threaded view
|

Re: D3DCREATE_FPU_PRESERVE

Wim Couwenberg-2
> D3D is the only
> component that I know of that interferes with Lua - or that Lua interferes
> with, if you work for Microsoft....

Unfortunately, there are more...  And the problem is not restricted to
the fpu precision mode either.  See

    http://lua-users.org/lists/lua-l/2006-03/msg00434.html

for some more info.

--
Wim



Reply | Threaded
Open this post in threaded view
|

RE: D3DCREATE_FPU_PRESERVE

Richard Ranft
> Unfortunately, there are more...  And the problem is not restricted to
> the fpu precision mode either.  See
>
>     http://lua-users.org/lists/lua-l/2006-03/msg00434.html
>
> for some more info.

Well, that basically says they had fpu issues related to a sound driver
update....

Perhaps some creative pushing and popping of FPU states around C calls is in
order.

Richard


Reply | Threaded
Open this post in threaded view
|

Re: D3DCREATE_FPU_PRESERVE

Glenn Maynard
In reply to this post by Roberto Ierusalimschy
On Thu, May 25, 2006 at 12:52:47PM -0300, Roberto Ierusalimschy wrote:
> 1) change lua_number2int in luaconf.h to this:
> 
>   #define lua_number2int(i,d)   __asm fld d   __asm fistp i
> 
> (Should have no performance penalty, but only works on selected compilers.)

A fast C99 solution is lrint/lrintf.

FWIW, I'd recommend trying C99, then VC inline, then a cast, and dropping
the problematic union hack.  (For every thread this starts, there are
probably half a dozen more people spending two hours figuring it out ...)

> 2) change lua_number2int in luaconf.h to its default definition:
> 
>   #define lua_number2int(i,d)     ((i)=(int)(d))
> 
> (Should always work, but may have a performance penalty in Lua; but
> how much??)

For anyone wanting a quick intro about some of the performance problems
with casting to int, see:

 http://mega-nerd.com/FPcast/

The quick summary is that on x86, the floating point mode has to be
changed from round to truncate for the cast, then back to rounding for
other math, and changing these modes hurts performance badly on some
(older) CPUs.

-- 
Glenn Maynard

Reply | Threaded
Open this post in threaded view
|

RE: D3DCREATE_FPU_PRESERVE

Bilyk, Alex
In reply to this post by Richard Ranft
Exactly the problems we've had at the time with Lua 4 and 5. Direct
Sound may practically be less of an issue because it tends to run in its
own thread and Lua tends to be used from the main thread. So, FPU state
changed by the DS is not visible to the main thread because of the
thread context switch. On other project I used Lua strings to store 32
bit integers in hex format a la "0xDEADBEEF" - a bit slower by the speed
was not an issue for me.

Alex

-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Wim Couwenberg
Sent: Saturday, May 27, 2006 3:35 AM
To: Lua list
Subject: Re: D3DCREATE_FPU_PRESERVE


> D3D is the only
> component that I know of that interferes with Lua - or that Lua 
> interferes with, if you work for Microsoft....

Unfortunately, there are more...  And the problem is not restricted to
the fpu precision mode either.  See

    http://lua-users.org/lists/lua-l/2006-03/msg00434.html

for some more info.

--
Wim




12