4 ms·

This is a great post, petitSeb is doing an outstanding job on Box86/64. I'm also keeping an eye on FEX which is evolving very rapidly. There has been 4 releases

by simjnd 4y ago

This is a great post, petitSeb is doing an outstanding job on Box86/64. I'm also keeping an eye on FEX which is evolving very rapidly. There has been 4 releases since the linked blog post which was written in late March, introducing very welcome features such as support for pressure-vessel or better OpenGL and Vulkan thunking.

olliej 4y ago
yeah, I liked how they explicitly distinguished the benchmark apps that made significant use of x87 as supporting x87 is necessarily an all software floating point implementation - it's impossible to get close to native performance for x87 heavy code on non-x86 architectures.
- lunixbochs 4y ago
  I don't know if I agree with "impossible". There's a lot of performance left on the table with SoftFloat. A non x86 architecture can add an 80-bit FPU if they want. There are architectures with 128-bit float, and CPUs with FPGA coprocessors. I suspect x87 is also not the most optimized path in modern x86 cpus (some instructions may even be fully emulated in microcode). Realistically, an x87-specific JIT could do significant instruction reordering, lift/reoptimize the underlying code (much of existing x87 code was compiled a very long time ago on older compilers), and vectorize the underlying integer float emulation, or even trace and move some computation to another core or a coprocessor like a GPU or DSP (often idle in embedded cpus). Many games work fine with x87 lowered to 64-bit or even 32-bit floats, and depending on the workload there's a middle ground where you could understand (or approximate) the current level of precision error for a value, generally run at a lower precision, and trace operations / "catch up" on precision at batched intervals.
  - olliej 4y ago
    Sorry, it is obviously possible to add hardware support for the 80bit ieee754 format (the format itself is not great, and in reality the precision isn’t necessary in all but the most extreme cases, and those where it is are likely to prefer 128bit float), but it isn’t something that is going to happen in the real world, and even if it was we’re talking about software for generally available systems.** You could also emulate it by arbitrarily dropping precision, but as a translator that means breaking bincompat, and more importantly breaking programs the use 80bit format (a lot of fortran). Obviously many games (especially old ones) perform fine as they’re only using 80bit because at the time x87 was the only hardware fp available on x86 hardware, not because they needed that perf. Even lowering the precision of the x87 unit isn’t sufficient as that only reduces the precision of the mantissa not the exponent. Even outside of the core arithmetic (excluding negation which is really easy in all ieee754 formats) there is a whole bunch of state that you need to keep track of to ensure identical behavior. Obviously if you are willing to break precision guarantees, etc then breaking state isn’t a problem, but if you’re trying to be something like Rosetta - eg completely general and running anything - you don’t really have the freedom to do that. ** sorry skim reading I missed your 128bit and x87 perf questions. Yes an emulator can (should?) use hw 128bit for the arithmetic if it’s available but on vast majority of hardware it isn’t. You are also right about x87 perf being slow compared to everything else, but it’s still faster than anything you can do in software (addition especially does not work interact nicely) due to the GRS tracking a software impl needs to do through many bitewise operations.
    - lunixbochs 4y ago
      My middle paragraph up-thread proposes that you can emulate it much faster than we're doing now, at full precision with integer SIMD and a specialized JIT. I'll reiterate the 80-bit softfloat stuff I've seen in use now is not really optimized. I suspect that beating the performance of a cpu on x87 from the era where x87 was relevant is somewhere between realistic and trivial. Beating a modern cpu on x87 from another architecture still feels possible (but it's a less useful thing to spend time on). > Even lowering the precision of the x87 unit isn’t sufficient as that only reduces the precision of the mantissa not the exponent. I don't know what you mean by "isn't sufficient". To be clear, I'm speaking from experience emulating x86 games on low resource arm devices, where I had success emulating x87 in lower precision. For QEMU, IMO the bigger performance issue is that it doesn't natively JIT _any_ FPU or vector instructions, and the indirect memory mapping hurts general performance quite a bit too.
      - olliej 4y ago
        Oh I have no idea when qemu wouldn't be doing those, but I wasn't very clear about precision. The x87 unit has control bits that you control (shocking!) behaviour of the unit, one of the things you can control is the precision it will operate at operate. People think that if the x87 unit is in the lower precision modes it's possible to simply use the common 32 or 64 bit FPUs, but the x87's 32/64 bit modes only impact the mantissa, not the the exponent so they reduced precision modes are still not interchangeable with fp32 or fp64.

