To save bandwidth and especially to save repetition, I'm going to reply
to everybody in this one message. I hope that's acceptable.
Adam wrote:
So I guess my question is, why is GIMP only using one core?
I should add that my question would apply to many applications, which is
how everyone interpreted it. I mentioned GIMP because that's the only
app I use where one command may take over a minute to execute, given a
large image and a complicated operation. That's not a major problem,
but this is my first system with a multicore processor and I was curious
why GIMP wasn't taking advantage of the multiple cores.
Chris Knadle wrote:
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. ;-)
I'm not (yet) familiar with multithreading but I learned about reentrant
programs. I thought anything in C was reentrant, because of C's passing
parameters on the stack (and other features designed into the
compiler). Once I implemented quicksort in BAL (S/360 assembler) and it
took some effort to fake reentrancy.
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
If I run 'htop' while GIMP is doing its complicated thing, I can see
that it occasionally switches cores, as whichever single core it's using
is at 100% while the other 3 are very low.
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.
I get the same response from 'ldd', but GIMP still uses only one core at
a time on my system.
Sean Dague wrote:
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?
I took "Concurrent Programming" at Marist around 1990 and I don't
remember it as being more difficult than any other programming course
there. We simulated concurrency under MS-DOS 3.3 by using a programming
language called "Concurrent Euclid" which had a painful compiler, and
our biggest assignment was the ubiquitous "dining philosophers" which
required five concurrent invocations of Philosopher(). Of course things
were much different back then.
I'd be interested in hearing a presentation on concurrent programming on
today's systems, even though I'm not yet up to writing anything complex
enough to benefit from it. (Also, this semester my one course meets
Wed. evening so there are conflicts.)
Thanks again to all for your enlightenment!
Adam
_______________________________________________
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
