Doubles change behavior in CreateThread process, why?
-
Hello, I'm having a problem with my double precision variables right now, and I'm hoping someone out there will be able to give me a hint as to what's going on. The details are going to be a little sketchy simply because of the size and complexity of the application. I have a function that tests to see if the double precision code is behaving properly. This function looks something like this.
void TestMath() { double kappa = -2.5316332141755993e-008; double cx; cx = (double)1.0 / (double)kappa; if (cx != -39500192.000000000){ BREAK("MATH IS WORKING"); } }When this function is called from the main body of my application, it never hits the break. However, if the function is called from a thread I have spawned using CreateThread(), the break does get hit. The value for cx should be -39500192.776766039, but it's being set to -39500192.000000000 And if I add the linedouble cx2 = 1.0 / -2.5316332141755993e-008;cx2 always equals -39500192.776766039 regardless of where I'm making the call. Using the IDE and checking the value for kappa indicates that it's value is correctly being stored. And again, if the function is called from a spawned thread, cx is evaluated to be -39500192.776766039 To create the thread, I'm simply callinghandle = CreateThread( NULL, 0,(LPTHREAD_START_ROUTINE)threadProcess, parameter, 0, NULL);And the function declaration for the thread looks like this.DWORD WINAPI threadProcess(void *param)Does anyone have any suggestions as to what could be causing this behavior? Thanks, Adam -
Hello, I'm having a problem with my double precision variables right now, and I'm hoping someone out there will be able to give me a hint as to what's going on. The details are going to be a little sketchy simply because of the size and complexity of the application. I have a function that tests to see if the double precision code is behaving properly. This function looks something like this.
void TestMath() { double kappa = -2.5316332141755993e-008; double cx; cx = (double)1.0 / (double)kappa; if (cx != -39500192.000000000){ BREAK("MATH IS WORKING"); } }When this function is called from the main body of my application, it never hits the break. However, if the function is called from a thread I have spawned using CreateThread(), the break does get hit. The value for cx should be -39500192.776766039, but it's being set to -39500192.000000000 And if I add the linedouble cx2 = 1.0 / -2.5316332141755993e-008;cx2 always equals -39500192.776766039 regardless of where I'm making the call. Using the IDE and checking the value for kappa indicates that it's value is correctly being stored. And again, if the function is called from a spawned thread, cx is evaluated to be -39500192.776766039 To create the thread, I'm simply callinghandle = CreateThread( NULL, 0,(LPTHREAD_START_ROUTINE)threadProcess, parameter, 0, NULL);And the function declaration for the thread looks like this.DWORD WINAPI threadProcess(void *param)Does anyone have any suggestions as to what could be causing this behavior? Thanks, AdamFound it! :D So, one of the details that I left out was that I am using DirectX for GPGPU math processing as well as for displaying 3d objects. It turns out that if you create a D3DDevice without the behavior flag D3DCREATE_FPU_PRESERVE, the following happens: Without this flag, Direct3D defaults to setting the FPU to single-precision round-to-nearest mode. Using this flag with the FPU in double-precision mode will reduce Direct3D performance. Don't you just love how moments after you post about a problem, your thinking changes just enough to allow you to find the culprit? Thanks for forum, Adam
-
Found it! :D So, one of the details that I left out was that I am using DirectX for GPGPU math processing as well as for displaying 3d objects. It turns out that if you create a D3DDevice without the behavior flag D3DCREATE_FPU_PRESERVE, the following happens: Without this flag, Direct3D defaults to setting the FPU to single-precision round-to-nearest mode. Using this flag with the FPU in double-precision mode will reduce Direct3D performance. Don't you just love how moments after you post about a problem, your thinking changes just enough to allow you to find the culprit? Thanks for forum, Adam