Should we require a CPU with SSE2 for Windows 32bit?

Some tests are failing on Octave built for Windows 32bit (see bug #58807).

Dmitri proposed to switch to using SSE/SSE2 instructions instead of 387 coprocessor instructions.
On the one hand, doing that seems to solve a lot of the precision issues.
On the other hand, doing that would mean that Octave no longer runs on CPUs without SSE2 instruction set.

To put that into perspective:
The last CPUs not supporting these instructions were e.g. AMD’s Athlon K7 or Intel’s Pentium 3. So most probably all CPUs that have been purchased in the last about 20 years should be supporting SSE2.

Also there is no current Windows version that still runs on CPUs without SSE2:

  • Windows XP and Vista are no longer supported by MS since at least 3 years. (Also afaik, Octave no longer runs on Windows XP for different reasons anyway.)
  • Windows 7 (also no longer supported, but still with reasonably large market share) with all available updates no longer starts on CPUs without SSE2 instructions (see e.g. the known issues for this update).
  • Windows 8 (and newer) require SSE2:

All 64bit processors (that Windows supports) provide these instructions and they are used by default in 64bit builds.

Given all of that, would it be ok to raise the minimum hardware requirements for Octave for 32bit Windows?

I followed your bug reports and was surprised that it hasn’t been an issue before, or did we just not bother? We have to adjust compiler switches for Octave (some / all dependencies)? How big is the impact of supporting SSE2 and does it affect the Linux, macOS builds somehow?

20 years after the introduction of SSE2 in the most commonly used CPUs, it should be save to require it.

I guess most users (and testers!) are on 64bit OSs and use the 64bit build where this is not an issue. Maybe there have been previous reports. But I don’t remember and couldn’t find any with a quick search.

Fortunately, it looks like we don’t need to change the build rules for Octave and all(?) of its dependencies. The cross-compilers are built by MXE Octave as part of the “normal” build process anyway. So, it is possible to change the defaults that gcc uses (see the patch in bug #58807). That applies to all packages that are built with that compiler without any further changes to the build rules.

I guess the effects are mainly of numerical nature (maybe also performance?). But small numerical differences at one point can lead to large errors later on. See e.g. the test where the axis limits are calculated to [0, 1.2] when they are [0, 1.4] on other platforms (admittedly not life-threatening in that particular case :wink: ).

That change would only affect the i686-w64-mingw32 target (Windows 32bit) in MXE Octave. Nothing would change for other platforms.

1 Like

After positive feedback during last online developer meeting, I pushed the necessary changes here: