CPU IPC and Clock Speed: How to Properly Compare Hosting Processors

CPU IPC: Instructions Per Cycle

CPU IPC stands for Instructions per Cycle, that is, instructions per clock cycle. For a defined measurement range, the number of completed machine instructions is typically divided by the number of CPU cycles counted within that same range. In this context, an IPC of 2 means an average of two completed instructions per counted cycle.

The value is a Design Feature, not a fixed metric for all of a processor's tasks. The same system can achieve a different IPC when performing a calculation with readily available data than when executing a database query, which often has to wait for data from main memory. The specific data set and the section of the program under consideration also affect the result.

A cache keeps frequently accessed data close to the CPU. If a core must instead wait for slower memory accesses, execution units may remain idle at times. Similarly, dependencies between instructions and branches in the program flow affect how much work can be executed simultaneously. A low IPC is therefore a reason for further investigation, but it is not yet a definitive diagnosis.

Furthermore, a machine instruction is not a standardized unit for a completed web request. Compilers, instruction sets, and vectorization can cause different programs to require different numbers of instructions for the same task. A higher IPC alone therefore does not prove either a shorter response time or more requests per second.

When making a comparison, it is crucial to know the specific application and measurement range behind the value. An IPC figure without this information leaves it unclear whether the systems are even performing the same tasks. You can find more information on the interplay between clock speed, cores, and memory hierarchy in the article on CPU Architecture in Web Hosting.

Understanding Server Clock Speed and Boost

The clock frequency describes how many cycles a CPU completes per second. One gigahertz, or GHz for short, equals one billion cycles per second. On its own, this value does not indicate how many instructions a program executes during these cycles or how much useful work it accomplishes as a result.

Data sheets often include a Fundamental frequency and a maximum boost. The base frequency serves as a specification value; the boost refers to a higher possible frequency under suitable conditions. Neither of these values replaces monitoring the actual clock speed achieved during specific use and under the respective load.

One example is the AMD EPYC 9655: For this model, AMD specifies 96 cores, 192 threads, a base clock speed of 2.6 GHz, and a maximum boost of up to 4.5 GHz. These values describe the processor’s configuration and frequency specifications. They are neither a measured IPC nor evidence of a specific hosting throughput.

For the EPYC 9005 series, AMD defines the maximum boost as the highest frequency a single core can reach under normal server operating conditions. The 9655's "up to 4.5 GHz" specification therefore does not guarantee that all 96 cores will maintain this clock speed continuously. Power and temperature limits affect performance under load.

For a short, one-off task, a temporarily higher clock speed may be relevant; in contrast, for a sustained parallel load, it is more important to consider the performance the system delivers over the entire runtime. Other models in the series have different frequencies and core counts. A comparison based solely on the highest GHz value would overlook these differences and the specific application.

Cores, Threads, and Virtual CPUs

In simple terms, a process is a running program instance. Within it, one or more threads execute instructions. A physical CPU core contains the hardware required to perform such work; depending on the processor, operating systems recognize one or more logical CPU threads per core. Logical threads on the same core share portions of its hardware.

A task with a heavily sequential section cannot distribute that part arbitrarily across many cores. In that case, what matters is how quickly the executing thread completes the actual work. Independent web requests, on the other hand, can often be processed in parallel: In such cases, additional available cores can boost overall throughput, provided that other resources do not impose limitations.

The number of logical threads is not the same as the number of independent physical cores. For example, according to the manufacturer, the EPYC 9655 has 96 physical cores and 192 threads. The 192 threads do not imply a doubling of performance compared to 96 threads, nor do they guarantee a specific throughput for a web server.

With a virtual server, the provider provides the guest operating system vCPUs Ready. A vCPU is not automatically an exclusively usable physical core: Its mapping to the host hardware may vary depending on the plan, and processing time may be shared with other guests or limited by quotas.

Question to ask before making a selection regarding specific resource commitments: Is CPU time guaranteed, or is it shared? Are there permanent performance limits, and how are vCPUs allocated? A high number of vCPUs only helps a parallel application to the extent that sufficient computing time is actually available; for a serial section, it is no substitute for fast execution on a single thread.

