Why does a server CPU perform faster tasks than a Macbook Pro CPU with the same benchmark score? [closed]

Question

Given the following CPUs and GeekBench scores:

• Amazon EC2 z1d.large instance: Intel Xeon Platinum 8151 4061 MHz (1 cores) Single-Core Score: 1094, Multi-core score: 1300

• Macbook Pro Laptop: Intel Core i5-8259U 2300 MHz (4 cores) Single-Core Score: 1002, Multi-core score : 4104

The Xeon is 9.1% faster in the single-threaded benchmark score.

However, when I compile javascript application code (single-threaded) on both devices, the Xeon completes the task 60% faster. Why? The benchmark score says the Xeon is only 9% faster.

They both have NVME drives, so that shouldn't be the bottleneck. I don't think there'd be a Mac vs Linux OS issue either, since Mac is linux based.

Is this because the Xeon is a server/desktop CPU? and running at 100% speed and power, whereas the Macbook Pro CPU is not running at full power and has to wait for the Intel Turbo Boost to ramp up?

Answer 1

Given the task you describe, compiling a Bable project, and the CPUs involved I think I know the source of the difference in performance. I wanted to answer earlier but had to do a bit of research to confirm my hunch.

First, let's characterize the load you're putting on your system.

Babel.js is written as a single-threaded, single process compiler that mostly leverages asynchronous I/O for parallelism (at least nothing I've googled indicates it using worker threads). Since it is a compiler that compiles files from disk a large part of its execution involves waiting for data from disk. This gives us the following workload:

1. Single-threaded so multiple cores or hyperthreading have no significant effect on compilation with one caveat:

2. Node.js uses worker threads to handle disk I/O but beyond a two or four hardware threads there is no additional advantages to multiple cores (see: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/)

3. Most of the parallelism takes place at the I/O level. Babel will try to read as many files in parallel as possible.

Both the i5 and the Xeon are fairly comparable with regards to points 1 and 2. So let's look at how the CPU can handle point 3: servicing Babel's parallel file read request.

Here's the first big difference between the two systems:

• The Core i5 8259 has 16 PCI lanes

• The Xeon 8151 has 48 PCI lanes

So clearly the Xeon can handle more parallel I/O operations than the i5. When there's more I/O than the number of memory transfer lanes available the OS handles it the same way as when there's more tasks than number of hardware threads available: it queues them up and force them to take turns.

Next I wanted to know if NVME can actually use multiple lanes. This is where I hit another interesting fact. The NVME standard allows a card to use up to 4 PCI lanes (there is physically that many connections allocated) but some cards use only 2 while others use 4. So not all NVME cards are created equal. This alone will give you double the number of files Babel can copy to RAM in parallel at almost double the bandwidth.

It also depends how the NVME slot is connected to the CPU. The Core i5 having only 16 PCI lanes will no doubt be reserving at least 8 of them for the GPU. Leaving you only 8 to be shared among other devices. This means that sometimes your NVME card will have to share bandwidth with your Wifi or other hardware. This slows it down a bit more.

And your NVME may not even be connected directly to your CPU's PCI lanes. The Macbook may actually reserve all 16 lanes for the GPU and connect to your NVME via its south bridge (which may have additional PCI lanes). I don't know if the Macbook does this but this again may reduce performance a bit more.

In contrast, the large number of lanes that the Xeon has allow the motherboard designer much more freedom to create a really fast I/O platform. In addition the AWS server does not normally have a GPU installed so it does not need to reserve any lanes for GPU use. Again, I don't personally know the actual architecture of AWS servers but it's possible to create one that outperform a Macbook at compiling Babel projects.

So in the end the main factors that enables the EC2 instance to outperform the Macbook are:

1. Number of PCI lanes directly supported by the CPU

2. Number of PCI lanes supported by the NVME drive

3. How the NVME lanes are connected to the CPU

Additional factors that may contribute include:

1. The speed of the I/O bus (PCI2 vs PCI3 etc)

2. The speed of RAM

3. Number of DMA channels available (this alone requires a long answer so I sort of skipped it but the reasoning is similar to PCI lanes)

Answer 2

Benchmarks are vague handwaves to some very specific performance characteristics (peak instruction rate) that often do not take into account other factors in a system.

A non-exhaustive list of things that can make a big difference to programs but not peak instruction rates:

• Memory. Type, bandwidth, channels. These all make a difference in how fast data can get to the CPU for it to do work. Servers typically have more channels of RAM, higher quantities and much higher peak bandwidth figures than desktop or laptop CPUs. Having a high single core instruction rate wins you nothing if you can't get data to the CPU fast enough to hit that rate.
  As a simple check I had a look and the 8180 Xeon (closest I could find) has 6 memory channels, while your laptop CPU would (hopefully) have 2 channels set up (or could have been poorly designed and only have one). The server has 3 times the memory bandwidth of your laptop. That will make a massive difference for memory intensive tasks.
• Hard disk. Faster hard disks, SDDs and so on can make a big difference in getting data to the memory for the CPU to work on. An SSD is orders of magnitude faster seeking for small bits of data, and bulk transfer is also much higher too. NVMe is even faster again. Servers often use RAID for backup or can be set up for raw speed. While they may both be NVMe a server farm may well have enterprise class disks in a RAID 0 or 01 and be faster than your single disk, particularly likely on shared machines where minimal impact across VMs is desirable.
• Thermal limiting. Benchmarks, especially on laptops and ultra-portable machines, only tend to last long enough to see the initial ramp-up of performance. Over time heat reservoirs become full as fans can't keep up with heat output, and that initial turbo-boost speed drops down to the "normal" peak clock frequency. This can skew benchmark results and make a laptop look a lot better than it will perform under long term loads. Servers tend to have over-specified (and loud) cooling systems to ensure performance, laptops are designed for quiet home comfort and the fans are far less powerful. What you see in a benchmark may not have the same thermal limiting as what you have in front of you, yours may not perform as well and may limit sooner.
• Bottlenecks. Servers will have far more I/Os than laptops. More PCIe channels, more dedicated IO ports and much higher bandwidth to peripherals meaning more data in flight down uncontested paths. Multiple PCIe devices contending for time on a multiplexer connected to a 16-lane CPU will be slower than a CPU which has 40+ dedicated lanes.
• Cores. Having more cores makes a difference to not only the task you are doing on one core, but means that the tasks are not fighting for time. The tradeoff is that is is easier to hit memory bandwidth limits with more cores vying for bus time.
• Caches. Server CPUs tend to have much larger CPU caches. While this is more of an optimisation, larger caches do mean less time going to memory and allow the CPU to hit their peak performance more than a smaller cache. A single core benchmark is probably small enough to fit in most cache sizes and so tells you nothing about the rest of the system.
• Graphics. Related to PCIe/memory bus contention, your laptop will be doing graphics work, most likely with an iGPU. That means your system memory is being used (and memory bandwidth stolen) in order to drive a graphical display. The server would likely have none of that, most likely being a headless node in a compute cluster. The server has far less graphical overhead.

Consumer class CPUs are indeed powerful, but server class has far more logic, control and bandwidth to the wider system. Generally though, that is fine. We don't expect a 15 watt processor to perform the same as a 10x more expensive CPU with a 140 watt power budget. That extra power budget gives a lot more freedom.

If server CPUs had the same performance as a desktop or laptop CPU, then there wouldn't be a distinction between the two.

Just to further nail home the point: a similar single core score just tells you that the cores are reasonably comparable under ideal conditions. They may be theoretically close in terms of performance, but it doesn't tell you anything about the wider system and what the CPU is capable of when tied to other components. Single core speed is artificially focused on one small point in the system, more so than most normal uses of a system will encounter.

For more information on why one system is "better" than another you need to look more at so-called "real world" benchmarks, which will show (still artificial but) more comparable system performance metrics and hopefully give some idea where bottlenecks might lie. Better yet you do the kind of test you did which shows that for that workload a server class system, with it's underlying architecture and components, is much better.

Answer 3

Adding to Mokubai's excellent answer:

• Instruction Set Extensions. Some extensions, such as AVX-512, are available in server processors (such as the SKX processor mentioned in the question) but not (or only later) in consumer processors. The Coffee Lake consumer CPU from the question, for example, does not support AVX-512. I don't think that compilers are too heavily affected by this, but if you were to execute certain numeric tasks, including scientific computation or machine learning, this could cause a difference.

• Core interconnects. Not relevant for single-threaded tasks, but when multiple cores are used, the type of interconnect has an influence on the "speed" with which cores can talk to each other. While the consumer processor uses a ring interconnect, the server processor is the first to use a mesh interconnect.

Answer 4

Intel Xeon Platinum 8151 Specs From Intel Corporation

Intel i5-8259U Specs From Intel Corporation

• It appears the Xeon has 38.5 MB L3 Cache
• It appears the Intel Core i5-8259U has only has 6 MB Intel® Smart Cache

A processor cache is where a processor stores recently written or read values instead of relying on main system memory.

• Caches are designed in all sorts of shapes and sizes, but have several classic characteristics that make them easy to exploit. Caches typically have a low set associativity, and make use of bank selectors. Associative Caches
• Inside a typical processor cache, a given physical (or logical depending on the design) address has to map to a location within the cache. They typically work with units of memory known as cache lines, which range in size from small 16-byte lines to more typical 64- and even 128-byte lines.
• If two source addresses (or cache lines) map to the same cache address, one of them has to be evicted from the cache.
• The eviction means that the lost source address must be fetched from memory the next time it is used. In a fully associated cache (also known as a completely associated memory or CAM), a source address can map anywhere inside the cache. This yields a high cache hit rate as evictions occur less frequently.
• This type of cache is expensive (in terms of die space) and slower to implement. Raising the latency of a cache hit is usually not worth the minor savings in the cache miss penalties you would have otherwise... You can read more here

DDR4 at higher bus rate also helps increase speed. Not too mention that the Xeon has Transactional Synchronization Extensions whereas the i5 does not.

They are not in the same class of processor, but hopefully the information above helps you, and the links from intel corporation assist in the validity of my responses.

Answer 5

In addition to the other answers, I would add that instructions used in any given benchmark may not match the instructions used in your compiler. Basically, each processor may be faster at certain types of instructions, or one may be better-performing than the other in certain scenarios, for example, branch prediction failure.

The code of one is not guaranteed to be a predictor of the the performance of the other code. That's because they do different things, in different ways.

You could, for example, have a late-model Core2 processor like a Q9550, overclocked by 33% (quite doable), and it might match or exceed a lower-clocked 2nd gen i5 processor for many tasks, despite the latter being more recent.

But if you have a sequence of code which involves a lot of branching instructions with a high degree of randomness, likely the i5 would outperform the Core2 many times over due to the Core2 processor's poor performance in the event of a branch prediction failure.

This sort of thing occurs at all sorts of micro-levels, for all sorts of instructions and processing types. That's why one CPU might be better in a Cinebench benchmark (video encoding), but worse in a SunSpider benchmark (javascript).

Answer 6

You just invented one more benchmark - "building this particular project". And the build environment in Amazon is way better than your Mac AT THIS PARTICULAR BENCHMARK.

CPUs (and storage devices, and computers as a whole, and operating systems, and building environments) are not created equal. CPUs are made to fit in different constraints regarding available power, cooling, space, cost and available technology. So are all other components of your setup.

I wouldn't expect much difference because of the different OS (Linux, Mac OS or even Windows) or the underlying storage system because build tasks are CPU- and memory-intensive and don't load much of the filesystem or the process scheduler. Then again, I may be wrong because building a JS project may be different compared to C and Java projects I am familiar with.

The build tools in Linux and Mac OS can differ considerably in performance. They may be themselves built with different compilers, libraries, optimization options, etc and these may bring the whole difference that you see.

Answer 7

They both have NVME drives, so that shouldn't be the bottleneck. I don't think there'd be a Mac vs Linux OS issue either, since Mac is linux based.

Please backup that claim. MacOSX is indeed a Unix-like OS, with probably a lot of kernel code from BSD or SVR4 (Unix in the 1990s). But Unix predate Linux by more than two decades. Read the history of Linux (born in and the history of Unix. BTW, I used SunOS3.2 in 1987. The first Linux kernel was released in 1991. I used Linux in late 1993 (kernel 0.99.12) on a i486 PC.

But Linux has (in kernel land) AFAIK, few source code from that era.

Of course, both MacOSX and GNU/Linux can have some GNU software running (notably GNU bash).

At last 9% is within the noise margin. Did you consider, for example, recompile all your Linux distribution from its source code by systematically passing gcc -O3 -mtune-native -flto both at compile and at link time and using the latest GCC? You could try using some source Linux distribution like Gentoo and/or follow the LinuxFromScratch guidelines.

BTW, a server computer costs more US$ or € than your MacBook Pro. Look at DELL prices for them. I would expect more performance from the server. For exemple, server processors have more CPU cache and more cores, and that does make a difference. A typical server processor costs more than your entire MacBook Pro. For example, AND Ryzen Threadripper 2990WX costs 1 758€ in France, and you need to buy a motherboard, a watercooling, plenty of RAM, etc... The same reseller is selling an i5-8279U MAcBook Pro for 1 989€. The price tag of Dell PowerEdge R6525 Rack Server starts at US$ $2,689.00 (no idea if shipping is included).

You should run several benchmarks.

Such as SPEC benchmarks (they cost a few thousand US$). Or OpenBenchmarking. And run all of them -and more than once- on both laptop and server. Collectively they exercise different parts of your computers, and only then you have a better assessment of their performance.