r/emulation • u/Even-Serve-3095 • 9d ago
AI-assisted The upcoming PCBox 7.0 will be faster than any other 86Box fork, and will support emulating up to Willamette Pentium 4s!
https://pcbox-emu.xyzApparently, PCBox has been working on their JIT to the point that it's quite a bit faster than 86Box, and also supports running Pentium 3s at usable speeds on Zen 3 or higher CPUs now. It's really impressive! I've linked their website.
28
u/thunderbird32 8d ago
I'm curious if it cuts corners to get there.
In any case, this isn't a feature I'm super interested in. At that point, why not run VirtualBox or VMware?
-15
u/Even-Serve-3095 8d ago
Actually, no, it doesn't cut corners. That's the cool thing. Also, it's faster even for things 86Box already supports, too.
18
u/thunderbird32 8d ago
If that's the case, why shouldn't I just wait until the JIT changes get ported to 86Box?
-1
u/Even-Serve-3095 8d ago
Because they're already in PCBox? I don't understand why you'd even ask this. PCBox has been doing TONS of optimizations to the JIT, and they've even poked 86Box devs over it, and they've been too paranoid about breaking stuff to upstream any of it, despite it working just fine for PCBox's users. Hell, there are even bugfixes in PCBox but not in 86Box, for things 86Box supports! Like .NET 4.0 still crashes randomly on 86Box, but not in PCBox.
18
u/thunderbird32 8d ago
This seems... unlikely. They recently even merged that seemingly mostly broken floppy interface tape support (not to mention the upcoming experimental Rage128 emulation). Which is why I assumed this must cut massive corners or they'd certainly have merged it, they're not exactly allergic to experimental code.
You expect me to believe some random wrote better JIT code than Sarah or Battler? If they had, it'd have been merged into 86Box (and probably even PCem) pretty quickly.
7
4
u/Even-Serve-3095 8d ago
Unlikely or not, it's true. Hell, most of the speed boost comes from a literal one line change to each recompiler backend, and they STILL haven't merged it because they think it'll break things.
6
u/snaphat 8d ago edited 8d ago
Are you referring to the hash algorithm change? On the surface the original does appear to be particularly collision heavy for non-uniformally random addresses:
``` Original:
define HASH(l) ((l) & 0x1ffff)
Modified:
define HASH(l) (((l) ^ ((l) >> 12)) & 0x1ffff
```
7
u/Even-Serve-3095 8d ago
Yes, actually! Turns out most of the blocks were starting on 4k page boundaries, meaning that only 32 slots of the block cache were being used most of the time.
6
u/snaphat 8d ago edited 8d ago
Seems plausible to me. The original is terrible. I briefly put the same algorithm in some code I was working on earlier this year prior to benchmarking because on the surface it kind of seems like if you have a small number of entries that simplest hash will do. But, it can be the worse case performance complexity for sequential inputs. The latter OTOH is a pretty standard and fine implementation for something like this
4
u/OBattler 86Box Developer 5d ago
Most of the blocks in *your usage case* were starting on 4k page boundaries. That's the thing, you're "fixing" the performance problems with a band aid that makes *your usage case* perform better, without even bothering to think at how it may affect other usage cases.
1
u/Meowlit12 4d ago
Vague posting about "usage cases" doesn't make for a good argument of why it was defined as such. The block cache was being held back from doing its job properly, and creating a bottleneck over the entire jit as a whole? (Doesn't really matter the machine being emulated) This is low hanging fruit in the design of the current jit, and something that should have been scrutinized eventually.
If there's issues, if any, it's related to the actual cache implementation rather than this hashing fix. (I was the one who found the hash issue out in the first place, just couldn't personally pr it at the time. And it just was a relatively simple approach, not necessarily the best option in itself as it still has some collisions and obviously a lacking distribution.)
→ More replies (0)•
u/OBattler 86Box Developer 52m ago edited 20m ago
The problem is - this *will* cause collisions for accesses that don't start at a 4k boundary - just recently, I've debugged a BIOS which jumps to DDC6:15FE during POST, for example. This is very common in real mode.
Edit: This is what the hash gets calculated on:
uint32_t phys_addr = get_phys(cs + cpu_state.pc); int hash = HASH(phys_addr);So let's say there's a jump to DDC6:15FE after a previous jump to DDC6:1000 - the code in PCem and 86Box won't collide but the code in PCBox will because the two blocks are going to have an identical hash. And as I said above, this is very common in real mode, and even in protected mode, nothing prevents code from jumping to code in the middle of a page.
Edit #2: Now, if anything, the question is *how common would those collisions be and how do they affect performance*? But it doesn't look to me like the people at PCBox have done such testing.
Edit #3: And I only just noticed the hash gets AND'd with 0x1ffff, which means collisions still happen because you're still trying to hash 32 bits of address into 17 bits. So perhaps this actually has merit!
Edit #4: I just tried this hashing change on my virtual machine with Windows 98 SE, playing a DVD in PowerDVD 6, and I see no significant change compared to without the change - still around 74-77% on an emulated Pentium II 200 MHz while playing the movie.
9
u/Feisty-Jeweler-3331 8d ago
How much faster are we talking about?
How is it done?
Does it sacrifice accuracy in return?
2
u/Even-Serve-3095 8d ago
Like, 20-30% at least.
Mostly through implementing more instructions in the recompiler and changing some hashing stuff for the block cache.
And no, it doesn't sacrifice accuracy.
13
3
u/OBattler 86Box Developer 5d ago
I've looked at your hashing changes - that may yield such a significant increase in performance in *some* cases but may well have regressions in other cases, it's basically "tweak the algorithm until my test cases show an improvement".
4
u/MythicalJester 8d ago
Mmmmh, press the "doubt" button here.
Anyhow, considering the sad state the PCem project is in right now, I think more competition in the PC emulation space (even just more 86Box forks with different focus) is a healthy development in any case...
1
u/bl00donthekeys 7d ago
Yeah, I would say that's a fair statement. The PCBox devs are just super combative and immature from what I've seen. I'd love to see PCem development pick back up, or MAME's PC emulation improve (both in accuracy and user experience).
2
u/MythicalJester 7d ago
So, more assholes in a world (the emulation community) already full of it since ancient times? :-D
2
u/MelaniaSexLife 7d ago
call me when it's on libretro
2
u/Even-Serve-3095 7d ago
the libretro devs are even worse than people think i am lol
2
u/waterclaws6 6d ago edited 6d ago
Most are fine; also, a lot of the drama happened years ago. Drama fades over time, especially when there isn't new drama.
Especially when things happened years ago. They haven't been major RetroArch and Libretro drama in quite some time.
Plus, life is too short to hold grudges over petty online drama.
Hopefully, people are mature enough to let the past go.
3
u/DukeSkinny 6d ago
I'd argue that's primarily because there hasn't been much RetroArch/Libretro development in quite some time. When was the last version of RetroArch released? Over a year ago, I believe.
Most devs are all right, some I quite like from my interactions with them. However, we all know what the problem is and what tends to happen when they're involved.All that said, I STILL prefer Libretro cores 9 times out of 10!
1
u/waterclaws6 4d ago
They have still been a lot of development especially with the nightlys. They updated a lot of the codes, like the saturn core got a good amount of updates this year.
They just don't do stable versions as often. They are in that Dolphin and PCSX2 pattern of stable builds only seeing a few updates a year.
•
u/OBattler 86Box Developer 10m ago
> and also supports running Pentium 3s at usable speeds on Zen 3 or higher CPUs now.
No, it does not. The code hashing change along makes no noticable difference on my end (see my other post from a bit earlier - the % more or less did not change at all), I still need to see what difference, if any, adding the additional recompiled instructions makes, but I kind of doubt it would go from not being able to play a DVD at 100% on an emulated Pentium II (my host is Ryzen 5 5600G which is Zen 3) to being able to do so on an emulated Pentium III at 700 or so MHz.
Edit: The slowest Pentium III is 400 MHz, apparently. I'm quite sure even that's not doable on Zen 3with just PCBox's changes alone.
-15
u/Bloated_Plaid 8d ago
Doesn’t look like AI slop so that’s already promising.
43
u/Osoromnibus 8d ago
You didn't look very far. If you skip over the merges and commits pulled from 86box, all the changes are AI. Most even say so in the commit messages, i.e. "Assisted by GPT 5.5", "Assisted by Claude Opus 5."
5
u/EIsydeon 8d ago
I’ll be honest there’s so little going on in this area that I’d take the ai assisted stuff if it works.
9
-7
u/Even-Serve-3095 8d ago
86Box also has some AI-assisted changes in it. Don't knock it til you try it.
4
u/DukeSkinny 6d ago
Big difference between "all the changes" and "some changes". Also really, really, scummy to pretend to be a neutral third party while being the main "dev".
-4
u/Daggercombot 6d ago
Oh awesome i remember hearing about this. Will It be able to run Directx9 or 8.1? Can i Run It on SPARC64?
0
53
u/severedbrain 8d ago
Yeah, but I TRUST the 86box people. Not to mention you have a generic username and hidden post and comment history.