Why is Mac OSX so slow compared to Windows, especially using Logic and MainStage, despite better HW?

[Zaphod (giancarlo)]

btw intel ipp v 8 is still a bit slower on mac osx... it's a matter of programming, though. If you execute the same asm code obviously they are the same.

[MeldaProduction]

Hmmm, can you be more specific about "wrong way"?

Edit: IPP may be slower, but according to benchmark it was still faster than the PC.

[otristan]

Good points Otristan!

About the OSX vs Windows. Yeah, it must be something related to thread handling. There are no allocs (well they may happen initially of course, but then it's over). And critical sections are there, but they should always pass, since they are separate for each instance. The only case would be if the passing critical section would be that slow, but as far as I know both cases (Win32 and OSX) should be using the test & set instruction, so technically no CPU overhead. I'm using this on OSX: MPEnterCriticalRegion . Is there a better alternative?

do not use MPEnterCriticalRegion as it's synch between multiple process so probably heavier (and deprecated) but use pthread_mutex or better like OSSpinLockLock which have lower overhead when low contention is expected

http://stackoverflow.com/questions/5869 ... d-of-mutex

Beware OSSpinLockLock is not recursive as opposed to Windows CriticalSection

[mystran]

Perfectly understandable DrGonzo . I started on Atari too! Those were the times... ehm... I'm glad they are gone . I'm pretty sure it's the history of Windows that many people scared... Up to Win XP it wasn't operating system at all . And Win XP is more like Linux than a user friendly system, good for hackers though . With Win 7 are great. Win 8 less so... but survivable. They start in a few seconds, don't know how they did it .

I would argue that the step from NT4 to Win2k (which was originally supposed to be the version that would move everyone to the NT line) was bigger than the step from Win2k to XP, but even the old NT4 was quite usable really, I don't remember any stability issues with either that or W2k really (back then I was primarily a Linux user, but I used W2k as my gaming platform for years even after WinXP was released, as there wasn't really anything that significantly in XP to bother with an upgrade). If you're comparing to the Win95/98 line, you're not being completely honest, as WinXP was just another version of a different (and pretty decent) line of operating systems.

But I guess that's really the problem. Because of the silly naming conventions, people still associate the problems of the Win95/98 line to the modern NT based Windows, even if the NT line actually predates those systems and while I have no personal experience about versions prior to 4.0, I've been told that it never was the train-wreck that the 95-line of glorified DOS-extenders were.

