time.time() strangeness

Discussion in 'Python' started by Nitro, Feb 26, 2008.

  1. Nitro

    Nitro Guest

    > Nevertheless time.time() shouldn't fail here unless DirectX is really
    > badly tinkering with my system.


    I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
    the DirectX device the bug does not appear. This flag means "Direct3D
    defaults to single-precision round-to-nearest" (see [1]) mode.
    Unfortunately it is not an option to pass this flag, I need the
    performance boost it gives.

    Can somebody tell me how this interacts with python's time.time()? I
    suppose it's some kind of double vs. float thing or some fpu asm code
    issue...

    -Matthias

    References:
    [1] http://msdn2.microsoft.com/en-us/library/bb172527(VS.85).aspx
    Nitro, Feb 26, 2008
    #1
    1. Advertising

  2. Nitro

    Ross Ridge Guest

    Nitro <> wrote:
    >I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
    >the DirectX device the bug does not appear. This flag means "Direct3D
    >defaults to single-precision round-to-nearest" (see [1]) mode.
    >Unfortunately it is not an option to pass this flag, I need the
    >performance boost it gives.


    Using D3DCREATE_FPU_PRESERVE is extreamly unlikely to affect the
    performance of your code. Almost all 3D computation these days is done
    either on the video card or using SSE math on the CPU, neither which is
    affected by the use of this flag and the state of the FPU's precision
    setting. If you're mixing Python and Direct3D I would strongly recommend
    using D3DCREATE_FPU_PRESERVE. It will save you a lot of headaches
    because time.time() is probably not the only thing that will break.

    >Can somebody tell me how this interacts with python's time.time()? I
    >suppose it's some kind of double vs. float thing or some fpu asm code
    >issue...


    If you let Direct3D change the FPU settings, then the calculation made to
    compute the floating-point value returned by time.time() gets rounded to
    a 32-bit single-precision floating-point value. This means that number
    returned by time.time() only has 24 bits of precision, which for current
    time values, only gives you an accuracy of a hundred seconds or so.

    Ross Ridge

    --
    l/ // Ross Ridge -- The Great HTMU
    [oo][oo]
    -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
    db //
    Ross Ridge, Feb 26, 2008
    #2
    1. Advertising

  3. Nitro schreef:
    >> Nevertheless time.time() shouldn't fail here unless DirectX is really
    >> badly tinkering with my system.

    >
    > I can tell you more now. If I pass D3DCREATE_FPU_PRESERVE while creating
    > the DirectX device the bug does not appear. This flag means "Direct3D
    > defaults to single-precision round-to-nearest" (see [1]) mode.
    > Unfortunately it is not an option to pass this flag, I need the
    > performance boost it gives.
    >
    > Can somebody tell me how this interacts with python's time.time()? I
    > suppose it's some kind of double vs. float thing or some fpu asm code
    > issue...


    I got bitten by this some time ago in a project at work. At first time
    values in floats where wrong, but I didn't see why. Then I started
    seeing very strange results in other calculations, and it took me some
    time to find out it was because of DirectX.

    If you don't pass D3DCREATE_FPU_PRESERVE, DirectX puts the FPU in
    low-precision mode behind your back, which effects all floating point
    operations in your process, such as the calculation of time.time(). All
    in the name of performance, but in my opinion that should certainly not
    be the default.


    Cheers,
    Roel
    Roel Schroeven, Feb 27, 2008
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Munnki
    Replies:
    2
    Views:
    525
    Munnki
    Dec 18, 2003
  2. Nitro

    time.time() strangeness

    Nitro, Feb 26, 2008, in forum: Python
    Replies:
    1
    Views:
    235
    Paul Rubin
    Feb 26, 2008
  3. Nitro

    time.time() strangeness

    Nitro, Feb 26, 2008, in forum: Python
    Replies:
    0
    Views:
    270
    Nitro
    Feb 26, 2008
  4. Nitro

    time.time() strangeness

    Nitro, Feb 27, 2008, in forum: Python
    Replies:
    2
    Views:
    249
    Roel Schroeven
    Feb 27, 2008
  5. Chris Shea

    Time's dst? strangeness

    Chris Shea, Apr 11, 2007, in forum: Ruby
    Replies:
    1
    Views:
    95
    Rick DeNatale
    Apr 14, 2007
Loading...

Share This Page