ZBrush under OS X: multithreading issue

I hate to disappoint you but this is a SOFTWARE issue not a Apple or Mac issue.

All of the developers had access to Mavericks in Beta before it was ever released to fix the problems with there software. Some did fix them, and Some did not. So I will leave it up to you to decide who was at fault in this case.

I think Donald was just assuming this was another that you noticed after installing Mavericks. This is the Mavericks thread after all.

Aside from that, Donald is completely correct. It takes a significant amount of CPU usage to cause the fans to kick in on a modern machine. The authors of ZBrush seem to have a fundamental misunderstanding of processors and multithreading. Apple can't fix that.

This is a user-to-user forum. Apple moderates the forums but isn't going to read the content or comment on anything. People at the Genius Bar don't know programming, so they can't help.

I've been a programmer for a couple of decades now. They don't know what they are talking about.

architektx wrote:

Because i'm using Mavericks and no one said if it's OS X problem or not.

I don't want to say that it can't be otherwise. More over, explanation "fans make it all hotter" sounds kinda a bit... illogical to me. Still, Pixologic insist that it's Aplle's side issue.

As I mentioned you will have to reduce the number of cores to one, basically turn muli-threading options down to one thread. There is no other workaround for this situation until Apple themselves can correct the system from thinking that each core is a completely separate physical processor.

I would really like to hear Apple's point here and if it's Apple's-side issue it's at development level so guys from Genius Bar won't say anything usefull.

This is a user forum.

Having written multi-threaded software for various applications, the description could easily be explained by a bug in the application implementation of multi-threading, or could also be a bug in the host OS. There have certainly been bugs in Apple software, and bugs in applications are rather more common.

This could also be that the application is simply processor-intensive.

Nobody here can help you with any of those potentials nor provide more than speculation, unfortunately.

If the Pixologic folks have not already done so, ask the developers if they're willing to post the bug report in the Open Radar service — preferably with a reproducer of some sort included — and some other folks can have a look. There might be a workaround. Or there might be an application code bug. Or this is an intractable Apple bug. Anybody that's programmed has certainly created bugs, after all.

FWIW, if this Pixologic statement:

ZBrush is software rendered, meaning that ZBrush itself is doing the rendering rather than the GPU. Your choice of GPU will not matter so long as it supports the recommended monitor resolution.

also applies to OS X, as well as to Microsoft Windows, then this software package will potentially be very processor-intensive.

These Graphics Processing Units (GPUs) widgets are hardware devices that exist to accelerate various rendering tasks, and to off-load the Central Processor Unit (CPU) of various processor-intensive (core-intensive) display-related tasks, and rendering and video transcoding and such are all very processor-intensive (core-intensive) operations. They'll all warm up the processors, and will all spool up the fans.

I can only assume that the Pixologic folks are not offloading various rendering tasks to a GPU (on Windows, if not also on OS X) for a reason, too.

As an example of GPU-based hardware, the Mac Pro has up to twelve cores, and two very speedy GPUs, with one GPU providing rendering and the second GPU available for more general computing tasks. If those GPUs are not being used, all the rendering will be done by the Xeon processor, and that'll definitely warm up some number of cores. (FWIW, you can get a view of the per-core processing activity via the Activity Monitor tool; Applications > Utilities.)

Sorry, but no. I cannot explain this any more than to simply say that the authors of the quote in your first post simply have no idea how a computer works. I am not being facetious or making a joke here. It is fundamentally wrong.

The fans are controlled by hardware sensors. When the CPU starts to work hard and heats up, the fan keeps it from getting too hot. The fan does not cause heat. The fan cools. Whatever miniscule amount of heat that the fan motor itself generates is dissapated by.... the fan.

There is only one CPU on your machine. If it has 4 cores, and only one of those cores is working hard and heating up, the CPU still gets hot. The cores are on the CPU. You cannot heat up a single core without heating up a CPU.

In modern OS X software, you cannot really turn multithreading on or off. A well-designed program will spawn many small tasks that will be distributed across all cores according to which ones have capacity. If you have 4 cores and are running something intensive on one core and then start up another program that properly implements multithreading, it will only use the remaining 3 cores.

It sounds like the authors of this program are simply using some 3rd party library ported from Linux or something and they don't understand it any more than they understand computer architecture. To give them the benefit of the doubt, it may be just the support person that is clueless and is telling people a typical blame-it-on-Apple story. I looked at the web site and it seems like a sophisticated program, or at least it was in 1999. It seems to be using obsolete multithreading logic and completely ignoring modern graphics techniques. Apple can't fix that.

architektx wrote:

