Getting inconsistent, stuttery performance when building Mini vMac compared to official builds

[bribri]

I've been tinkering with Mini vMac and trying to compile my own versions for macOS. However the binaries I'm producing have very stuttery and inconsistent performance compared to the standard Macintosh Plus and Macintosh II builds available for download at www.gryphel.com. This occurs even when I pass the same options into Mini vMac's configuration tool as what the official builds report were used to build them.

Can anyone help me figure out what's causing this difference in performance? Perhaps there's something off about my build system? I've tried compiling using both Xcode 11 on macOS 10.14 and Xcode 14, and both give me the same issue. I'm not sure what else I can try.

Any help will be greatly appreciated!

[adespoton]

Are you building with the debug target or the release target? Debug is usually stuttery like you describe; I've had no performance issues with the release target, even with a fat binary. Might also want to check if you're in x86_64 mode if you're running on AARCH64.

[bribri]

Are you building with the debug target or the release target? Debug is usually stuttery like you describe; I've had no performance issues with the release target, even with a fat binary. Might also want to check if you're in x86_64 mode if you're running on AARCH64.

I'm building for x86_64 on x86_64, from the command line. I don't see any options for the configuration tool to select a debug or release build, outside of the logging level (which I have set to "ship"). So I don't think that's it, unless there's something I'm missing.

[adespoton]

Are you building with the debug target or the release target? Debug is usually stuttery like you describe; I've had no performance issues with the release target, even with a fat binary. Might also want to check if you're in x86_64 mode if you're running on AARCH64.

I'm building for x86_64 on x86_64, from the command line. I don't see any options for the configuration tool to select a debug or release build, outside of the logging level (which I have set to "ship"). So I don't think that's it, unless there's something I'm missing.

"ship" is the correct option from the command line, so it has to be something else. It might be worth running bindiff over the two binaries to see what's different....

[bribri]

"ship" is the correct option from the command line, so it has to be something else. It might be worth running bindiff over the two binaries to see what's different....

These are the options I'm passing to the configuration utility:

Code: Select all

-t mc64 -m II -vsync 0 -log 0 -dis 0 -d s

The two binaries are of significantly different size. The Macintosh II build available on the Mini vMac website has a binary that's 189,056 bytes, versus the one I'm building which is 240,232 bytes. The discrepancy in size seems like it'd be explained by me making a debug build, but I can see the gcc commands being called by the makefile and there's nothing in them to indicate that. I can see it's optimizing the code too. For example:

Code: Select all

gcc "src/GLOBGLUE.c" -o "bld/GLOBGLUE.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Icfg/ -Isrc/ -Os
gcc "src/M68KITAB.c" -o "bld/M68KITAB.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Icfg/ -Isrc/ -Os
gcc "src/VIAEMDEV.c" -o "bld/VIAEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Icfg/ -Isrc/ -Os
gcc "src/VIA2EMDV.c" -o "bld/VIA2EMDV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Icfg/ -Isrc/ -Os
gcc "src/IWMEMDEV.c" -o "bld/IWMEMDEV.o" -c -Wall -Wmissing-prototypes -Wno-uninitialized -Wundef -Wstrict-prototypes -Icfg/ -Isrc/ -Os

...and so on. If I change the optimization flag to -O3 I still get the same stuttering.

[bribri]

Nevermind, the size discrepancy is just symbol information. If I strip the binaries then they're much more similar in size. Still not sure where the speed issues are coming from, though.

[bribri]

I have some more information. I tried building the latest beta on an M1 Mac Mini as an arm64 executable, and am having the same issue there too: the official build from the website performs much better than whatever I build. I'm thinking there must be some kind of important setting for the configuration tool that I'm missing. I don't see why there would be such a big difference in performance between these builds otherwise.

edit:

Now this is just getting silly. I figured I'd try building the beta on the original system I was working with, my macOS 10.14 system, and the builds I make of the beta perform great! So that blows away the theory of missing a setting.

In summary:

Building latest stable on Intel macOS 10.14: bad performance
Building latest beta on Intel macOS 10.14: works great
Building latest stable on M1 macOS 12: bad performance (even given architecture mismatch -- official build still runs better)
Building latest beta on M1 macOS 12: works great (edit: originally said this had poor performance)

[adespoton]

I wonder if running them with the profiler would reveal what's causing the slowdowns? We could work backward from there.

[bribri]

I wonder if running them with the profiler would reveal what's causing the slowdowns? We could work backward from there.

I had the same thought. Unfortunately symbols are stripped out of the official builds, so the samples I get from them aren't particularly useful. (I don't know why those binaries are stripped too, given it's an open source project!) But for what it's worth here are the two samples I took of both the official and my build:

10 second sample of official build: https://pastebin.com/RHe10i0w
10 second sample of my build: https://pastebin.com/NTCy77tK

So far I don't see any obvious clues in these but I'll keep looking it over.

edit: It's a little bit of an apples to oranges comparison, but I figured I'd do a sample of the working build of the beta version: https://pastebin.com/EUVk5ry0

Based off of a cursory glance of this, my guess is that it has something to do with drawing to the window. Maybe there's some reason why building it as an Xcode project works better. I'll keep digging into it.

[kanjitalk755]

Mini vMac runs emulation and drawing in a single thread.
Because of that, if drawing is blocked for some reason, the emulation speed will drop.
So I tried to separate the drawing to another thread in the macOS/SDL2 version.

https://github.com/kanjitalk755/minivma ... macos_sdl2

[adespoton]

Mini vMac runs emulation and drawing in a single thread.
Because of that, if drawing is blocked for some reason, the emulation speed will drop.
So I tried to separate the drawing to another thread in the macOS/SDL2 version.

https://github.com/kanjitalk755/minivma ... macos_sdl2

What does that do to the timing of the drawing? I seem to recall Paul's original reasoning for single thread was a) portability and b) timing. It's odd that switching to multithreading should improve things, since Mini vMac can run pretty smoothly on a 68040 Mac with 256k VRAM (or at least it could 10 years ago, I haven't tested recent builds)....

[kanjitalk755]

Yes, it's really odd.
The stable binary downloaded from the official site does not experience slowdown.
I haven't been able to find build options to get same behavior as it (both stable and beta).
My implementation is one workaround, not ideal.

[bribri]

I've been using custom beta builds for my project for the last couple of weeks, and at least for my purposes I've found that they're stable and perform as well. And for me they don't have the stuttering issue. So I've stopped investigating why the stable builds have that issue, at least for the time being. I do suspect it has something to do with video rendering. Strange that the official builds don't have this problem.