On Tuesday, February 12, 2013 10:16:08, Adam wrote: > Chris Knadle wrote: > > On Monday, February 04, 2013 22:21:11, Adam wrote: > >> 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. > > Okay, I see. So then one can design C functions to be reentrant by > avoiding non-dynamic local variables (and a few other structures... or > it's easier to write reentrant code in C than in some other languages.)
I don't know what languages are easier or harder to write reentrant code for. My initial guess would be that reentrant functions is possible to do with most languages. > >> 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". > > So having multiple cores won't make GIMP run any faster, but it does > mean I can run both GIMP and another CPU-intensive program and both will > run nearly as fast as if they were the only program running. > > BTW I'm not complaining about GIMP, just curious. When I'm manipulating > large images (which isn't often), the quality of the result is much more > important than the speed. Well, whether you get any speed improvement depends on how the multi-threading is done. One method of multi-threading is to offload a job to a thread (or process) and then WAIT for the job to complete. If multiple such jobs can be done "in the background", then on a multi-core machine this can lead to a speed improvement, but if this is done only for one job then in effect the main program is simply waiting for a single thread to complete which results in not much speed improvement. This also depends on the kernel's scheduler; for instance if the schedule can completely dedicate a CPU intensive job thread to one core, then the other core can be used for normal operating system functions that would normally require interrupting the CPU intensive job to do, so you'll get /some/ speed improvement that way. I'm no expert in this area -- I mainly know the basic concepts, and only a small bit about how to do some very basic threading in C/C++ via locks, and even that was just some basic test examples just for learning purposes and not "real-world" application. > >> our biggest assignment was the ubiquitous "dining philosophers" which > >> required five concurrent invocations of Philosopher(). > > > > 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 > > Yep, that's the one. I'm sure you can see why it would be appropriate > for a class in concurrent programming. I don't see the "solution" we > were told to use on that page, though -- one of the philosophers starts > off by looking in the opposite direction from the others. For example, > start by trying to get the fork on the right, unless it's philosopher #2 > who starts by trying to get the fork on the left. > > Any guesses, anybody, on whether some future programs are going to be > written to take advantage of multiple cores? Speculation is heavy in this area, because we've essentially hit a speed limit on CPUs such that the only way to get faster processing is via additional cores rather than faster cores. Video games in particular are an area that have to take advantage of multi-core processing because 3D games are continuing to get bigger and need more processing power, but CPU speeds are not. Thankfully there are things that can generally be threaded there -- video rendering, video pre-processing, data retrieval, user input, etc, but that also comes with many issues to handle. On the other-end are the typical command-line utilities, and there most programs (such as grep) are single-threaded and are likely to remain that way. -- 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
