#GAME DEBATE COMPARE CPU DRIVER#
#GAME DEBATE COMPARE CPU ANDROID#
#GAME DEBATE COMPARE CPU PC#

For readabilityвЂ™s sake in this article, I chose an effective ~200ms sample periodВ (Due to overhead on scripting and time-keeping mechanisms, this is just a rough target)В which should give enough resolution for a good graphical representation of the CPUвЂ™s frequency behaviour. The X-axis represents the distribution in time, always depending on the scenarioвЂ™s length.

The Y-axis of the graph is a stacked percentage of each CPUвЂ™s frequency state. What we end up is a stacked time distribution graph such as this: So by calculating the deltas between each readout, we end up with an accurate frequency distribution within the period between our readouts.

#GAME DEBATE COMPARE CPU DRIVER#

The time-in-state statistics are always accurate because they are incremented by the kernel driver asynchronously at each frequency change.

#GAME DEBATE COMPARE CPU ANDROID#

Since Android devices run on the Linux kernel, we have easy access to this statistic provided by the CPUFreq framework. Instead of going the route of logging the discrete frequency at a very high rate, we can do something far more accurate: Log the cumulative residency time for each frequency on each readout. What happens in-between though is not captured, and due to the switching speed being so high, we can miss out on 90%+ of the true frequency behaviour of the CPU. Frequency at both these readouts would be either at a high or low frequency.

Take aВ given sample rate of 1s: Imagine that we read frequency out at 0.1s and 1.1s in time. For example this can happen in periodic short high bursts. Sampling at anything under half the DVFS switching speeds can lead to inaccurate data. Mobile SoCs now can switch frequency at intervals of down to 10-20ms, and even have unpredictable finer-grained switches which can be caused by QoS (Quality of Service) requests. To be able to accurately get a good representation of the frequency one would need to have a sample rate of at least twice as fast as the CPUвЂ™s DVFS mechanism. The issue with this is the way one captures the frequency: the readout sample will always be a single discrete value at a given point in time. Usually this gives a rough idea to see if there is some load on the CPU and when it kicks into high gear. Traditionally when wanting to log what the CPU is doing, most users would think of looking at the frequency which it is currently running at. As such, any comparisons between such SoCsВ should be limited toВ purely to theoretical scenarios where a givenВ CPU configuration would be running Android.

I should start with a disclaimer that because the tools required for such an analysis rely heavily on the Linux kernel, that this analysis is constrained to the behaviour of Android devices and doesn't necessarily represent the behaviour of devices on other operating systems, in particular Apple's iOS. To try to finally have a proper analysis of the situation, for this article, IвЂ™ve tried to approach this issue from the ground up in an orderly and correct manner, and not relying on any third-party tools. The existing tools for monitoring CPUs just donвЂ™t cut it when it comes to accurately analysing the fine-grained events that dictate the management of multi-core and heterogeneous CPUs. While there have been some attempts to analyse the core-count debate, I was never really satisfied with the methodology and results of these pieces. I can draw parallels between those discussions from a few years ago and todayвЂ™s arguments about 6 to 10-core SoCs based on big.LITTLE. I can still remember when the first quad-cores were introduced that users were arguing the benefit of 4 cores in mobile workloads and that these increases were just done for the sake of marketing. This increasing of CPU cores brought up many discussions about just how much sense such designs make in real-world usages. While ILP (Instruction-level parallelism) has certainly also gone up with each new processor architecture, with designs such as ARMвЂ™s Cortex A15 or AppleвЂ™s Cyclone processor cores brining significant single-threaded performance boosts, itвЂ™s the increase of CPU cores that has brought the most simple way of increasing overall computing power.

#GAME DEBATE COMPARE CPU PC#

This was a natural evolution similar to what the PC space has seen in the last decade, but only in a much more accelerated pace. The industry has seen a move from single-core to dual-core to quad-core processors to todayвЂ™s heterogeneous 6-10 core designs. Over the last 5 years the mobile space has seen a dramatic change in terms of performance of smartphone and tablet SoCs.

Game debate compare cpu