Calculating IPC and Clock Speed Together

IPC and clock frequency describe different aspects of CPU performance. For a suitably defined measurement range, their effects can be approximately combined: Instructions per second correspond to the IPC multiplied by the effective CPU cycles per second. Here, the IPC refers to the completed instructions and the counted cycles within the same time frame.

Illustrative calculation, not a measurement: Assuming a constant 2.0 instructions per cycle and 3.0 GHz, the calculation yields 6.0 billion instructions per second. Even 1.5 IPC at 4.0 GHz results in 6.0 billion. In this example, the higher clock speed thus compensates for the lower IPC in the calculation.

However, the same instruction rates do not mean that both systems process the same number of web requests. For the same task, programs may require different numbers of instructions depending on the compiler, instruction set, and commands used. An instruction therefore does not represent a uniform amount of application work completed.

A website's response time also cannot be directly determined from this metric. A thread may be waiting for data from storage or for a network response; during that time, its instruction rate does not account for the entire elapsed time. In the case of a virtual machine, there is the additional factor that it does not necessarily receive CPU time at all times.

To make a comparison, it must therefore be clear which code and which time period were included. The formula helps to classify active execution; for the hosting decision, completed tasks and their response times under a comparable request profile are also required.

Classify Data Sheets and Key Figures

A data sheet provides useful guidance for selecting a hosting CPU. However, the information answers different questions: IPC describes performance within the respective measurement range, while frequency specifications and core counts specify the characteristics of a processor model. Only when considered in conjunction with the application do these become useful comparison criteria.

The EPYC 9655 illustrates how these specifications fit together: According to AMD, the model has 96 cores and 192 threads, a base clock speed of 2.6 GHz, and a maximum boost of up to 4.5 GHz. The 4.5 GHz is not a guaranteed clock speed for all cores under sustained load, nor is it a measured hosting throughput.

A ranking based on maximum GHz would obscure how much work different processors can handle per cycle and per task. A ranking based on the number of cores, on the other hand, overlooks the fact that not every application can distribute its workload equally well in parallel. Both metrics are starting points, not definitive assessments of performance.

When looking at offers, be sure to pay attention to the Model variant and on which resources are actually available. For a reliable comparison, you also need an appropriate load profile and results from comparable software and configurations. The specifications of different models should not be conflated with a maximum value assumed for the entire product family.

Select a Hosting CPU Based on Load Profile

Which CPU is suitable for hosting depends on what the server is expected to do. A single, long-running task has different requirements than many independent web requests. The table translates typical load profiles into a key metric and a question that should be clarified before making a selection.

For a single task, the performance of the executing thread is particularly important if a significant portion of the work is performed serially. More cores do not automatically reduce the duration of this portion. A brief peak performance boost is also insufficient evidence for a long-running task: what matters is its measured runtime under the specified conditions.

In contrast, many independent requests can be processed in parallel. In this case, in addition to performance per thread, what matters is how many resources are available simultaneously and how response times change as the load increases. The sum of nominal GHz figures is no substitute for a comparison of the Total throughput with the same degree of parallelism.

In a database with a large working dataset, memory accesses can slow down execution if the required data is not efficiently retrieved from the caches. A low IPC may warrant further investigation, but it does not by itself prove a memory bottleneck. Therefore, also check the queries, the data set, and the memory configuration before replacing the CPU.

With a VPS, there is also the Commitment of Resources Important: A vCPU is not automatically an exclusive physical core. Consider allocation, possible CPU limits, and sharing with other guests. Only with this information can an application test be meaningfully compared to an offering on a dedicated server.

Plan comparable application tests

A meaningful comparison starts with your application, not with an isolated CPU number. Set the same software version, the same dataset, and the same configuration for both hosting plans. SPEC describes running your own application on your own infrastructure as the ideal benchmark for product selection.

