ptitSeb
(Documentation request) Add a FAQ on the website
I would like propose a question that explain the difference between Box86/Box64 and FEX-Emu.
I'm probably missing a few things but here are the main comparison points:
| FEATURE | Box64 | FEX | QEMU |
|---|---|---|---|
| x86_64 architecture support | Slow | No | Slow |
| Arm architecture support | Fast | Fast | Slow |
| LoongArch architecture support | Fast | No | Slow |
| PowerPC architecture support | Slow | No | Slow |
| RISC-V architecture support | Fast | No | Slow |
| Dynamically-linked programs | Yes | Yes | Yes |
| Statically-linked programs | No | Yes | Yes |
| Library handling | Wrapped | Translated | Emulated |
| 4KB to 16KB pagesize support | Partial | No | No |
| 32-bit on 64-bit | Yes | Yes | Yes |
@ptitSeb anything else you want to add to or adjust in that comparison?
I would add the library wrapping too. With 200+ lib supported on box64, and limited support on FEX (I think OpenGL and Vulkan are "thunked" there, not sure if some other libs are)
Updated, thanks! I can get a PR up later to at least add this to the README.md file.
Not sure it's worth separating "thunked" from "wrapped", as it serve the exact same purpose.
That's a good idea but I personally do not know the details of how QEMU works. All I know is that it's slow. For example, my high-end x86_64 gaming computer using QEMU is slower than my Raspberry Pi when it comes to running Arm programs.
Okay, I did some research and fact checking to come up with a QEMU column. Seb can let us know if it looks accurate.
I also changed the "Library handling" for FEX to say "Translated" instead of "Thunked". I feel like that makes more sense as it covers more than the 32-bit on 64-bit approach.
Okay, I did some research and fact checking to come up with a QEMU column. Seb can let us know if it looks accurate.
Thanks! It looks good to me.
I don't think there should be "Slow" and "Fast" in the architecture layout. That's too subjective. I would prefer "Interpreter" and "JIT" kind of items instead, to avoid direct speed comparison that would require a new benchmark campaign to back up.
Okay, I did some research and fact checking to come up with a QEMU column. Seb can let us know if it looks accurate.
I also changed the "Library handling" for FEX to say "Translated" instead of "Thunked". I feel like that makes more sense as it covers more than the 32-bit on 64-bit approach.
I think it would be better to have a number here, of "native libs" directly used by emulated program (maybe separate 32bits and 64bits too). That would make things more clear that box64 doesn't need a chroot / fsroot / whatver x86_64 linux system is needed to run. Or add a line for that? because that's one of the keep point.
I thought about using JIT instead of fast. The reason I didn't was because most folks won't understand what the end result means. I understand, it's an oversimplification and not necessarily accurate in all cases.
Yeah, It's impressive that Box wraps over 200+ libraries. We should be showing that off! The library implementation we want to do temporarily(?) for Box32 is somewhat of a RootFS. Just very minimal. It's not required so I'll note that, too.
Okay, here's an updated table:
| FEATURE | Box64 | FEX | QEMU |
|---|---|---|---|
| x86_64 architecture support | Interpreter | No | Interpreter |
| Arm architecture support | JIT | JIT | Interpreter |
| LoongArch architecture support | JIT | No | Interpreter |
| PowerPC architecture support | Interpreter | No | Interpreter |
| RISC-V architecture support | JIT | No | Interpreter |
| Dynamically-linked programs | Yes | Yes | Yes |
| Statically-linked programs | No | Yes | Yes |
| Library handling | Wrapped | Translated | Emulated |
| Native x86_64 libraries wrapped | 250+ | 10+ | No |
| Native x86_32 libraries wrapped | 90+ (Box86), 40+ (Box32) | No | No |
| x86 RootFS required | No | Yes | Yes |
| 4KB to 16KB pagesize support | Partial | No | No |
| 32-bit on 64-bit | Yes | Yes | Yes |
I found the list of thunked libraries in FEX here. Looks to be 17 right now. The implementation sounds similar to the concept of wrappers in Box.
I got all of the numbers for wrapped Box libraries by looking at the number of src/wrapper[32]/*.h files.
QEM use JIT. There is no interpreter in QEMU. Only Box has one to my knowledge. QEMU use an IR and "TCG" to generate it's code iirc. It approach "many to many", with a focus on accuracy, is the reason it's slower then FEX or Box. But if you take a pure CPU (without x87 code), it's not that slow. The lack of OpenGL/Vulkan support is the main thing that makes it unsuitable for gaming (and that's why FEX implemented thunking, that is a wrapper inside a physical library I think).
About the wrapped libs, I'll add some command line option to box64 to get the list of wrapped libraries... sooninsh... that will help end user understand and find if a lib is wrapped or not)
One last note: when you run steam stuffs, because steam has it's own rootfs basically, box64/box32 will use this one anwyay for any missing libs...
Good points!
Now that it's interpreter vs JIT, it's not a simple matter of a (subjective) slow vs fast. I didn't know that QEMU used a JIT. I'll update that.
I looked to see if QEMU supported other pagesizes. I would have thought it did but the evidence I found pointed to "no". However, I just looked again and found this thread which confirms it supports other pagesizes: https://lore.kernel.org/linux-arm-kernel/[email protected]/T/
I'll also add a note about GPU acceleration. I know that QEMU was just updated to now have Vulkan pass-through using Venus, the same back-end that ChromeOS uses with crosvm. But I think that only works on the same architecture.
Here's the latest table:
| FEATURE | Box64 | FEX | QEMU |
|---|---|---|---|
| x86_64 architecture support | Interpreter | No | JIT |
| Arm architecture support | JIT | JIT | JIT |
| LoongArch architecture support | JIT | No | JIT |
| PowerPC architecture support | Interpreter | No | JIT |
| RISC-V architecture support | JIT | No | JIT |
| Dynamically-linked programs | Yes | Yes | Yes |
| Statically-linked programs | No | Yes | Yes |
| Library handling | Wrapped | Translated | Emulated |
| Native x86_64 libraries wrapped | 250+ | 10+ | No |
| Native x86_32 libraries wrapped | 90+ (Box86), 40+ (Box32) | No | No |
| x86 RootFS required | No | Yes | Yes |
| 4KB to 16KB pagesize support | Partial | No | Yes |
| 32-bit on 64-bit | Yes | Yes | Yes |
| OpenGL and Vulkan support | Yes | Yes | No |
Last remark: I would say "Native OpenGLand Vulkan support" (because QEMU support anything, but emulated only)
Alright, possibly the last table update. :-)
| FEATURE | Box64 | FEX | QEMU |
|---|---|---|---|
| x86_64 architecture support | Interpreter | No | JIT |
| Arm architecture support | JIT | JIT | JIT |
| LoongArch architecture support | JIT | No | JIT |
| PowerPC architecture support | Interpreter | No | JIT |
| RISC-V architecture support | JIT | No | JIT |
| Dynamically-linked programs | Yes | Yes | Yes |
| Statically-linked programs | No | Yes | Yes |
| Library handling | Wrapped | Translated | Emulated |
| Native x86_64 libraries wrapped | 250+ | 10+ | No |
| Native x86_32 libraries wrapped | 90+ (Box86), 40+ (Box32) | No | No |
| x86 RootFS required | No | Yes | Yes |
| 4KB to 16KB pagesize support | Partial | No | Yes |
| 32-bit on 64-bit | Yes | Yes | Yes |
| Native OpenGL and Vulkan support | Yes | Yes | No |
The table content looks fine, but I personally don’t find it’s necessary to put it in README, more suitable to put it into the website FAQ.
Looks fine to me, except for a few nitpicks:
- Maybe add "(slow)" in the QEMU arch supports, as even though it's JITed the resulting code is much slower (if it is just because the libraries are emulated, then ignore this, but AFAIK it's not);
- I know what "wrapped", "translated" and "emulated" mean, but a more general public (which is the target of this table) wouldn't: what's better? I would instead put "native if possible"x2 and "emulated", or "hybrid"x2 and "emulated", or even get rid of this line altogether (since it's implied by the next line);
- Instead of "native ... libraries wrapped", I think "used" would be better (and replace "no" with "none"/"0") (and technically in the FEX codesource libraries are not wrapped, they are thunked, so "use" is a more general term);
x86_32doesn't exist, it's justx86;- Maybe add a line for supporting self-emulation, i.e. running a program using the x86 version of the emulator using the native version of the emulator? According to the QEMU documentation, it supports this. If you want to add it, you'd need to check whether
box86/box64/box32supports this. This is very niche, but does show off the emulation capabilities of the emulator (though obviously FEX doesn't support this because there is no x86 version of it, so it wouldn't be a fair comparison).
Also, if it's put in the website FAQ, I'd like it to have background colors so the good and bad are more easily viewable at a glance: green for yes/best, red for no/worst, yellow for in-between (similar to e.g. the sorting algorithm table on Wikipedia). (Sadly, this cannot be achieved on GitHub AFAIK, despite quite a lot of requests to GitHub to add color support).
Updated!
- x86_32 is a common term online even if it's unofficial slang. Many operating systems use it in their documentation, too. It helps to distinguish between 64-bit and 32-bit. Either way, I renamed it to x86.
- I switched to the term "hybrid" for library handling since it's shorter and hopefully easier for users to read/understand.
- I didn't add any mention of self-emulation. I'm no Box expert so I'm not sure and it's a niche feature.
- I added Android support.
- Is the website open source? I don't think I have access to edit it.
| FEATURE | Box64 | FEX | QEMU |
|---|---|---|---|
| x86_64 architecture support | Interpreter | No | JIT (slow) |
| Arm architecture support | JIT | JIT | JIT (slow) |
| LoongArch architecture support | JIT | No | JIT (slow) |
| PowerPC architecture support | Interpreter | No | JIT (slow) |
| RISC-V architecture support | JIT | No | JIT (slow) |
| Android support | Yes | No | Yes |
| Dynamically-linked programs | Yes | Yes | Yes |
| Statically-linked programs | No | Yes | Yes |
| Library handling | Hybrid | Hybrid | Emulated |
| Native x86_64 libraries used | 250+ | 10+ | 0 |
| Native x86 libraries used | 190+ (Box86), 40+ (Box32) | 0 | 0 |
| x86 RootFS required | No | Yes | Yes |
| 4KB to 16KB pagesize support | Partial | No | Yes |
| 32-bit on 64-bit | Yes | Yes | Yes |
| Native OpenGL and Vulkan support | Yes | Yes | No |
I can give you an account to contribute on box86.org, that's not a problem.
I think a FAQ (with more qeustion than just comparing box with other solutions) would be more appropriate on box86.org than on the README of box64.
That sounds good, thanks! I'll go ahead and close the README.md PR I opened.
Emulated instruction sets - differences: Box64: VMX FEX: 3DNow! QEMU: 3DNow!, SSE4a, TBM
Emulated instruction sets - differences: Box64: VMX FEX: 3DNow! QEMU: 3DNow!, SSE4a
Box64 emulate an Intel only CPU (so 3Dnow! or SSE4a doesn't make sense). QEMU can be Intel of AMD. Not sure about FEX, maybe only AMD?
To me it seems that either FEX added 3DNow! support (with corresponding CPUID bits) without explicitly specifying is the CPU Intel or AMD (e.g. emulating a non-existing hybrid GenuineIntel with 3DNow) - or they support both in some way (their CPUID has if/then for AMD/Intel, but so has box64 and you say you don't emulate AMD at all, so probably I'm misunderstanding it).
To me it seems that either FEX added 3DNow! support (with corresponding CPUID bits) without explicitly specifying is the CPU Intel or AMD (e.g. emulating a non-existing hybrid GenuineIntel with 3DNow) - or they support both in some way (their CPUID has if/then for AMD/Intel, but so has box64 and you say you don't emulate AMD at all, so probably I'm misunderstanding it).
when you emulate the CPUID opcode, you need to define if you follow AMD or Intel standard. And there is no way to indicate 3DNow there if you follow Intel standard. You can enable it only with AMD standard.