In the fact that you can indeed reduce the number of threads that ZBrush is using. This situation has been going on back and forth for quite some time. Start up ZBrush and from within the preferences you will find the ability to reduce the number of cores that is being used. This workaround currently works 100% of the time with users that run into your situation. Also note that this situation does not happen to ALL apple users. As far as me saying the fan was increasing heat goes, it seems that this is where the situation is sticking at and not the real situation. That is where I simply misspoke while trying to explain to you that for some reason each thread is being seen as a whole and full processor on its own, your fans are going into overdrive because it thinks you are not running multiple cores on one processor but it is behaving as if EACH thread is a whole separate physical processor. This is how it was explained by our development team. If it is all incorrect it still leaves you with the situation that currently reducing the number of threads being used will reduce the heat issue you are seeing. I am passing the information you sent along to our development team right now so that they can either give us an updated and more valid reason for the situation or get it corrected on their end.

Going to a single core is the text-book workaround for latent synchronization bugs in the application code, or in the underlying operating system code. The particular trigger can be difficult to locate and can be exceedingly timing and configuring dependent, too. These bugs can be triggered by differences in disk speeds and file access timing, or unexpected memory contention, or any number of other factors.

The explanation you've received also seems a little garbled. Fans spool up when the cores heat up, and the cores heat up when something — whether it's an infinite loop or actual work like image rendering — is going on, or the application and the system have gotten locked into some unexpected state.

FWIW, it's curious why you weren't instructed to enable some in-built application diagnostics and capture some details of your environment and the run-time environment. When presented with these sorts of bugs in large and complex applications, some vendors choose to implement internal diagnostics or guards or interlock mechanisms — details depend highly on the bug and its trigger — within their applications, in an attempt to better identify and isolate the exact trigger for the misbehavior.

The other approach is for one of the programmers involved to use DTrace and have a look around when the system is looping. That approach is more common on development systems, and particularly when you can more reliably duplicate the trigger for the bug.

Again, there's not much that's going to happen here to resolve whatever is happening with this particular Pixologic code on your Mac, unfortunately. This is between Pixologic and Apple to sort out; either a workaround or a different approach in the Pixologic code, or a fix for whatever might be wrong in the Apple code. (This assumes that the bug is in OS X, too. I'd not automatically assume that, but then I don't have knowledge of what Pixologic and Apple have been discussing here.)

architektx wrote:

etresoft, thank you, sir. It doesn't solves the problem but it helps me as non tech person to get abit about the possiable sourcer of the issue. Well, so far i've only to use Bootcamped Windows 8.

I'm confused. Are you running this program under Windows?

There's a such function to turn off/on multhitreading but if i've got you correctly, you mean it's not actually real turning it on or off?

It depends on the implementation. In a very primitive implementation, there may be a "num_threads" parameter to specify how many threads to start. If you have more processors than threads, then you are wasting CPU capability. If you have more threads than processors, then you are doing too much swapping between threads with no benefit. If your I/O cannot feed data fast enough for all the threads, then you have too many threads again.

You might see something like this in an old, UNIX command-line tool. Modern software should be much smarter about such things. Ideally, it would only have one thread that reads some data to work on, passes it off to the GPU, and waits for it to complete before starting on the next chunk of data. I would expect a program like this to be a heavy GPU user. Try running any modern (or decade-old) game with software rendering. I suspect the experience will be very familiar to a Zbrush user.

Also, you started this thread based on what your vendor told you, asking when Apple would have a fix for the problem. You never really said what "the problem" is. Loud fans? That is to be expected consider what this program is doing.

architektx wrote:

MrHoffman, nope, they didn't tell me to make any application diagnostics. They admit it's a known problem. But from you say it's not so known 😀

There are many known problems in many versions of OS X and of many applications, and it's simply not possible for anyone to be familiar with all of them. Some are quite subtle, and rarely seen.

Without lower-level (technical) details of what's happening and preferably a reproducer — which is why I suggested OpenRadar earlier — it's generally not possible to identify and discuss a particular problem.

Do I know of a generic problem in OS X that'll cause this particular core-warming behavior? No. (If there was a generic core-warming problem latent in OS X, I'd expect that would usually be discussed all over the forums.)

There's an old programming joke that's somewhat relevent to this class of programming bug:

Some people, when confronted with a programming problem, think "I know, I'll use multithreading".

Now have problems two they.

More seriously, there are many potential triggers these sorts of programming bugs. Getting the sequencing wrong or the locking and the coordination wrong (in an application or in the underlying operating system code) is very easy, and the bugs — the triggers for some of these problems — can sometimes be incredibly subtle to find and fix.

Hello evryone ,

I have the same issues on my iMac with Maverick 10.9.1, just opening Zbrush (4r6) push the user procesus close to 90% and the cpu start to up to 50-60° in less than 1 minute. I'm doing the same and using it with bootcamp Windows 7 without any issues. Also some small probleme with some features in Mudbox (2014 sp2) on OSX 10.9 that i dont have with Windows 7..I'm lucky to be not ermetic with Windows ^^ But its sade solution for 3d designers & Mac customers to use windows on there Mac. Even if its not for all ussers, it still have more issues in 3d with OSX, "generaly" no ?

ps : Sorry for my english

Hi!

Still same problem, with El Capitan, i hoped witha system update,somethingwill change, butallremained without changes, wait for clarificationfrom apple or zbrush.