5 ms·

Interesting bug, but I don’t like the fix. Most computers are 64 bits for decades now. It takes same resources to add/subtract/compare int64 compared to int32.

Interesting bug, but I don’t like the fix. Most computers are 64 bits for decades now. It takes same resources to add/subtract/compare int64 compared to int32. No reason to use 32-bit integers for time, when I write C++ I use GetTickCount64() API introduced in Vista. The C# equivalent is Environment.TickCount64, but there’s no need because unlike many other languages, C# standard library comes with a good support for dates, times, and time intervals. Instead of integers for elapsedInterval and requiredInterval variables, I prefer TimeSpan type. Safer, more readable, and potentially higher resolution because TimeSpan keeps int64 number of 100 nanoseconds ticks.

samplatt 3y ago
>Most computers are 64 bits for decades now. Desktops and laptops and servers, sure. There's an awful lot of 32bit processors in industrial controllers.
- adrian_b 3y ago
  True, but even in any 32-bit microcontroller program any hardware tick counts and any high-resolution timestamps or other high-resolution time quantities should be handled using 64-bit integer types, e.g. "int64_t" or "long long". All modern compilers support such types, so the choice does not require any work for the programmer. Even on 32-bit MCUs, the extra overhead for using 64-bit time quantities is almost always negligible, because normally only additions and subtractions are done with these values. Multiplications and divisions, which are slow on 32-bit MCUs, are used very seldom for time values. The failure to use such types is a serious programmer mistake, which does not have any excuse, already for at least three decades or more. In microcontrollers it is even easier to always use the right types for time values, because normally there are no backward compatibility concerns. Many microcontrollers have only small hardware tick counters, e.g. 16-bit counters, but it is easy to extend them in software to 64-bit by having an interrupt on overflow that increments the high words of the 64-bit software tick counter (when reading such split software-hardware tick counters, modifications in progress must be detected and the read must be retried, like for any other lockless data that are shared between concurrent threads).

samplatt 3y ago

>Most computers are 64 bits for decades now. Desktops and laptops and servers, sure. There's an awful lot of 32bit processors in industrial controllers.

adrian_b 3y ago
True, but even in any 32-bit microcontroller program any hardware tick counts and any high-resolution timestamps or other high-resolution time quantities should be handled using 64-bit integer types, e.g. "int64_t" or "long long". All modern compilers support such types, so the choice does not require any work for the programmer. Even on 32-bit MCUs, the extra overhead for using 64-bit time quantities is almost always negligible, because normally only additions and subtractions are done with these values. Multiplications and divisions, which are slow on 32-bit MCUs, are used very seldom for time values. The failure to use such types is a serious programmer mistake, which does not have any excuse, already for at least three decades or more. In microcontrollers it is even easier to always use the right types for time values, because normally there are no backward compatibility concerns. Many microcontrollers have only small hardware tick counters, e.g. 16-bit counters, but it is easy to extend them in software to 64-bit by having an interrupt on overflow that increments the high words of the 64-bit software tick counter (when reading such split software-hardware tick counters, modifications in progress must be detected and the read must be retried, like for any other lockless data that are shared between concurrent threads).