Ghostbusters High CPU Usage

[EldarOfSuburbia]

tl;dr This is my own personal theory why Ghostbusters consumes a ton of CPU, and a possible, simple, solution. It's pure speculation and if it turns out to be wrong, so be it; this thread will go to the graveyard with "IT WAS WRONG" on the tombstone.

We've had Ghostbusters for a week, and while most who can play the table on their platform of choice will agree that it's a great table, a lot of other folks are having difficulties getting it running at all, and even when they do, it runs like a dog - and I'm not talking a racing greyhound here; more like a well-fed St Bernard that's just got up from a nap.

Why might this be? Well, one thing that has been noted is that the table itself consumes a lot of CPU resources.

What is causing this? A simple explanation is that the code that is being executed is running one (or more) tight loops that don't have any pauses built in. Apologies in advance if you're not one for coding, but consider these two simple programs:

/* Example 1 : No sleep */
while true {
    /* do stuff */
}

/* Example 2: Sleep */
while true {
    /* do stuff */
    sleep(1);    /* pause execution for 1 millisecond */
}

I mean, that doesn't seem like much, does it? Introduce a millisecond pause! That's nothing.

Well, on my PC that millisecond pause is the difference between that program consuming < 1% of CPU (with the pause), and consuming 10-12% CPU (without it)!

This is a basic example of code that might be considered to be "badly optimized". But, code that is badly optimized on one platform, might be perfectly fine on another platform.

Consider Stern's current pinball platform, SPIKE, which runs under the hood in Ghostbusters. It consists of a main "node" with the primary CPU that runs the core game code, and parcels out other responsibilities to more specialized satellite nodes. This main node is running a version of Linux on a relatively low-speed ARM processor. The only thing it is running, besides the operating system, is the game code. So there's no problem if the game code consumes 100% of the CPU - that's all it's ever going to do.

Compare that with your PC or your phone or tablet, which is running a whole bunch of stuff besides the Ghostbusters game code. For a start, it's running TPA/SPA, and it's running its own OS (Windows, iOS, Android) and all that entails, with a bunch of background apps and services.

Another thing that a real Ghostbusters table isn't running is a simulation of the laws of physics. This is where, maybe, the Ghostbusters code could be "optimized" for TPA/SPA.

Real-world physics doesn't run on CPU cycles. It's analog, always running, no interrupts, no sleep cycles. The code in a real Ghostbusters table needs to be able to react to real-world physical events as soon as they happen, and those events aren't governed by software collision detection. The code needs to react as quickly as possible, and this means running any loops in as tight a cycle as the CPU will allow: no sleeping allowed. Ye cannae change the Laws of Physics, Jim, and the Laws of Physics don't sleep for a millisecond every time round the loop!

In the simulated world, that luxury exists. You could bake that millisecond (or shorter, depending on the platform/language) pause into the code every cycle, it would give the CPU time to do other stuff, and performance would improve dramatically.

 

[ScotchYeti]

Even if everything appears to be always running, you split up 1 second in 60 frames (or any other value depending on the desired resolution). During this one frame you do what needs to be done. Any CPU cycles that are left you go to sleep.

The real problem often starts when something nasty happens in a library you rely on. Or maybe it's indeed the new emulation core that is hard to tame...

 

[EldarOfSuburbia]

Even if everything appears to be always running, you split up 1 second in 60 frames (or any other value depending on the desired resolution). During this one frame you do what needs to be done. Any CPU cycles that are left you go to sleep.

Like I said, there's the problem as I see it. The laws of physics don't go to sleep and don't have spare CPU cycles, so the game code has to be "always on" in a real machine.

I don't think there's anything wrong with the emulation core, because there's no emulation core for the modern Sterns: Farsight are compiling the source code, which they get from Stern, to run directly on each OS. There's no emulation layer; essentially all the modern Sterns are scripted, except the scripting has no second-guessing of code, because it's all there.

Performance in SPA is better than it is in TPA, at least it is for me on Android. It's also far better in TPA on my 'phone (LG G3) than it is on my tablet (Samsung Galaxy Tab S2), so maybe it's purely a Samsung thing (which wouldn't surprise me in the least, Samsung really screw with Android in their implementations).

TPA Ghostbusters runs at 40% CPU on my PC (i7-2600, 4x3.4GHz), I can't compare with SPA since it's not available yet.

So maybe there is something in the SPA framework that works better with the compiled code than TPA does. Or maybe the SPA binary is optimized for simulated physics, whereas the TPA one isn't? You'd think they'd use the same binary in both, but without looking at file sizes (or even knowing that I'm looking at the right thing), who knows?

 

[shutyertrap]

I think you are onto something, with them running the Stern code unaltered. When I was trying to look up my CPU usage even without the game running, it'd spike to 50% quite frequently and drop right back down as it ran Windows Update checks and other background things. This has been a complaint among Windows 10 Creator users, and I tried running as many hacks as I could find to drop the CPU usage. And yes, we've already established in other threads that my computer is old with its Dual Core2 processor, but I would expect slow down, not total computer crash like Ghostbusters causes now.

I'd love to check out if it runs better in SPA like you are saying, but it's still not released for the Steam version.

 

[Gorgias32]

This is certainly all just speculation, but it's a good observation that it must be one of FarSight's biggest challenges with emulation of ROMs, that the ROMs were programmed for a physical environment.

Interesting thread! I love seeing the pseudocode!

 

[pm1109]

Lets hope a steam update comes out today to fix this issue but I wouldn't hold my breath that this issue would be fixed that quickly knowing Farsight..

 

[ScotchYeti]

Physical environment or not, we are talking about getting the analog world into the digital. Even if you have the impression that something is continuously ongoing, in the computer you slice it up. Some years ago I was involved in an Atari emulator project and I think that the concepts are still more or less the same. Ah, the good old times.

Anyway, FS will fix it, no doubt about it.

 

[Worf]

SPA tables aren't emulated like TPA. SPA tables are executed - they take the Stern code and compile it to run natively on the host CPU. Minor modifications are needed to hook the code up to the virtual hardware.

It's possible that the Stern code makes lots of tight loops since it was coded to run on the Stern hardware directly and be the only application running.

 

[shutyertrap]

I was just reading that the new Assassin's Creed game is also running insane CPU usage. People are blaming it on the DRM though, while Ubisoft is just saying it's a demanding game. Biggest issue people are having though is that the minimum specs requirement listed has no way of actually running the game other than at like 12 fps. Anyway, thought it was timely to our concerns even if it's a whole other issue.