I was wondering if there is a simple way to "turn on" all 100% of the CPU so that I can run processes faster (such as python calculations).
1) Is this possible?
2) Is there an easy way to revert back to normal?
3) Is there a way to use less CPU if desired?
I'm thinking of a command line interaction like:
pi@raspberry:~ $ sudo turnOnFourCores python run.py
By default, any computer will try to use all of its cores when it can. However, it can only achieve this when an application is multi-threaded. If it is not (i.e. a Python script that doesn't use the threading module), then it can only use at maximum, one core. This equates to 25% of the CPU on a four-core CPU. If you'd like to modify your script to use multiple cores, you can split your calculation into multiple parts, and multi-thread it as shown in the Python documentation.
As Anon answered, this will fail to work without working with Python's GIL (Global Interpreter Lock). This allows tasks to operate (seemingly) at the same time, but does not allow code to run across multiple cores. If you are using modules written in C (e.g. numpy), they can allow you to use multiple cores go around that limitation. Additionally, if that is not an option, Python offers multiprocessing, which allows you to run any task on multiple cores.
I was wondering if there is a simple way to "turn on" all 100% of the CPU so that I can run processes faster (such as python calculations).
Not in the sense that I think you are implying. This is not an issue specific to the pi, either, it is a logical constraint.
All by themselves computers currently do not have much capacity to determine that a process running as a single thread can instead be run in parallel. Note that at the point when they might have this capacity, there would be no need for computer programmers, because a computer system that could do this might as well write its own code1..
Consider the following simple math expression:
(4 + 2) * 17 / (3 + 6)
There is some potential for this to be calculated in parallel, but it is logically limited. I'd say there's no point in more than two threads, and even then it is mostly only going to be one:
#1 a) 4 + 2 b) 6 * 17 c) 102 / 9
#2 a) 3 + 6
Thread #2 has contributed by calculating 3 + 6 = 9, used in step C by thread #1, saving it one step. But that is as far as parallelism will usefully get here. While thread #2 could calculate 17 / 9 while #1 is doing 6 * 17, doing that would be pointless, because you now have two different paths to the same goal that cannot be recombined. I.e., #2 could keep working:
b) 17 / 9 c) 1.888 * 6
And end up with the same result as thread #1 (11.333), but they have not helped one another beyond step A, therefore having two of them pursue this goal is a waste of time.
(Note that this example is not a literal one; it's intend to demonstrate a logical principle. The scale on which tasks are threaded in user code is much larger, but you don't need a real lesson in multi-threaded programming in order to grasp the idea here.)
Exploiting multiple processors requires code that is written to do it. You cannot simply take anything and say, "oh use all 4 cores and do it faster!". That's not what would happen. Logically, a lot of (..or most) problems and tasks involve steps that cannot happen in parallel, they must happen in sequence.
1. But see Felix Dombek's comment below; I am not an expert on AI. It may also be worth noting that as per Peter Corde's comments, contemporary instruction sets and processors can be exploited by the OS to optimise very finely grained things in a parallel manner, and hardware pipelines do this as well, albeit not across cores (a single core has more than one thing going on, operating on the stream of instructions at various points before their final execution). I was trying to stick to topic of user threads here as I think that is more or less what you are getting at.
add instructions next to each other so they can both run in the same clock cycle. The following multiply and divide rest will be serialized by data dependencies, though, as you point out.
Commented
Nov 22, 2017 at 8:15
No for python.
Other people are suggesting you to look into threading, which is a valid answer for most languages, but they didn't take into the account that you are using python.
The python GIL does not allow you to effectively make use of multiple cores.
Using multiple cores requires explicitly exposing thread-level parallelism to the OS, which usually requires the programmer to write a multi-threaded program. (Or to run a single-threaded program multiple times on different inputs, like compiling with make -j4)
Compilers for some languages support auto-parallelization, though. For example, C or C++ with OpenMP can compile an ordinary for() loop into a program that starts multiple threads.
#pragma omp parallel for
for(int i = 0; i < 1000000; ++i)
{
A[i] = B[i] * constant + C[i];
}
But still, this has to happen when you wrote or compiled the program. There is no way for current hardware and OSes to use multiple cores to speed up a single-threaded program.
Related: How does a single thread run on multiple cores?: answer: they don't. But there are other kinds of parallelism, like Instruction-level parallelism that a single CPU core finds and exploits to run a single thread faster than one instruction at a time.
My answer on that question goes into some of the details of how modern CPUs find and exploit fine-grained instruction-level parallelism. (Mostly focusing on x86). That's just part of how normal CPUs work, by having multiple instructions in flight at once, and isn't something you need to enable specially. (There are performance counters that can let you see how many instructions per clock your CPU managed to run while executing a program, though, or other measures.)
Note that RPi3 uses in-order ARM Cortex-A53 CPU cores. Each core is 2-wide superscalar (2 instructions per clock as ILP allows), but can't reorder instructions to find more instruction-level parallelism and hide latency.
Still, the CPU is pipelined, so the total number of instructions in flight (from fetch and decode all the way to the write-back stage at the end of the pipeline) is significant. When data dependencies don't limit things, there can be 2 instructions in each pipeline stage that the CPU is working on, with a throughput of 2 instructions per clock. (That's what 2-wide means.)
It can't execute instructions out of order, but with careful instruction ordering (usually by a compiler) it can still hide the latency of an instruction that takes multiple cycles for its output to be ready. (e.g. a load even if it hits in cache or a multiply will take multiple cycles, vs. an add being ready the next cycle). The trick is to order the asm instructions so there are multiple independent instructions between the one that produces a result and the one that uses it.
Having software (a compiler) statically schedule instructions is more brittle than having hardware that can reorder internally while preserving the illusion of running in program order. It's very hard for compilers to do as good a job as even a small out-of-order window for reordering instructions because cache-misses are unpredictable, and it's hard to analyze dependency chains across function calls at compile time. And the number of registers is limited without hardware register-renaming.
All of this is small comfort when your code runs slower than you'd like. Sure there's a lot of cool stuff under the hood in a Cortex-A53, but there's more cool stuff under the hood in a Cortex-A57 (like out-of-order execution of up to 3 instructions per clock), and even more in a big x86 CPU like Skylake (not to mention the clock-speed differences).
Cortex-A53 is pretty fantastic compared to a https://en.wikipedia.org/wiki/Classic_RISC_pipeline like original MIPS that you'd learn about in computer-architecture class, but by modern standards it's pretty low-end.
java, not myapp.jar, and it certainly isn't single threaded.
This is not how CPUs work... at all.
As it currently stands, your CPU is perfectly capable of running at 100% usage, assuming that it's not being throttled due to temperature related issues at 80 degrees Celsius or more. That being said, you don't (generally) want to see your CPU pegged at 100%. If you're routinely at 100% CPU utilization, you likely have too much for your processor to handle. This will cause stuttering and a generally unhappy user experience.
To compare with something more physical, your CPU utilization is a lot like a car. The car is likely capable of going 100 mph, but there's a good chance your speedometer reads something significantly under that. When in town, you may never be able to get about 25 mph. That doesn't however change that the car can go 100 mph. You simply haven't pushed on the accelerator hard enough.
If you simply make the RPi do more things (push more on the accelerator), you'll see the CPU utilization figure go up. For example, watch the CPU utilization when you run the command yes in a terminal window (Remember that ctrl+c ends terminal commands). This will increase your CPU by 25% as it maxes out one of your four CPU cores.
The other answers do give good detail, but don't seem to address your question(s) specifically.
N.B :
If you are looking to improve the performance of the pi overall, you might want to look into Overclocking. This allows the CPU run at a faster rate. The downsides are increased heat production, lower lifetime of the processor, and increase power consumption.
If possible I would parameterize the script and execute them in separate Python processes. For example:
cat parameters.txt | xargs -n1 -P4 python run.py
An other alternative is the already mentioned multiprocessing library, which lets you fork-and-join python processes. But that also requires you to have a list of parameters (such as a filename) for which you want calculations to be run.
map but apparently it also has many quite sophisticated shared-memory constructs.
If you want to test your RPI. You can run stress as in here, then you can see how your CPUs are being used with htop. This is useful because you can see if your power source is enough, if it is not enough your RPI will try to use too much current (amperage) and it will shutdown.
On the other hand, if you want to use python scripting, you should see joblib which works great when you want to parallelize processes, and thus you will be using the number of processors you wish.
I think OP might not fully understand the concepts of multi-core/multi-thread programming and how difficult to fully utilize 100% of multi-core unless the algorithm can be easily made into an embarrassingly parallel problem.
For more info, you can read more about the well known article title "The Free Lunch Is Over" http://www.gotw.ca/publications/concurrency-ddj.htm
Although all these answers are right in different ways it is true that the operating system will automatically use the different cores to spread the load. You can see this with a simple python program (temp.py say)
while True:
x = 1.0
open a terminal from your RPi desktop and type $ top which will show processor work. Then open another terminal and python3 temp.py and you will see a python3 job rise to 100% processor time. Then open another terminal and repeat the process and see how you move up to 400%. So at one level as @Shadow commented it is that simple and it is the default. However designing programs that can use the parallel processing is non-trivial as others have explained.
The answer is a resounding YES! You simple have to write your program to recognize them and use them. Programs that do this can use the cores. I write mine to do this in Java and thus I can.
The above answers from Python developers have a very limited concept of this answer and so can be very confusing but the answer is YES and only YES!
Since the OP did not specify python in his question, I would like to suggest two more modern languages that work fine on the Raspberry Pi and have very easy ways to use concurrency.
My current favorite is the Rust language. I have written and compiled programs on the Pi. Rust is nice in that it prevents many types of pointer and race-condition bugs, which makes writing concurrent code both easier and safer. Rust is intended a systems programming language, but it can do pretty much anything C can do.
Another such language is Go (also called Golang to make it easier to search for). Go was created by the Google team, and is a reasonably mature language. It is easy to make coroutines in Go, which they call "Go routines."
Both of these languages can compile code on the Raspberry Pi, even the Pi Zero. However, they can both be cross-compiled from a faster computer which is nice for large programs.