Next, define a Inquiry Profile, which accurately reflects actual usage as much as possible: for example, which pages or API endpoints are accessed and how many requests arrive simultaneously. Keep concurrency and resource limits consistent across runs. If a service specifies different limits, document them explicitly rather than attributing the difference solely to the CPU.

Plan for a warm-up phase so that, for example, the application has started and caches have had time to fill up. After that, running the test several times for a sufficiently long duration will help distinguish short-term fluctuations from recurring differences. Also document whether any other tasks were running on the systems during the measurement.

In addition to throughput, record the Response Time Distribution and the errors. A higher average number of completed requests per second is of little use on its own if individual requests take a very long time or fail frequently. Therefore, also compare high percentiles of response time at the same level of parallelism.

Published SPEC CPU 2017 results can provide additional guidance. SPECspeed measures the time required to complete tasks, while SPECrate measures throughput; the two metrics are not directly interchangeable. Compare results using the same metric, and take system configuration and software into account. The CPU suite does not reflect the network and I/O components of a complete hosting service.

Check the IPC and frequency during operation

To create your own Linux test environment, you can use `perf` to capture the completed instructions and cycles of an existing, tested program. In the following example, testprogramm A placeholder: Replace it with your test program and, if applicable, its arguments. The command is a suggested test; it is not a test that has already been run.

perf stat -e '{instructions,cycles}' -- testprogramm

The curly brackets group the events into a Meter Group together. They should be captured simultaneously, which can reduce errors caused by time-shifted multiplexing. Divide the number of instructions counted by the number of cycles counted to obtain the IPC for this measurement range; perf can also output this value directly.

Whether events are available and can be read depends on the hardware, kernel, permissions, and, if applicable, the virtualization environment. An event group that is unavailable or cannot be aggregated does not provide a reliable comparison. Do not change security settings solely for the purpose of this example.

Even a frequency display requires context: scaling_cur_freq According to the kernel documentation, this value often corresponds to the last state requested by the driver and not necessarily to the actual hardware clock speed. This value is not available everywhere cpuinfo_cur_freq On the other hand, it should display the current frequency as determined by the hardware. More on CPU Governors on Hosting Servers explains how frequency scaling is controlled.

A low IPC is an indication that further investigation is needed, but it is not a definitive diagnosis. Memory accesses can slow down execution; you must also check which part of the program was measured and whether other factors are at play. Therefore, compare the counter value with the application's behavior and its data access patterns.

Identify Bottlenecks and Decide on an Upgrade

Start with a specific symptom: Do requests slow down under load, does the error rate increase, or does a single task take too long? Note when the problem occurs and what other tasks are running at the same time. Only then can you determine whether more CPU power can actually reduce the delay in question.

First, check the available and used CPU time. A task that is consistently computationally intensive can benefit from faster execution or greater usable parallelism. However, high utilization alone does not explain which code is causing it, nor whether the response time is primarily driven by that code. Therefore, compare this finding with the throughput and response times for the same load phase.

Next, examine memory requirements and data accesses. If a database frequently needs to access data outside the CPU cache, it may have to wait for memory; a low IPC may indicate this, but does not prove the cause. Limited RAM, disk accesses, or slow external services can also contribute to the observed delay.

With a VPS, the Commitment of Resources Regarding the diagnosis: Inquire about the allocation of vCPUs, possible CPU limits, and resource sharing with other guests. A dedicated server offers a different allocation of physical resources, but even there, the application, configuration, and load profile determine the outcome. If possible, compare both offerings using the same application test.

Consider upgrading your CPU if the measurements indicate a CPU bottleneck and the new plan actually provides the required processing time. If the delay is primarily due to memory, storage, or an external service, it makes more sense to investigate those areas further. Record the initial state so that you can evaluate any subsequent changes in a comparable manner.

Do not interpret maximum boost specifications as a guaranteed sustained clock speed for all cores, nor should an IPC value be viewed as a universal characteristic of the CPU. Similarly, a single utilization figure is not sufficient for a complete bottleneck diagnosis. The decision is based on the specific task and the resources actually available, not on a single peak metric.