[Windows] Processor featuring BMI2 extensions required

[johnwait]

This is the same bug as mentioned raygray's comment on bug#29; I'm opening a new issue since this is not really related to issue #29.

This is for version 1.8.1 on Windows 7 x64. My processor is a mobile Ivy Bridge one (you'll see why it matters).

So starting FastoNoSQL.exe gets me an Invalid Instruction exception (c000001d) at 00000000-00856533. Loaded modules are irrelevant since the exception occurs within FastoNoSQL.exe's code segment.

Re-running it within WinDbg*, I get:

[..]
ModLoad: 000007fe`ff080000 000007fe`ff0ae000   C:\Windows\system32\IMM32.DLL
ModLoad: 000007fe`fe9f0000 000007fe`feaf9000   C:\Windows\system32\MSCTF.dll
(2dd14.2b8f4): Illegal instruction - code c000001d (first chance)
(2dd14.2b8f4): Illegal instruction - code c000001d (!!! second chance !!!)
*** WARNING: Unable to verify timestamp for FastoNoSQL.exe
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for FastoNoSQL.exe - 
FastoNoSQL+0x456533:
00000000`00856533 c4c261f7c7      shlx    eax,r15d,ebx

*I actually had to update my debugging tools for WinDbg to be able to disassemble that instruction

Looking that up, I find that SHLX is part of the BMI2 instructions introduced (for Intel) with the Haswell line (~june 2013), which means my T430 is just one generation short of running the code.

Anyway, if downgrading the compiler's target or implementing a shim for older CPUs is not possible/desirable, either a support statement on the download page mentioning the minimum CPU architecture required *or* a detection & warning routine within the application itself (e.g. Detecting BMI2 support at runtime) would be appreciated; at least people will know it's not your application that is at fault.

For my part, I can still run the application under Intel's Software Development Emulator, although having a native build supporting an older architecture would be best.

[topilski]

Hi @johnwait , thank you for investigation.

[topilski]

@johnwait can we find where this instruction used in code? or in runtime libraries? Is FastoRedis working on your machine? both solution we built on same server.

[johnwait]

Having a debug build/symbols (.pdb) file would probably tell which code that instruction corresponds to. But I suspect it's more the result of a compiler's optimization than a specific code line per-se (unless you use inline assembly with BMI2 instructions).

I just tried FastoRedis v1.8.1 (Windows x86_64 build), and it runs without a hitch.

I like I said, I was able to run FastoNoSQL v1.8.1 using Intel's SDE (which emulates instructions which my CPU doesn't support) to do what I needed it for; the only difference would be that if it were available natively for my (old) architecture generation, it may have run a bit faster than through the emulator.

Still, I knew I could use the emulator because my investigation told me it was a matter of instruction extensions not supported by my CPU; that may not be obvious to some people. So the main issue is the exception being caught by the OS instead of the program displaying an error, no so much that my CPU isn't supported.

[topilski]

Hi @johnwait , can you please build own build in FastoNoSQL site, in profile page, please select databases which you want to use, in advanced settings.

[topilski]

Only RocksDB used shlx instruction, i check it via objdump -d build/bin/FastoNoSQL | grep shlx command.

[topilski]

Hi all, thank you for helping in this issue, i have update our build server and now started from FastoNoSQL 1.8.2 application should work as expected, please check i'am waiting for yours feedbacks.

[topilski]

ping

[johnwait]

I just tested FastoNoSQL 1.8.2 and I can report that it runs without issue on my Ivy Bridge-era CPU-equipped machine. I had done some profiling on version 1.8.1 and SHLX was actually the only BMI2 instruction being used.

So it closes this issue.

However, it would be great in the medium-term to have a CPU support statement or policy, so we know if our CPU should be supported or not, even if no roadmap is yet decided upon for supporting new CPUs and dropping olds one.

For example, @unforgettableid's CPU didn't have support for AVX extensions ( available for Core-branded chip since & incl. Ivy Bridge, but not for Pentium & Celeron branded ones). And so my CPU supports AVX extensions, but not the AVX2 expansions, introduced a generation later with Haswell (~2013).

In any case, big thanks for your help and time on resolving this issue.

[topilski]

Hi @johnwait , thank you too, in mostly we are going to support all devices, if new issues appear we will fix them.