Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MP 7,1 Mac Pro vs. MacBook Pro 16" Benchmark

K

kelvin.lau

macrumors member
Original poster
Jan 22, 2019
38
37
My three computers had the following specs:

MacBook Pro 15" (2018)
2.9 GHz 6-Core i9
32 GB 2400 MHz DDR4
Intel UHD Graphics 630 1536 MB

MacBook Pro 16" (2019)
2.4 GHz 8-Core i9
32 GB 2667 MHz DDR4
Intel UHD Graphics 630 1536 MB

Mac Pro (2019)
3.2 GHz 16-Core Intel Xeon W
32 GB 2933 MHz DDR4
AMD Radeon Pro Vega II Duo 32GB

For the benchmark, I used WordPress's open source iOS project. Here was my test procedure:

1. (cmd + shift + k) Clean the project
2. (cmd + b) Build the project

Here were the results:

MacBook Pro 16"
2m31s

Mac Pro
3m16s

MacBook Pro 15
3m32s

I did 3 attempts for each computer. I'm a little disappointed, and confused. The components on my Mac Pro are better on paper. How did I lose out to the MBP 16?

I really want to keep my Mac Pro. I know that as a developer, I'm not the main target audience for the product. However, I thought it was still going to be faster than my laptop. Does anyone have any ideas on why this is happening?

Edit1:

Did some further testing based on some feedback from others. Here are some results (brackets shows multiple test timings):

4:00 - 8 active cores (equivalent to Quad Core)
3:06 - 15 active cores (7.5-Core)
[2:41, 2:43, 2:31, 2:31] - 16 active cores (8-Core)
[2:27, 2:53, 2:29, 2:23, 2:41] - 17 active cores (8.5-Core)
2:28 - 18 active cores (9-Core)
2:31 - 19 active cores (9.5-Core)
2:43 - 20 active cores (10-Core)
2:47 - 21 active cores (10.5-Core)
3:12 - 24 active cores (12-Core)

At 17 active cores, Mac Pro can overtake the MBP 16"
 
Last edited:
Mate - could you pleeeeeease run Logic Pro X benchmark tests on the MBP 16 bs the 7,1?

Its just a project you download from here and open in Logic X, then see how many tracks you get running before it runs out of power... https://logicbenchmarks.com

Would be great to be able to compare those 2 computers with those specs!!!
 
MGrayson3 said:
How many cores were in use? This looks like a pure GHz issue.
Click to expand...

Agreed. It could be that Xcode dutifully spread the load over all 16 cores, which may have both incurred overhead in spinning up a lot of processes and (most importantly) caused the Xeon to de-turbo down to the base clock speed.

I agree that it's quite disappointing such an expensive machine does not at least equal a supposedly more constrained laptop.

However, there are a few sources for hope:

The Mac Pro is very new and I don't think Xcode has even had a point release since its release.

It is possible some of the team will themselves start using Mac Pros and they'll no doubt want to optimize its performance.
 
Another possibility is the SSD. Was the SSD identical? Compiling typically involves fetching lots of small files, so a larger SSD in the 16" may have an advantage.
 
  • Like
Reactions: Krevnik
MGrayson3 said:
How many cores were in use? This looks like a pure GHz issue.
Click to expand...

I had iStat downloaded on my Mac Pro. The CPU spikes during parts of the compilation sequence. Sometimes it uses all 16 cores, then goes down to very minimal 5% utilization.
[automerge]1579269988[/automerge]
PeterJP said:
Another possibility is the SSD. Was the SSD identical? Compiling typically involves fetching lots of small files, so a larger SSD in the 16" may have an advantage.
Click to expand...

Both the 16" and the Mac Pro have 1 TB SSDs. I've got an Intel Optane 900p on my windows computer, let me see if that could make a difference.
 
kelvin.lau said:
I had iStat downloaded on my Mac Pro. The CPU spikes during parts of the compilation sequence. Sometimes it uses all 16 cores, then goes down to very minimal 5% utilization.
Click to expand...

That bit where it drops to 5% utilisation, how long does it last for and does that also occur on the MacBook Pro? Be very interesting to find out what's causing this.

