On Saturday, February 16, 2013 14:56:33, Adam wrote: > 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.)
Yes, some languages (and architectures) have limits on the depth of recursion. In the case you mention for BAL (S/360/370/390 assembly), I'm guessing that there was no CPU instruction available for PUSH and POP, and that the way you "faked" it was via indirect memory addressing and updating a "variable" (a memory location) to contain the current "pointer" into the indirect-addressed memory. Recrusion is usually limited to certain kinds of jobs that naturally lend themselves to recrusive solutions. For instance -- solving an NxN matrix determinant -- that's something that lends itself to a recursive solution, because any NxN matrix determinant can be broken down into 2x2 determinants. [This is a fun exercise.] However... the type of recrusion we've been discussing so far have been single threaded. The reason I brought up recrusion was to discuss issues with writing reentrant functions, which is easier to discuss conceptually in the context of recrusion than it is in multi-threading. > >> 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. That sounds right. > >> 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? Both and then some. Bottom line: limitations of known physics. To try to deal with the heat issue, voltages that the processors use have been incrementally lowered. Many CPUs these days run on ~1.25v. (I think this is considered LVCMOS.) This gets into limitations on the voltage thresholds for what a "1" and a "0" are. > That 0.7v drop? More like 0.2v - 0.5v these days, but yes. > And how do minis/mainframes avoid this limitation? They don't AFAIK -- but there are people on this list with much more experince in this area than I have. Today's CPU speed limits that I know of (for a single core) are around 4 GHz, and around 5 GHz for CPUs that are cryogenically cooled. The acutal "results" you get from different CPUs differs depending on the architecture though. There have been various tricks used over the years to get more out of the CPU without increasing the clock rate. Instruction sets (CISC vs RISC), instruction pre-fetching and branch anticipation, pipelining, etc. > > 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. Right, depends on the type of program/load. > 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". Assuming /etc and /usr are on the same disk, then probably yes. How well that would perform gets into filesystem implementation details. -- 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
