Completely OT, but switching to a Firefox tab with TFA loaded takes noticeably longer than switching to other tabs (about 3 seconds vs less than a second).
86Box: Why Not Pentium III?
81–90 of 102 posts
Re: 86Box: Why Not Pentium III?
#82Earlier quoted context omitted.
Accurate timing is most useful when you are retro-programming a video game, or something else real time. How do you know if your game will run at 60 fps if the execution times aren't accurate? > what CPU timing would you even emulate Ideally your emulator would support as many CPU + hardware configurations as possible, at many different speeds, so you can test as many as you want. But just one single accurate hardwar…
> How do you know if your game will run at 60 fps if the execution times aren't accurate? Again, this is not a console. If you rely on a specific Pentium 3's instruction timings to reach 60 fps, your game is not going to reach 60fps _on any other PC_, not even if someone has an identical CPU, since any single other difference in hardware, configuration, or even layout of the filesystem is going to matter much more. Y…
If someone was to decide to develop a game for a minimum performance requirement of a Pentium III at 500mhz and some GPU, for some reason (which would be a completely arbitrary choice, but that's the hobby, so roll with it) then the only way they can possibly check that out meets that minimum requirement is to test on a machine with that configuration.
Either a real machine, or a accurate emulator.
It doesn't matter if there is other PC hardware configurations out there with different preformance. A minimum requirements just means "I tested on this machine, and it meets the minimums." Ideally you should underspec your minimum requirement test machine so that your target audience can be reasonably expected meet it.
You can't substitute in virtualization. That has zero chance in hell of providing a realistic estimate of performance, even if you paired it with an accurate gpu emulator.
Modern CPUs simply have very different performance characters, instructions that might have huge stalls on the P3 might be extremely cheap under virtualization. Caches are also widely different sizes.
If you use a proper, but inaccurate emulator, you get different issues. Even if it was tuned to provide a decent estimate of cpu performance over average code (and they are typically tuned to overestimate cpu preformance, because people playing games would rather framedrops from real hardware are not emulated), it's just an average that doesn't take into account things like cache misses and branch misspredicts.
If you were to write code with a lot of cache misses or branch misspredicts, your inaccurate emulator would massively overestimate it's preformance compared to a real cpu.
The various issues just add up and it becomes impossible to profile and optimise the game you are developing unless you have an accurate emulator. Other solutions will all point to different parts of the code being hot.
Also, remember this is within the era when you might be still developing a game with a software renderer, and if not you still have to do vertex transform and lighting on the cpu.
Personally I'm not that interested in accurate emulation of PC, the issues get a lot worse when it comes to developing games for 5th, 6th and maybe even 7th gen consoles. That's were my true interest in accurate OoO emulation lies. But I can see why someone might want accurate PC emulation too.
Re: 86Box: Why Not Pentium III?
#83It’s probably not even possible to emulate the Pentium Pro (or any other out-of-order x86 CPU) in a cycle-accurate fashion at the original speeds on contemporary hardware. Just attempting to match the original behavior for instruction scheduling, cache models, branch prediction, etc. would blow your CPU budget.
Why would u want to do cycle accurate emulation? Software ran on a wide variety of different software, I doubt there’s any software that relies on cycle accuracy for a Pentium pro level machine. And afaik, box86 is about running software, not modelling some specific machine exactly.
Re: 86Box: Why Not Pentium III?
#84Earlier quoted context omitted.
To add an example to your arguments, the C64 and PC/XT demo scenes show what can be done with cycle accurate retrocomputing. Especially 8088mph: https://youtu.be/yHXx3orN35Y
Do you know a lot of demo scene binaries that only work with accurate instruction timings of a Pentium 3 ?
What's your fixation here? You're wasting a lot of people's time.
Re: 86Box: Why Not Pentium III?
#85Earlier quoted context omitted.
I kind of miss add-in processor cards to allow a computer to run software from another architecture. Those devices were basically a whole computer on a card or add-on that would use the host computer for I/O with some level of integration. Stuff like the Apple IIe card for the Macintosh LC, or the MacCharlie sidecar for the original Macintosh that allowed it to run PC programs. I bet there are modern PCI cards out th…
Honestly that's pretty close to what a usb c dock is.
Well if we're going that far, why not just connect your phone to your PC and adb shell into it?
Re: 86Box: Why Not Pentium III?
#86Article claims it’s not possible to emulate a Pentium III at full speed on an Apple M1, and so there’s no point to a fork attempting this feat. But isn’t that exactly what Rosetta 2 does?
Rosetta 2 only needs to emulate a macOS specific subset of x86-64 user mode. This needs to emulate kernel mode, including paging and the guest OS hosting its own user mode.
Re: 86Box: Why Not Pentium III?
#87Earlier quoted context omitted.
Should does not equal must. Wanting a better world with less suffering and more joy is not the same thing as imposing this world by force. A thought that should have occured to you.
It is still not your place to say what people's ideals should be, or what efforts that they should persue.
You perfectly understood their point
Re: 86Box: Why Not Pentium III?
#88Arguably, cycle-accurate emulation should be done with FPGA support anyway. The Pentium III is old enough that there should be no legal obstacle to implementing new compatible hardware.
The problem won't be legal, but scale: the Pentium 3 has ~9.5M transistors [1] - and the world's largest FPGA, at a staggering price point of 55.000 dollars, has only 9M logic gates [2]. Probably you could use an FPGA a bit smaller if you use FPGA-native memory for L1-L3 instead of transistors, but you'll nevertheless need an FPGA that is many orders of magnitude too expensive for a hobbyist niche project. Also, you…
how are CPUs and modern GPUs actually developed
At least some of it is done on FPGA clusters, boards with multiple enormous FPGAs. Cost of such a system is in at least 6-7 digit range.
Re: 86Box: Why Not Pentium III?
#89Earlier quoted context omitted.
I'm of the belief that hardware is not truly preserved until you have a fully-accurate emulation of it. You are correctly that software doesn't require fully accurate timings. Just accurate enough to bypass any timing bugs and replicate the experience. Especially outside of the console space. If your only goal is running all known software, then you can get away with some massive accuracy bugs. But there is more to h…
>> I'm of the belief that hardware is not truly preserved until you have a fully-accurate emulation of it. BTW Intel has this internally
I don't doubt that, but at full clock speed?
Re: 86Box: Why Not Pentium III?
#90Earlier quoted context omitted.
> How do you know if your game will run at 60 fps if the execution times aren't accurate? Again, this is not a console. If you rely on a specific Pentium 3's instruction timings to reach 60 fps, your game is not going to reach 60fps _on any other PC_, not even if someone has an identical CPU, since any single other difference in hardware, configuration, or even layout of the filesystem is going to matter much more. Y…
If someone was to decide to develop a game for a minimum performance requirement of a Pentium III at 500mhz and some GPU, for some reason (which would be a completely arbitrary choice, but that's the hobby, so roll with it) then the only way they can possibly check that out meets that minimum requirement is to test on a machine with that configuration. Either a real machine, or a accurate emulator. It doesn't matter…
> If someone was to decide to develop a game for a minimum performance requirement of a Pentium III at 500mhz and some GPU, for some reason (which would be a completely arbitrary choice, but that's the hobby, so roll with it) then the only way they can possibly check that out meets that minimum requirement is to test on a machine with that configuration.
This just doesn't happen in modern PC development, save for heavyweights who can afford multiple identical hardware configurations (e.g. HPC clusters). I know I'm repeating myself, but the variety of configurations just makes this highly implausible. Sure, you can be some demoscene type of guy who decides to target specifically this configuration, but then you're literally targeting one processor out of hundreds, and per your own words, the fact that it works on the 500Mhz doesn't mean it will work with the same performance on the next generation or even on the 550Mhz variant. I guess this is obviously fine, but really stretching it. You'll quickly end up having something that only works on your machine, with the same starting disk image, etc.
Even PCem doesn't fully simulate the x86 cache because there is no benefit to it, and that includes cores from eras which were much more sensitive to timing. Branch mispredictions? Forget about it. Most P3 software is going to run concurrently to some other software, anyway.
I'm not saying that you don't need a cycle-accurate simulator to get real timings. I'm saying that with such a large divergence in configurations and environments, virtualization (or any other inaccurate emulator) is likely to provide a performance level that is quite accurately somewhere in the interval. Most specially since you will have actually calibrated it to that interval beforehand :)
Now on consoles I can see the benefit. Consoles are lots of identical hardware, operating systems that tend to get out of the way, and the people who develop for them only test (for obvious reasons) on the console hardware itself or at most a developer edition which has the same hardware (for obvious reasons again). You can have a silent bug that depends on timing of a mispredicted branch or the relative speed between the bus accesses of two cores and _never_ notice it since your testing environment is exactly 1 device (such a bug would immediate flare on a PC on like the 2nd reboot). Whatever it is that you develop for any one such console, it is highly likely it will work on all the million other sold consoles. Consoles are practically designed to have reproduce-able environments.
On the other hand you practically can emulate the entire x86 software catalog with emulators which _still_ have large differences in behavior at the actual instruction level compared to the hardware, so the instruction timing doesn't really seem important, and creating now some software that does depend on it seems .. complicated.
As an anecdote, not long ago I was working on a x86 emulator, and to my horror I realized that the push/pop instructions were actually miscomputing the operand size on a rather common but not primary situation (long mode but with a 32-bit segment). The emulator was pushing the stack by double the amount it should, and pushing/popping the high dword of registers it shouldn't have clobbered. This was actually happening in some of the most critical operating system code out there (bootloaders, WoW, etc.) ... and yet the bug had been in the emulator for years and no one had been the wiser, booting 64-bit OSes just fine :)