Re^2: [OT]: threading recursive subroutines.

[BrowserUk]

Once again, you offer a few authoritative sounding 'wisdoms' in place of 'an answer'.

And as usual, on close inspection, they not only are of no value in terms of answering the question asked; they are in large part fundamentally incorrect.

1. Threading buys you only two things:

   This belies even the crudest understanding of threads. For example, you completely omit the following "buys" of threading:

   • substantially cheaper context spawning.
   • substantially cheaper context switching.
   • the avoidance of kernel mode switching for state sharing.
   • others.
2. but it does not alter the fact that I/O is usually the physically limiting determinant of throughput

   So, in your experience, there are no applications where a short burst of IO results in a large volume of cpu intensive computation?

3. It allows you the potential opportunity to utilize multiple CPUs and/or cores, if they exist.

   You've failed to notice that?:

   • Even the cheapest commodity box you can buy now has multiple cores.

     They're already turning up in high-end smart phones. Next year they'll be in disposable cells. A year or two beyond that and dual-core arms will be turning up in musical Xmas cards as they are replaced by 4 & 8-core processors for phone/tablet/ICE applications.

   • That the practical manifestation of Moore's Law--the doubling of the number of transistors per chip--which until recently meant either the doubling of clock speeds, or (less frequently) the doubling of the width of the registers, has effectively hit the practical limits?

     You haven't read the writing all around you that says that in the future, the maintenance of Moore's Law means that the number of cores will likely double every 2 years whilst clock speeds and register widths stagnate.

4. Recursion, on the other hand, is a property of an algorithm.

   Recursion is a property of implementation.

   In many cases, algorithms written recursively in any given high-level language, are run iteratively by the implementation. This is the result of the well-known 'tail call elimination'

5. Furthermore, it is significant to observe that recursion is not parallel. The recursive iteration must complete, and deliver its result, before the outer iteration(s) may proceed.

   This is a(nother) very naive generalisation.

   Many, many algorithms that are habitually described recursively, due to the succinctness and clarity of that description are trivially convertible to an iterative implementation. And as soon as you have iteration, the potential for simple, direct parallelisation is obvious.

6. Many algorithms that can be expressed in a recursive fashion, also can be expressed in a massively parallel fashion ... but traditional threading models are not “massive parallelism,” a term that is usually reserved for talking about things like array (co)processors.

   Is there such a thing as a "tradition threading model"?

   If it did exist, the lines of where and when it existed are long since obscured.

   Witness that for a (low) few thousands, you can have 16-cores on your desktop today. And if you have the need and half a million, an effective 1024 cores is yours for the asking.

   Note also that if massively parallel array processing meets your requirements, then a few hundred quid will put the effective equivalent of a Cray 1 in your desktop in the form of a NVIDIA Tegra 2.

Times they are changin' have changed. Change with them, or die.

[sundialsvc4]

You really just don’t like me, do you? ...

[BrowserUk]

You're quite wrong. It is not you I have a problem with. How could it be, as I do not know you?

I do have a problem with many of your responses here. For the reasons I have often attempted to explain in detail.

Those explanations can be summarised as:

You have a tendency to offer 'potted wisdoms' rather than actual solutions.

This might be useful if those wisdoms were always, or even usually correct, but they aren't. Moreover, if they were sufficiently incorrect as to being obviously so, then I would ignore them and allow nature to take its course. But the danger is that they are often sufficiently grounded and plausible, as to make them casually indiscernible from ideas worth pursuing. Which makes them very capable of causing people to waste a lot of time doing so.

What's worse, even when your "ol'timer logic" has been comprehensively demonstrated to be flawed, again & again, you keep on trotting out your "virtual memory is disk" dogma. And you're still doing it.

Conversely, I've never seen you offer any Perl code as a solution. Nary a once. Maybe I just missed it?

To reiterate, it isn't you, but your posts I have a problem with.

[Limbic~Region]

BrowserUk,
Conversely, I've never seen you offer any Perl code as a solution. Nary a once. Maybe I just missed it?

I couldn't possibly imagine this to be true so I set out to prove you wrong. While you are in fact wrong, I was quite suprised by the results.

sundialsvc4 has been a monk since 2007-10-29 (3.25 years) and has posted 1148 nodes in that time. Of those, 1073 (93.5%) are replies. Of those, 141 (13.1%) have code tags. In other words, about 1 in 8 response have code. Here is the interesting thing - what I found surprising. Of the 141 with code tags, 89 (63.1%) were made in a one month window (2009-02-26 to 2009-03-25). In fact, of the 444 replies made in 2010, only 18 (4%) had code tags. Rather than being 1 in 8 responses it dropped to 1 in 25. Of the 94 replies so far in 2011 - none have code tags.

I want to be clear, I didn't gather this information to attack sundialsvc4. I honestly thought you were letting your feelings blind you to honest contributions. Disclaimers: The presence of a code tag doesn't mean the presence of actual code. While I excluded root nodes (non-replies), there isn't an easy way to exclude replies to yourself. I certainly didn't review all 1073 responses to subjectively quantify value and one should not draw the conclusion that because no code was provided that the response wasn't useful.