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

kelvin.lau

macrumors newbie
Original poster
Jan 22, 2019
9
2
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:

John_B Beta

macrumors member
Feb 7, 2004
41
29
Maidenhead, UK
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!!!
 

Bradleyone

macrumors regular
Jul 7, 2015
222
249
Sydney, Australia
How many cores were in use? This looks like a pure GHz issue.
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.
 

PeterJP

macrumors 6502a
Feb 2, 2012
641
408
Leuven, Belgium
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

kelvin.lau

macrumors newbie
Original poster
Jan 22, 2019
9
2
How many cores were in use? This looks like a pure GHz issue.
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.
- - Post merged: - -

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.
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.
 

AdamSeen

macrumors regular
Jun 5, 2013
176
137
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.
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:

defjam

macrumors 6502a
Sep 15, 2019
795
731
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.
 

kelvin.lau

macrumors newbie
Original poster
Jan 22, 2019
9
2
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.
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
 

AdamSeen

macrumors regular
Jun 5, 2013
176
137
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:

Beliyaal

macrumors member
Feb 14, 2008
53
19
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.
 

AdamSeen

macrumors regular
Jun 5, 2013
176
137
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.
 

kelvin.lau

macrumors newbie
Original poster
Jan 22, 2019
9
2
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:

deconstruct60

macrumors G3
Mar 10, 2009
8,897
1,752
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.
....
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.
 

AdamSeen

macrumors regular
Jun 5, 2013
176
137
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.
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?
 

RyanFlynn

Contributor
Nov 24, 2006
292
197
Los Angeles
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!!!
16-core with unbalanced ram hit 478 tracks. I'll get you the 8 core 16 a little later
 

deconstruct60

macrumors G3
Mar 10, 2009
8,897
1,752
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

......

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.
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. ..."

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. ..."

Similar issue measured in 2017 context of that article.
 
Last edited:
  • Like
Reactions: AdamSeen

John_B Beta

macrumors member
Feb 7, 2004
41
29
Maidenhead, UK
16-core with unbalanced ram hit 478 tracks. I'll get you the 8 core 16 a little later
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
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.