Not logged in. Login

Timing Code

CPU Frequency

Modern CPUs don't run at full speed all the time, to save power (which is good). This can make timing code difficult because some tests might occur in a lower-power mode than others, thus timings may not be comparable (which is bad).

Command Line

On a Linux system where you have admin privileges, you can set all CPU cores to "performance" with this command, before running any timing tests:

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

You can restore the "power save when appropriate" behaviour by returning to the (almost certainly default) "ondemand" governor:

echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

GUI

If you don't have admin privileges, there may be a GUI way to set the CPU governor. On Ubuntu, you can click the system menu in the upper-right of the screen, the power profile icon, and select "performance" before speed tests, and restore "balanced" after.

Thermal Throttling

Modern CPUs (especially in laptops) aren't always capable of running at full power for very long: they can't cool fast enough and must enter a lower-power mode to prevent damage. This is known as thermal throttling.

The result: you get "full speed" for a little while, and then a slower steady state. On a desktop computer, the CPU shouldn't throttle. On laptops, you might get only 10–30 seconds of full-speed CPU before throttling.

The result: longer CPU speed tests should probably be done on a desktop computer.

Limiting Memory

If you are testing something that may use a lot of memory, it may be wise to limit the allocation allowed to whatever command you run, so you don't completely run out of memory (which can cause your computer to slow down enough that a hard reboot is the most practical solution).

This command will limit any future commands in this shell to 4GB of total memory:

ulimit -v 4194304
Updated Mon April 15 2024, 10:42 by ggbaker.