[and since we're discussing history: I also known a retail copy of OS/2 Warp, which I used at some point to play some DOS-games, as unlike Win95 you could reliably multi-task back and forth between the game and other applications without having to worry about the whole thing crashing down; it actually worked a bit better than running DosEMU in Linux]

[MeldaProduction]

Good points Otristan!

About the OSX vs Windows. Yeah, it must be something related to thread handling. There are no allocs (well they may happen initially of course, but then it's over). And critical sections are there, but they should always pass, since they are separate for each instance. The only case would be if the passing critical section would be that slow, but as far as I know both cases (Win32 and OSX) should be using the test & set instruction, so technically no CPU overhead. I'm using this on OSX: MPEnterCriticalRegion . Is there a better alternative?

do not use MPEnterCriticalRegion as it's synch between multiple process so probably heavier (and deprecated) but use pthread_mutex or better like OSSpinLockLock which have lower overhead when low contention is expected

http://stackoverflow.com/questions/5869 ... d-of-mutex

Beware OSSpinLockLock is not recursive as opposed to Windows CriticalSection

Thank you Otristan, will definitely check it out! Though I wonder how bad could the performance of MPEnterCriticalRegion be... It shouldn't even reschedule if it can access the lock.

[ZenPunkHippy]

This is not very scientific, but I used the well known DAWbench project to compare performance of 2 machines:

2009 Mac Pro / 8-core @ 2.26 GHz dual XEON / 12 GB RAM / OS 10.9.2

2012 Intel E5 / 6 cores @ 3.2 GHz XEON / 16 GB RAM / Win 7 x64 (tuned for DAW performance)

The mPressor version of the test project was used on both machines because there is no Mac version of the specially developed REA comp used for the Reaper native comp test on Windows.

Mac: 240 mPressor instances active
Win: 384 mPressor instances active

It's possible to activate a few more instances on the Win machine but that is how many were included in the project to begin with - and the CPU is basically maxing out anyway, it started to stutter with 2 or 3 more instances.

The Win machine runs a newer CPU with higher clock speed per core, but there are 2 x CPUs in the Mac.

Oh, and Reaper crashed once on Windows during testing

I think the ageing Mac Pro holds up quite well. In real world usage, I never run out of CPU power in my projects. Previously was constrained by RAM limitations, but that is obviously no longer a problem with Logic and all plugins I use regularly being 64-bit.

What I will say about Macs is that the disk performance is generally quite poor compared to Windows, and the network side is a bit rubbish too. These are the most frustrating performance related problems I encounter. It generally does not affect my audio projects, but copying large files between disks or to and from a NAS, yeah I notice that it's slower on OS X.

Peace,
Andy.

Note: hats off to Vin Curigliano at AAVIMT in Melbourne for putting together DAWbench project, and for building awesome Win based DAWs.

[Zaphod (giancarlo)]

Good points Otristan!

About the OSX vs Windows. Yeah, it must be something related to thread handling. There are no allocs (well they may happen initially of course, but then it's over). And critical sections are there, but they should always pass, since they are separate for each instance. The only case would be if the passing critical section would be that slow, but as far as I know both cases (Win32 and OSX) should be using the test & set instruction, so technically no CPU overhead. I'm using this on OSX: MPEnterCriticalRegion . Is there a better alternative?

do not use MPEnterCriticalRegion as it's synch between multiple process so probably heavier (and deprecated) but use pthread_mutex or better like OSSpinLockLock which have lower overhead when low contention is expected

http://stackoverflow.com/questions/5869 ... d-of-mutex

Beware OSSpinLockLock is not recursive as opposed to Windows CriticalSection

exactly...

[EvilDragon]

Winodows and mac osx are pretty the same, maybe mac is faster on hard drives.

Actually, Windows is faster on hard drives. Especially SSDs, IIRC.

[Zaphod (giancarlo)]

Hmmm, can you be more specific about "wrong way"?

Edit: IPP may be slower, but according to benchmark it was still faster than the PC.

no, ipp is slghly slower, especially for larger kernel sizes. Anyway if you use assembler code they are the same... if you use pthreads for threads they are the same ( there is a better handling for thread priorities on mac osx)... events for waking up when waiting on mutex and so on. Things are the same. Windows is slighly more spartan and fast (less checks) but it is slower on hard drives, for example. At the end mac osx is fast, application wise. I'm not speaking about itunes, complex applcations like office or browsers. Mac osx is not so bad. Still I dont like it.

[Zaphod (giancarlo)]

just an exception, named pipes (windows) are faster than domain sockets. Anyway you could use shared memory if both processes are on the same architecture. Windows is good for basic things.

[planetearth]

Thanks. Unfortunately it doesn't explain the problem. Macs indeed seem to have good hardware. But how is it possible it is now so slow. It is on Mavericks though, so it is actually possible it's the case. But as far as I remenber my Mac was slow with Snow leopard as well. But I think people have different "acceptance" for speed. I have seen so many Apple users claiming how fast and stable it is, yet when they were showing me I almost could nake a nap . For me Windows 7 is the fastest, Windows 8 seemed to be problematic when it has been released, I don't know now with Windows 8.1. Anyway results of my benchmarks are just extreme...

With Windows you can really have great performance, but then the musicians find out about games and porn and start wondering where did all the performance go . With Macs, well who knows... that's what I'm trying to find out .

Erm... First of all, I can explain the porn. How the games got onto my computer, I'll never know.

While most of this has been over my (technical) head, I'm learning quite a bit about the operating systems and about those who post what they know. I would have assumed the differences in the Mac OS speeds (when compared to other versions of OSX) would be due to bloated updates being pushed out, with little regard for how they'll affect the speed of the system. After all, a system that's 2% slower but crashes far less frequently is "better" to the end use than a faster system that's still unstable. It seems Microsoft has done this for years with XP, Vista...and now Windows 8/8.1.

I appreciate what Melda is saying here, and that this hasn't devolved into a Mac-vs.-Windows fanboy deathmatch of some kind. It's great that the technical aspects are still being discussed in this thread, and that no one has resorted to unseemly criticisms (well, aside from the comment made about my porn, that is).

And Melda, I really appreciate your plug-ins, and was just about to install them on my new DAW. I know many musicians who swear by them, and I'm glad to see you have a sense of humor and you're interested in really finding out what's going on with the systems for which you have to develop your effects and instruments.

Steve

[Aletheian-Alex]

Well without knowing the exact settings of each project, I can only throw a few suggestions out there. Logic/Mainstage 9 was kind of a mess with multiple instances/high track counts. Chatter on the boards for Logic X seems to be the opposite of your experience... the figure I see tossed around most often is Logic being roughly 3x more efficient then Reaper, but I don't have either at the moment so I can't say.

I would fire up TimeProfiler instrument and see where the hotspots are because there is obviously a bottleneck somewhere, and see if it is an OS issue (if it is, please let us know so we can avoid the same thing). Another issue might be Clang/LLVM growing pains. I just recently rolled my own build of LLVM so that I could get to the auto-vectorizor output in XCode and that was a bit eye-opening since I could see what loop syntax it was choking on and re-write it. I also noticed some other anomalous behavior like a certain plugins running more CPU-efficiently with an animated cocoa UIs than with the generic view... which was just bizarre and I found no explanation for apart from some threading differences in xcode instruments.

As for the Win vs OSX question: from a user perspective, I gravitated toward Macs because of the stability, ease-of-troubleshooting and support. I used to do on-the-spot recording sessions and live events, so troubleshooting a misbehaving Win system with Cubase/Nuendo in the field or playing the 'driver blame game' with tech support in terms of which vendor's drivers/hardware/software was to blame for an issue was just a nightmare, not to mention spending a good portion of each session simply trying to keep Nuendo crackle-free. I gravitated to OSX/ProTools and eventually OSX/DigitalPerformer and haven't looked back. The few hardware issues I have had were solved quickly enough that it didn't interrupt the session (once had a logic board overnight-aired and installed free of charge within 24 hours). But that is just personal experience, so take it with a grain of salt.

[EvilDragon]

W7 onward is the epitome of stability over here.

[MeldaProduction]

Thanks you all folks for the exhaustive info .

So, the SYNCHRONIZATION STUFF

I did try to remove simply all synchronization, completely. Just hoping it won't crash during testing. It didn't, but it didn't help at all. So it is not related with sync... after all in single processing thread all locks needed to pass...

And THE PROFILER

I must say, this is the first thing I really loved on OS X! XCode is a piece of lazy buggy junk, which doesn't even have basic debugging tools. But the profiler is awesome! Simple and effective. I wish I had something like that on Windows...(any recommendations? )

Anyway I analyzed Reaper and Logic and unfortunately it seems that for the complicated calculations the plugin performs the Mac or LLVM code just doesn't work that well... According to the tests:

Reaper really takes most of the CPU, starting 4 processing threads, according to the profiler 99% of the time was spent in the processing routine, where there's really nothing to optimize.

Logic did the processing the same way, but used only 2 threads, so it basically left about 30-40% of the CPU time unused... what a waste. So there's the explanation why Logic is slower than Reaper.

CONCLUSION?

I got nothing . Probably LLVM doesn't generate such a good code after all, well MS compiler was always unbeatable for me. Or maybe the MacBook isn't that fast after all. Either my benchmarks didn't work that accurately, or maybe it fails with more complicated calculations, maybe memory/cache problem, hard to say.

But it's not multithreading (well it is for Logic...)... The MacBook is just slow eventually...

[mystran]

I must say, this is the first thing I really loved on OS X! XCode is a piece of lazy buggy junk, which doesn't even have basic debugging tools. But the profiler is awesome! Simple and effective. I wish I had something like that on Windows...(any recommendations? )

Very Sleepy is a pretty decent free sampling profiler. For very cache sensitive code you might need to adjust the default polling rate down a bit (to keep it from affecting results too much), but other than that you just tell it what process/threads to profile and let it run for a while. It'll then show source locations/private symbols for any modules that it can find debug symbols for (ie locate the PDB, which usually works automatically), but doesn't need any instrumentation and doesn't mind unknown code so you can just profile your DAW directly, or whatever.