CPU Usage on Core 2 Duo

I have two Xojo apps:

  • A1 : foreground UI app which does OpenGL animation and tried to do 60fps updates, and uses about 10%-15% of one CPU doing so.
  • A2: background helper app which does computations. Normally idles around 1% CPU but can hit 100% when doing a computation.

For the most part, this setup works great.

However, I’ve discovered something weird: On OS X 10.10 or 10.11, on a Core 2 Duo chip (e.g. one that has only two cores and no hyperThreading), when A2 is consuming CPU then A1 stalls, and can not maintain a 60fps animation rate.

Observations:

  • OS X 10.9: works fine

  • OS X 10.10: problems

  • OS X 10.11: problems

  • This doesn’t happen on i5 or i7 CPUs that have 4 or 8 hyper threads.

  • This doesn’t happen with other processes that use CPU.
    For example in the terminal I can run:

yes > /dev/null 

which will suck up 100% of one CPU core, and this has no bad effects.
In fact, I can even run two copies of the command:

yes > /dev/null & yes /dev/null & 

which takes up 200% of CPU, and still A1 maintains the 60fps animation rate.

So it’s not simply that there isn’t enough CPU to go around; Something specifically changed in 10.10 that seems to cause multiple apps to conflict.

Anyone else seen this?

Apart from Xojo generating millions of context switches with Shells (I think that started with 10.10), do you see anything in the console?
Or maybe one machine uses the CPU for it’s graphics while the other one hands it over to the GPU?

This is exactly my thoughts also. Is your helper application using OpenGL anywhere?

I recently had a hard time with Core Image processing large images and I was using a similar set-up to you. Before I managed to reduce the time taken to process, if I let Core Image use the GPU, it would make the animation of the main application stutter, I have had it had crash a couple of machines. Switching Core Image to using Software rendering solved this stuttering and crashing.

In the end I found a solution for the root of the problem, which appeared to be asking Core Image to do too much to a largish image. I used a CIImageAccumulator to break apart the render chain into smaller steps.
Some more information and stats are here. https://forum.xojo.com/37852-core-image-pain

Great ideas - the Helper app does do graphics functions (such as loading an image and resizing it). That could stress the GPU as well, right?

But I tested with a very simple test app (this would be App2, the one wasting time, not the one doing the OpenGL animation)

button1.action
  // # intentionally waste a bunch of CPU
  #Pragma DisableBackgroundTasks
  dim t0 as double = Microseconds
    while (Microseconds - t0) < 10000000
    wend

And the results are the same.

[quote=309141:@Marco Hof]Apart from Xojo generating millions of context switches with Shells (I think that started with 10.10), do you see anything in the console?
[/quote]

I have not run Instruments or indeed watched Console for error messages: that might be interesting.

I can sort-of reproduce this in a very simple test program: Two Xojo apps, both running threads with a sleep(16) and some functions to calculate fps (and StandardDeviation of fps). Nothing else.

Most of the time they run at ~60fps. But if one of them hits the CPU to 100%, the other one will suffer: the fps will drop on occasion, and the StandardDeviation of fps rises noticeably. It’s not as dramatic as the case when A1 is running OpenGL animations, but it’s still measurable.

Is your helper application a console application or a GUI application (that doesn’t have or doesn’t show a window)?

Sounds to me as if those processors may have an issue.

[quote=309165:@Sam Rowlands]Is your helper application a console application or a GUI application (that doesn’t have or doesn’t show a window)?

Sounds to me as if those processors may have an issue.[/quote]

It’s a GUI application, although I’ve tried it running the time-wasting task within App.Open (before Window1 opens) and the results are the same.

If the GUI app runs a shell, and the shell wastes time (yes > /dev/null) then there is no impact.

So it does seem like “two or more GUI apps” is important.

I can’t say, the helper that I have right now (which is what does the heavy lifting with Core Image is a console application). When Core Image is set to software only the animation of the main application is nice and smooth, even when the helper is maxing out all cores. When it’s set to use the GPU, the animation gets choppy.

However right now, I’m using the GPU because it cuts render time in half, a few seconds of choppy or double the time with nice smooth animation. I’ll let the user decide with a prefs option, and also as I’ve experienced machine crashes when using the GPU.

In the past I’ve created helper apps that use a GUI, but only so that I could use NSSharingServices while the rest of my application was still 32-Bit. So It didn’t do anything intensive.

Thanks, Sam. If we aren’t on the same exact bug, we are probably on related ones.

The key to me: I can run two copies of a time-wasting command (“yes >> /dev/null”) which max out the CPUs on a 2 core system, and yet my app keeps animating at a solid 60fps. MacOS has always has great multi-tasking and this shows it.

Yet if even one Xojo app is using >50% of one CPU, then the other Xojo app suffers.

How are you launching the helper application?

Currently I’m using NSTask.

[quote=309326:@Sam Rowlands]How are you launching the helper application?
Currently I’m using NSTask.[/quote]

In normal operation, I’m using “open -gn /path/to/app.app” via a shell and then both apps communicate via an IPCSocket - but neither of those seem to matter… I see the same behavior with a completely independent App2 launched by double-click in the Finder.

Interesting, I wonder if this is just a widespread 10.11 bug?

I just tried this:

  • Mid Macbook Pro 2009 (core 2 duo)
  • OS X 10.11.6 completely stock installation
  • Open Activity Monitor
  • Open two Terminal windows, and in each one execute “yes > /dev/null”
  • No Xojo apps involved whatsoever

What happens is that things go haywire - Activity monitor stops updating and the system is generally unresponsive.

It’s almost like the task scheduler is really broken in recent macOS builds with 2 core CPUs.

The most recent 10.11 update fixed some issue in the kernel where the machine would become totally unresponsive
at least one cause had to do with Intel graphics & a “stall”
https://discussions.apple.com/thread/7800609?start=0&tstart=0

[quote=311091:@Norman Palardy]The most recent 10.11 update fixed some issue in the kernel where the machine would become totally unresponsive
at least one cause had to do with Intel graphics & a “stall”
https://discussions.apple.com/thread/7800609?start=0&tstart=0[/quote]
Interesting; I found that our latest app on a 2009 17" MBP would crash when working hard under Yosemite; but it’s fine under El Cap.

Yep it has a Core 2 Duo processor. Let’s see if I can the program to check for that and warn the user.

Thanks guys.

[quote=311091:@Norman Palardy]The most recent 10.11 update fixed some issue in the kernel where the machine would become totally unresponsive
at least one cause had to do with Intel graphics & a “stall”
https://discussions.apple.com/thread/7800609?start=0&tstart=0[/quote]

This 2009 MacBook has a NVIDA 9400, so might be something different.

Anyone out there have an older mac with Core 2 Duo and willing to run my test and report back?

Sure, I’ll give it a go, which version of the macOS would you prefer?