On Monday, February 04, 2013 22:21:11, Adam wrote: ... > 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).
No, C is not automatically reentrant. The issue is that functions can have local variables; non-dynamic local variables have memory locations that are chosen at compile time rather than at run time . In that case a second concurrent call to the same function will corrupt the local variables. The following example illustrates this problem (but doesn't explain it well): https://en.wikipedia.org/wiki/Reentrancy_(computing)#Example You could likely come up with an example single-threaded /recusive/ function (one that calls itself) that uses standard non-dynamic local variables to test this. In reading the reentrancy page on Wikipedia I also note that there's a difference between a function that is reentrant vs one that is "thread safe"; the latter is even more strict. > >> 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. Yes... that's not surprisng. > >> 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. This goes back to what Sean had mentioned, concerning applications not being able to take advantage of multiple cores well. i.e. "possible" != "great". > 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. This is the first I've heard of the "Dining Philosophers" problem, but I found a reference to it: https://en.wikipedia.org/wiki/Dining_philosophers_problem -- Chris -- Chris Knadle [email protected] _______________________________________________ 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
