0

My question is pretty straightforward and simple.

On a running program, could switching from one core to another on the same CPU, give rise to different results of the same set of values and instructions that encode the same float arithmetic operations?

I asked this because I had a program that was running with integer to double fixed calculations, and results changed after a few seconds of running and kept the new results for a few seconds as well. The change in results was extremely small, but I had no interpretation to it whatsoever.

EDIT:

  • This is the exact code.
  • Keep in mind that this is a window application using winapi.
  • It is a test project for HID input readings.
  • The data is being tested is BYTE winapi type, which is just an unsigned char.
  • It receives value periodically from a polling HID after registration with RawInputAPI of Windows.
  • It takes values from 0 to 255;
  • All that I am doing is converting it to a double within the range -1.0 to 1.0;

CODE:

BYTE& InputValue = DIH_Data.bRawData[2];
int ivalue = 0;
double value = 0.0;
ivalue = InputValue - 128;
value = ((double)ivalue) / 128.0;
OutputDebugString(std::to_wstring(value).c_str());
OutputDebugString(L"\n");

RESULT:

  • All readings are pretty consistent and are as expected;
  • I have these two results, however:
    • the first reading: 0.648430
    • the other reading: 0.648438
  • These seem to both arise from an input value of 83 out of 255. Why do they have different readings I have no idea.
curiousguy
  • 8,038
  • 2
  • 40
  • 58
Physician
  • 483
  • 2
  • 7
  • 3
    No, as long as the program is well-written (eg. without undefined behaviour) and you do not use an exotic CPU hardware. Note that the hardware is not completely protected from physical issues like [single event effects](https://en.wikipedia.org/wiki/Single-event_upset) or electronic issues. Such events are pretty rare though especially if your CPU is properly cooled and you use ECC memory (pretty critical on computing machines executing long-running programs). A software error is likely to be the problem, but it is impossible to say without a complete code analysis. – Jérôme Richard Mar 05 '23 at 12:58
  • 2
    I assume that the program is deterministic, that is, it does not use the current time to compute things like random seed or do not perform any system calls (eg. IOs) that could result in different results. By the way, frequent software bugs impacting results that way are typically buffer overflows or *race conditions*. – Jérôme Richard Mar 05 '23 at 13:02
  • What computation yields irreproducible results for you? Is it iterative? Is it something you can show here? – Solomon Slow Mar 05 '23 at 14:54
  • Ha, this is certainly a rounding issue. As long as you compile your code without fast-math nor special rounding options, then the possible rounding modes are the ones specified by the IEEE-754 standard and mainstream processors are compliant so it should be deterministic. Thus, I advise you to check your compilation flags.AFAIK, in C, the default rounding mode is to round to the nearest integer. The exact value is 0.6484375 so regarding the precise rounding mode details, it can be 0.648437 or 0.648438. 0.648430 is very unexpected though, even for 32-bit floats. – Jérôme Richard Mar 05 '23 at 18:45
  • 1
    It might also be a printing issue. I advise you to print the binary representation so to check that. Note that the rounding mode can be tweaked manually (see: https://stackoverflow.com/questions/6867693). AFAIK, it is tied to a process or a thread so the scheduling should not impact it (it would be actually dangerous otherwise), but an external library may change it. – Jérôme Richard Mar 05 '23 at 18:46
  • @JérômeRichard Thanks for your effort. Great contribution. – Physician Mar 05 '23 at 18:53
  • By the way, you can use a debugger (eg. msvc, gdb, lldb) to track which instruction cause different values. It is not impossible for a processor to have a bug (it would not be the first) but this is unusual. If so, I am curious of which instruction could cause such a difference, if any (it is quite frequent between two different platform but I never saw that on the same machine). – Jérôme Richard Mar 05 '23 at 18:55
  • @JérômeRichard It wasn't only on the same machine. It is on the same actively running instance of the program. The program was the foreground window and never toughed, and the value changed. That's why I found it strange. But, honestly, my primary work was actually just related to the same original 83 (out of 255) values. Thus I will rather continue working on the project without solving this problem because I have other larger problems to care about. Nonetheless, I really appreciate your help. Have a nice day. – Physician Mar 05 '23 at 19:24
  • @chux-ReinstateMonica How come? It is an 'int' type not a 'double'; Besides, InputValue can never give a value between 82 and 83; – Physician Mar 06 '23 at 06:25
  • 1
    @Physician You are correct. – chux - Reinstate Monica Mar 06 '23 at 06:30

0 Answers0