Box86 vs native: OpenGL is almost native, CPU bound 50%, SSE3 is slower | Hacker News Reader

Box86 vs native: OpenGL is almost native, CPU bound 50%, SSE3 is slower

stands.fosdem.org

139 pointsmarcodiego38 comments

Really hope Box86 or wine hangover allow windows x86 binaries to run well on arm sbc on a not too distant future.

Someone's already gotten wine working on the pinephone: https://www.reddit.com/r/PinePhoneOfficial/comments/m4bvti/w...

Me to! Maybe it is not in the scope of these projects. Apple however managed to do this for their latest architecture and also I think it was done quite a lot for the Pandora game console. So that would be by translating the binary files themselves to a new architecture before executing them.

In the case that someone targets one application run in wine this is not to much work I believe. If someone would be interested into doing this, I would be very happy to help!

https://www.giantpockets.com/starcraft-pandora-port-came/

> windows x86 binaries

That may only work for 32 bits binary applications since Box86 does not support 64 bits. You can already see Box86 + Wine running older Windows games here: https://www.youtube.com/watch?v=yoIptyr6zV4

Well box86 actually supported running wine since a while ago, which means you can install x86 wine and use it.

Yes, that is precisely why you can play x86 Linux games through Box86 on ARM.

Well, no -- you can also run the Linux version of Steam and games with a native Linux version with no need to use wine. The performance should be better than using wine, too.

Steam does not exist in repos on ARM based distributions. So no, you can't just also run the Linux version of Steam and games without a need to use Wine... When it comes to using Box86 on ARM.

Huh? You totally can -- it's even mentioned down in the README in the github repo: https://github.com/ptitSeb/box86#notes-about-steam

You can download a straight tar.gz file from Steam [0], extract it, and run the contained steam executable with box86, and as long as you have the ARM versions of some native libraries installed as mentioned in the project readme, x86 Linux steam will run fine, no wine required.

Fun fact, box86 also works on PowerPC, I got it running at the start of the year. Not sure how much has bitrotted, but if you've got a POWER8/9/10 machine, it can run box86 ;)

(without JIT, so dramatically slower than in the article, but better than qemu usermode!)

[0] http://repo.steampowered.com/steam/pool/steam/s/steam/

How does Box86 implement x86's strong memory model? It is, for example, well-known that for emulating x86 code on Apple M1, there exists a special mode on this specific CPU that enables a strong(er) memory model.

Maybe it doesn't. If it only supports running on a single core at a time, it doesn't need to.

How would Box86 compare with QEMU user-level emulation?

The nice thing about Box86 is that it intercepts calls to things like the libc, SDL, font rendering and OpenGL, and runs the native library versions.

In that regard, it's actually more like WINE than something like QEMU system mode. QEMU only emulates kernel system call interfaces and any library code is also emulated, and so is much slower.

No sure, but I think QEMU-user only translates syscalls. Box86 (also) translates library calls. That way more code (libraries) can be run natively and, because of it, much faster.

Yes, QEMU user-mode only emulates syscalls, so all the guest program's libraries are guest-architecture code, translated and run via the JIT.

Ah, it works the way I wrongly assumed qemu-usermode does.

Will there ever be a Box64 ?

Yes, already in early stages of development. https://www.youtube.com/watch?v=Ec3vIdpoPIM

> On a CPU intensive app [...] the emulated software is roughly 50% of the native speed. While this number can still be improved [...] this probably won’t change much in the future (it will probably top at maybe 60%)

This is a shame if true. What's the difference between this and something like rosetta 2 that allows the latter to achieve greater performance?

Unless I am mistaken M1 chips have hardware dedicated to making translations faster.

To be specific, the M1 supports a stronger memory model which makes emulation easier. There is no real dedicated hardware though.

But the original benchmarks weren't multithreaded, which should make that a nonissue?

(Is it possible to generate code assuming a weaker memory model, and then invalidate that upon creation of a thread? Might get dicey with shared memory, though...)

The hardware itself has dedicated instructions

Possibly M1 hardware optimisation for x86 emulation?

I'll watch this with great interest.

Looks like possibly a way to get Skype working on a rPI.

Zoom is already working via Box86: https://www.youtube.com/watch?v=9yx3XzYnHV4

A small list of command lines would be so much faster, easier and simpler than a youtube video...

But you can monetize a youtube video so much better >_>

If it they can run Warhammer: Dark Omen with 3d acceleration, then that would be pretty impressive. Pretty famous for being a pain in the butt when it comes to running it on modern or emulated hardware.

Funny coincidence, I was just playing it last month! It was a bit annoying to get everything running but after consulting the guide over at http://forum.dark-omen.org/help-section/read-me-ultimate-dar... I was able to get a really great HD experience. But I agree with you, it took me probably 30-40 minutes of fiddling!

Does box86 have a jit?

Yes, it’s DynaRec (dynamic recompilation) which is a form of JIT. (I suppose you could call it an optimizing JIT of sorts) - with a fallback to a more “normal” JIT for x86 code which is emitting other x86 code (like Unity games).

How do they detect when the fallback should be used?

It's right in the README - "Box86's Dynarec uses a mechanism with Memory Protection and a SegFault signal handler to handle JIT code." Essentially, code areas are write protected and when they trigger a write fault, the area is marked as "dirty" to be recompiled.

https://github.com/ptitSeb/box86/commit/2aa2e53fef61d00df535...

first "protect memory, fault handler purges that code block as 'invalid' approach"

and

https://github.com/ptitSeb/box86/commit/4778760622df90c97da2...

second, "mark block as dirty rather than purging it" approach

I dabbled a bit in x86 on ARM emulation quite a while back, but didn`t make it beyond a couple of concepts. It´s crazy how much the box86 people accomplished in a relatively short amount of time.

Well explained! Thank you so much for this!

Dynarec

Yes

Reply on news.ycombinator.com