by simjnd 4y ago

olliej 4y ago

yeah, I liked how they explicitly distinguished the benchmark apps that made significant use of x87 as supporting x87 is necessarily an all software floating point implementation - it's impossible to get close to native performance for x87 heavy code on non-x86 architectures.

lunixbochs 4y ago
I don't know if I agree with "impossible". There's a lot of performance left on the table with SoftFloat. A non x86 architecture can add an 80-bit FPU if they want. There are architectures with 128-bit float, and CPUs with FPGA coprocessors. I suspect x87 is also not the most optimized path in modern x86 cpus (some instructions may even be fully emulated in microcode). Realistically, an x87-specific JIT could do significant instruction reordering, lift/reoptimize the underlying code (much of existing x87 code was compiled a very long time ago on older compilers), and vectorize the underlying integer float emulation, or even trace and move some computation to another core or a coprocessor like a GPU or DSP (often idle in embedded cpus). Many games work fine with x87 lowered to 64-bit or even 32-bit floats, and depending on the workload there's a middle ground where you could understand (or approximate) the current level of precision error for a value, generally run at a lower precision, and trace operations / "catch up" on precision at batched intervals.
- olliej 4y ago
  Sorry, it is obviously possible to add hardware support for the 80bit ieee754 format (the format itself is not great, and in reality the precision isn’t necessary in all but the most extreme cases, and those where it is are likely to prefer 128bit float), but it isn’t something that is going to happen in the real world, and even if it was we’re talking about software for generally available systems.** You could also emulate it by arbitrarily dropping precision, but as a translator that means breaking bincompat, and more importantly breaking programs the use 80bit format (a lot of fortran). Obviously many games (especially old ones) perform fine as they’re only using 80bit because at the time x87 was the only hardware fp available on x86 hardware, not because they needed that perf. Even lowering the precision of the x87 unit isn’t sufficient as that only reduces the precision of the mantissa not the exponent. Even outside of the core arithmetic (excluding negation which is really easy in all ieee754 formats) there is a whole bunch of state that you need to keep track of to ensure identical behavior. Obviously if you are willing to break precision guarantees, etc then breaking state isn’t a problem, but if you’re trying to be something like Rosetta - eg completely general and running anything - you don’t really have the freedom to do that. ** sorry skim reading I missed your 128bit and x87 perf questions. Yes an emulator can (should?) use hw 128bit for the arithmetic if it’s available but on vast majority of hardware it isn’t. You are also right about x87 perf being slow compared to everything else, but it’s still faster than anything you can do in software (addition especially does not work interact nicely) due to the GRS tracking a software impl needs to do through many bitewise operations.
  - lunixbochs 4y ago
    My middle paragraph up-thread proposes that you can emulate it much faster than we're doing now, at full precision with integer SIMD and a specialized JIT. I'll reiterate the 80-bit softfloat stuff I've seen in use now is not really optimized. I suspect that beating the performance of a cpu on x87 from the era where x87 was relevant is somewhere between realistic and trivial. Beating a modern cpu on x87 from another architecture still feels possible (but it's a less useful thing to spend time on). > Even lowering the precision of the x87 unit isn’t sufficient as that only reduces the precision of the mantissa not the exponent. I don't know what you mean by "isn't sufficient". To be clear, I'm speaking from experience emulating x86 games on low resource arm devices, where I had success emulating x87 in lower precision. For QEMU, IMO the bigger performance issue is that it doesn't natively JIT _any_ FPU or vector instructions, and the indirect memory mapping hurts general performance quite a bit too.
    - olliej 4y ago
      Oh I have no idea when qemu wouldn't be doing those, but I wasn't very clear about precision. The x87 unit has control bits that you control (shocking!) behaviour of the unit, one of the things you can control is the precision it will operate at operate. People think that if the x87 unit is in the lower precision modes it's possible to simply use the common 32 or 64 bit FPUs, but the x87's 32/64 bit modes only impact the mantissa, not the the exponent so they reduced precision modes are still not interchangeable with fp32 or fp64.