Also you might try compiling another project such as Chromium or the Linux kernel (https://chromium.googlesource.com/chromium/src/+/master/docs/mac_build_instructions.md). I'd be very surprised to see if the MBP beats the MP.
 
Last edited:
This illustrates the importance of testing a new system with your workload. Benchmarks and theoretical performance don't always tell the whole story (which is why I don't like GeekBench). If the MBP ends up being faster for what you need it for then return the Mac Pro (which isn't much faster than the 2018 MBP). That's a lot of money to spend on a system which isn't faster than something you already own.
 
AdamSeen said:
That bit where it drops to 5% utilisation, how long does it last for and does that also occur on the MacBook Pro? Be very interesting to find out what's causing this.

Also you might try compiling another project such as Chromium or the Linux kernel (https://chromium.googlesource.com/chromium/src/+/master/docs/mac_build_instructions.md). I'd be very surprised to see if the MBP beats the MP.
Click to expand...

After another look, it only happens for a brief segment of the compilation process. I made a shoddy (sorry) video of the companion between the two devices
 
Ok, it looks like there is a throughput issue on the Mac Pro. As to whether that’s a disk issue or something else, have to dig into it more.

Looking at the Intel pages there doesn’t seem to be much difference between the instructions available except for the Mac Pro has AVX 512. Where would I go next?
Checkout another build such as chromium or the Linux kernel. Build something with gcc or similar (not Xcode). Check throughput across relevant IO (ssd, network). Perhaps check file system events api (can access it through terminal, but there may be other ways). Try disabling some of the cores (using instruments) to see if it’s doing too much multithreading

The MBP has no reason to beat the MP by this much. The MP is more powerful. I’m guessing, as mentioned above, it could be a software issue with Xcode or that particular build.
 
Last edited:
I tried this myself on my 28 core Mac Pro and the problem is that swiftc is launching as many processes in parallel as there are processor threads. Xcode is also launching swiftc processes in parallel. So you end up with:

Macbook Pro 6 Core: 12 * 12 = 144 processes
Macbook Pro 8 Core: 16 * 16 = 256 processes
Mac Pro 16 Core: 32 * 32 = 1024 processes
Mac Pro 28 Core: 56 * 56 = 3136 processes

The ideal number of processes is the number of threads for the processor. What we are seeing is all time spent in the kernel context switching.

I only work on C++ code usually where the clang compiler is not doing something so braindead. Seeing this behavior in the swiftc compiler is really surprising to me. It's a rookie mistake.
 
Good find 👍 That will definitely do it.

Kelvin, if you disable 8 of your cores using instruments app, can you re-run the test and confirm? Worth submitting a bug report as well.
 
Thanks for the tips. Here are some results (brackets shows multiple test timings):

4:00 - 8 active cores (equivalent to Quad Core)
3:06 - 15 active cores (7.5-Core)
[2:41, 2:43, 2:31, 2:31] - 16 active cores (8-Core)
[2:27, 2:53, 2:29, 2:23, 2:41] - 17 active cores (8.5-Core)
2:28 - 18 active cores (9-Core)
2:31 - 19 active cores (9.5-Core)
2:43 - 20 active cores (10-Core)
2:47 - 21 active cores (10.5-Core)
3:12 - 24 active cores (12-Core)

At 17 active cores, Mac Pro can overtake the MBP 16". Will do more jiggering to see if I can find a even better sweet spot.
 
Last edited:
kelvin.lau said:
I had iStat downloaded on my Mac Pro. The CPU spikes during parts of the compilation sequence. Sometimes it uses all 16 cores, then goes down to very minimal 5% utilization.
....
Click to expand...

it is not just the compiler that in the compilation sequence, it is the project. Depends upon how the code is structured. Brief example

file A ---\
file B -------- > library ABC
File C ---/

file D -------> library DE
file E ---/

file W dependent up library ABC
file X dependent upon library DE
File Y dependent upon X and W
File Z dependent upon File Y , X , W , library ABC , library DE

Can't run all nine files in parallel. Definitions and structures in some are being used to build parts that the other, "downstream" files use. Usually have a relatively large number of basic type that are largely independent. But later will have files that intermingle the usage of those basic types ( more dependencies). the latter can kill off parallelism.

XCode probably has some sort of "build plan" / "build phases" for this project ( and perhaps pull out some of the implicit dependencies and make the explicit in the plan. ) . And very complicated build plan can negate more than a handful (or two) of cores.
 
kelvin.lau said:
Thanks for the tips. Here are some results:

4:00 - 8 active cores (equivalent to Quad Core)
3:12 - 24 active cores (12-Core)
2:53 - 20 active cores (10-Core)
2:41 - 16 active cores (8-Core)
2:27 - 17 active cores (8.5-Core)

At 17 active cores, Mac Pro can overtake the MBP 16". Will do more jiggering to see if I can find a even better sweet spot.
Click to expand...

That is quite astonishing but good to have it confirmed. I’m not familiar with Xcode projects, but could it be a project level thing?
 
John_B Beta said:
Mate - could you pleeeeeease run Logic Pro X benchmark tests on the MBP 16 bs the 7,1?

Its just a project you download from here and open in Logic X, then see how many tracks you get running before it runs out of power... https://logicbenchmarks.com

Would be great to be able to compare those 2 computers with those specs!!!
Click to expand...
16-core with unbalanced ram hit 478 tracks. I'll get you the 8 core 16 a little later
 
Beliyaal said:
I tried this myself on my 28 core Mac Pro and the problem is that swiftc is launching as many processes in parallel as there are processor threads. Xcode is also launching swiftc processes in parallel. So you end up with:

Macbook Pro 6 Core: 12 * 12 = 144 processes
Macbook Pro 8 Core: 16 * 16 = 256 processes
Mac Pro 16 Core: 32 * 32 = 1024 processes
Mac Pro 28 Core: 56 * 56 = 3136 processes

......
Click to expand...


It think the approach works OK on 4-8 core systems, which wouldn't be surprising what most Swift developers have. Got a little wonky at 16-18 cores on some rarified iMac Pro. Only runs into a buzzsaw on the new highest end.

Looks like a mismatch in awareness. XCode thinking that the compiler is limited so invoking many copies. The compiler with its own plan. And the two not working together at all.


I only work on C++ code usually where the clang compiler is not doing something so braindead. Seeing this behavior in the swiftc compiler is really surprising to me. It's a rookie mistake.
Click to expand...

Yeah the "go crazy, let the OS scheduler figure it out" approach. ( I've seen some non-rookies make that mistake when given access to more than a "normal" set of cores. )

Dependencies tend to be higher in C++ so not surprising the default there is to not go "hog wild" on core usage unless it makes sense. Languages with more dynamic bindings tend need to recompile few modules (fewer dependencies ) but also engage in duplicative work ( reload and reanalyze interfaces ).

Most of the time don't have to do "wipe project binaries clean" to incrementally fix something.


This has to have been a somewhat "know" problem to Apple though. Stumbled across this 2018 blog related to the topic.

" .. Our testing shows that moving from a dual-core Mac mini to a 12-core Mac Pro can give a 3x speedup without any additional effort. ..."

Improving Xcode Build Times

As projects grow, build times can become problematic. However, there are several tweaks you can make to Xcode that can decrease the amount of time it takes for builds to complete without any extra work. Additionally, Xcode 14 ships with some powerful tools to help you gain insight into potential...
blog.macstadium.com blog.macstadium.com

So 6x cores leads to a 3x speed up. That is way under 1:1 linear.

Same blog

"... By default, Xcode typically uses the same number of threads as the number of cores in the machine’s CPU. However, you can dramatically reduce build times – in some instances by a full 30% - by increasing the thread count beyond the default. This takes advantage of some processors’ ability to multi-thread or simulate additional cores. ..."

If someone has tweaked XCode to follow the virtual cores then that is problematical. 28^2 or 16^2 are far more tractable numbers for the scheduler to handle.

I haven't found the setting for the "scale factor" but if that can be 'dialed down' for XCode then can bring it back to the physical cores.

[ If compiling off a very fast SSD and have large enough RAM for a multiple GB file system cache the processor SMT probably isn't going to help very much once most of the common sources files are touched and cache loaded. ]

P.S. Not sure if same parameter in current XCode. ( more often build more general stuff with another build tool. )

"... "xcodebuild" tool allows to control the number of threads used during the builds using "-jobs" option, or with "IDEBuildOperationMaxNumberOfConcurrentCompileTasks" Xcode setting. ..."
www.linkedin.com

The best hardware to build with Swift is not what you might think

In the previous article I shared some data regarding Swift compiler performance when compared with Objective-C. I noted that Swift builds are significantly slower than comparable Objective-C code.
www.linkedin.com www.linkedin.com

Similar issue measured in 2017 context of that article.
 
Last edited:
  • Like
Reactions: AdamSeen
RyanFlynn said:
16-core with unbalanced ram hit 478 tracks. I'll get you the 8 core 16 a little later
Click to expand...

Thanks a million man much appreciated - just asked you this in another thread hah! You've got a lot more RAM than I was planning on, but that's easy enough to add progressively. Will be interesting to see how many tracks you can get with just the base RAM (or 48Gb so I've got all 6 channels used). I just do dance music so won't need as much sample memory as you presumably do running big kontakt instruments for soundtrack stuff so should be ok
 
  • Like
Reactions: RyanFlynn
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back