Chris Knadle wrote:
On Tuesday, February 12, 2013 10:16:08, Adam wrote:
>> 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'll agree, probably possible with /most/ languages, but I'd guess
easier with some than others. I mentioned coding Quicksort (which
involves a recursive function) in BAL (S/360/370/390 assembler) where
AFAIK reentrancy is NOT possible, and I had to fake a stack and
recursion, and even then it was only possible because I knew the maximum
number of items to be sorted and therefore the maximum depth of
recursion. (Actually the instructor said, "Once you've read in the
numbers, sort them using any algorithm you want. I've never seen
Quicksort" so naturally I took that as a challenge.)
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.
>
> Well, whether you get any speed improvement depends on how the
> multi-threading is done.
I think that when GIMP is doing heavy image manipulation (like Van Gogh,
"Special Effects That Nobody Understands"), most operations involve the
results of the preceding operation, so it doesn't sound like the kind of
thing suited for multi-threading.
>> 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
Why is that? Speed of electricity? Heat? That 0.7v drop? And how do
minis/mainframes avoid this limitation?
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.
Well, most of those don't take very long anyway, and I suppose are
IO-bound more than CPU-bound.
I suppose that:
$ grep -R stolid /etc /usr
could be split into two threads by the user:
$ grep -R stolid /etc &
$ grep -R stolid /usr &
but my guess is that all the head movement (on a conventional HD) would
cancel out much of the gain of the "multithreading".
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
