On 02/03/2013 09:00 AM, Chris Knadle wrote:
On Sunday, February 03, 2013 02:42:36, Adam wrote:
Question about how multicore processors work:
This is an AMD quad-core system. If, for example, I tell GIMP to perform
some complicated operation on a large image, 'top' and 'htop' show me
that one of the cores is running at 100% while the other cores are doing
almost nothing. I gather this isn't any faster than a single-core
processor running at the same speed would be. It would seem to me to get
the operation done more quickly if several cores were handling it.
So I guess my question is, why is GIMP only using one core?
Ed Nisley already answered how to fix this specific instance, but I wanted to
give you a bit of information about your questions below.
Yeh, so the answer from Ed is good for the specific case. However, on
the general case realize most desktop software is really only written
for a single core. Splitting things up is hard.
Does this have anything to do with how GIMP is coded or compiled?
If the designer wants a program to have the ability to use more than one core,
the program needs to be designed to allow it. Specifically it requires the
program to designed to be "multithreaded", and it also generally requires some
functions to be "reentrant".
https://en.wikipedia.org/wiki/Multithreading_(software)
https://en.wikipedia.org/wiki/Multithreading_(computer_architecture)
https://en.wikipedia.org/wiki/Reentrancy_(computing)
I won't try to get into how complicated actually doing this is. ;-)
Is there any way to speed things up by making it use more than one core?
For standard single-threaded programs, I think the answer is "no". However
there's a bit more to this story, because AFAIK a program can end up switching
which core (or processor) it is being run on while it's still running. IIRC
this is one form of "context switching".
https://en.wikipedia.org/wiki/Context_switching
These context switches have some CPU time and I/O costs associated with them.
It isn't discussed much, but there can be a few situations where limiting a
set of processes to /fewer/ cores can end up /reducing/ CPU load because of a
reduction in the number of context switches that occur.
The Linux scheduler is pretty smart here. tasks have stickiness, so
won't tend to move cores unless their current core is overloaded, and
others are long term idle. Basically Linux will load balance over time,
but there is "inertia" baked in.
Or is each process only executed by one of the cores?
Each /thread/ is only executed by one of the cores. If a process is "single-
threaded" then the entire process only runs on one core.
The next logical question you're likely to have is "How can I tell if a
program has been designed to be multi-threaded?" Thankfully I think there's
an answer for that. On Linux systems multi-threading is generally done via
the 'pthread' library -- but the point is that it includes a /library./ You
can use 'ldd' to look for what libraries the program has been built against,
and in the case of the GIMP:
$ ldd /usr/bin/gimp | fgrep thread
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0
(0x00007ffb02ae7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007ffb023ca000)
... that looks like a program designed to be multi-threaded.
Just because you use pthreads, doesn't mean the program will really take
advantage of multiple cores well. Concurrent programming is it's own big
complicated beast, maybe an interesting future talk?
-Sean
--
Sean Dague Mid-Hudson Valley
[email protected] Linux Users Group
http://dague.net http://mhvlug.org
_______________________________________________
Mid-Hudson Valley Linux Users Group http://mhvlug.org
http://mhvlug.org/cgi-bin/mailman/listinfo/mhvlug
Upcoming Meetings (6pm - 8pm) Vassar College
Feb 6 - Raspberry Pi
Mar 6 - 10th Anniversary Meeting - Linux where you least expect it
Apr 3 - Typography: Physical Art to Digital Art
