Dear Steven,
Rephrased that way, I can agree with you.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Steven Ericsson-Zenith
Sent: Sunday, February 24, 2013
5:19 PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Sapir-Whorf Hypothesis
I think you miss my point and make my case. :-) I would certainly not
direct an engineer into one of these methods - but rather eliminate their
concern for the issue. If you call out any particular method for parallel
decomposition or "message passing" you will preoccupy the engineer
with performance semantics.
Better to eliminate the ideas entirely from high level languages designed
to solve real problems since they are not necessary and contribute nothing
algorithmically. Ideally, programmers need not be concerned about mapping
their solution to a machine.
But to solve this problem well requires a combined and coordinated effort
between software and hardware layers. The solution requires that the two be
designed as one with the long term in mind.
On Feb 24, 2013, at 5:01 PM, "Rich Cooper"
<rich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
Steven wrote:
Dear Phil,
It is not a question of limiting thought but more to do with directing the
engineer toward one solution over another, often complicating their
thoughts and behaviors with unnecessary concerns, and distracting the
engineer from the task at hand.
For example, in the case of parallel programming the engineering
preoccupation becomes data distribution. Speak to a
"parallel programmer" and this is what they will tell you
about before everything else. Whereas it would be more desirable and more
productive for all concerned if their preoccupation were, in fact,
the problem at hand.
I disagree. The methods for parallelizing computation are
diverse, and by “directing the engineer” into one of those methods
is counterproductive. Each engineer has a conception of how to
incorporate parallelism, and data distribution is just one such way.
In my dissertation, I showed a method for organizing the
computation sequence into chunks so that each chunk could be performed in
any one of N computers, and the calculated output of that chunk and
function becomes another chunk to be input to any one of those
N computers. The system self balances, i.e., each computer in
a string has as its first obligation to pass the current chunk on to the
next if and only if that computer is not busy. That is, each
processor keeps the next processor busy before continuing its own
calculation. There was a paper published in the IEEE Transactions
on Electronic Computers (September, 1977 I think, or thereabouts) based on
the same dissertation.
In other words, the preoccupation distracts engineers from their primary
task: algorithmic design. And in fact parallelism itself contributes
nothing at all to algorithmic design - both issues, parallel decomposition
and data distribution, provide only performance semantics (a
pragmatic).
The details are in:
http://www.amazon.com/Process-Interaction-Models-Steven-Ericsson-Zenith/dp/1463777914
In this book I tried to address this issue for parallel machines. There
were not so many of these at the time but now, of course, they are
pervasive. However, I should say that I am happier with my more recent
("Keen") proposals in this area.
I considered only general purpose programming languages, not languages for
distinct domains. However, these issues are general and will still
exist even if one or the other language were generally considered more
suitable for a given application domain.
Again, I disagree. The issues are certainly widespread, but
not truly general. The history of computer architecture shows so
many ways to solve concurrent computation problems that are not
related to the language itself, but to the processor architecture and
interconnection method. Language is secondary in that
it conforms to the computing architecture in which the system must
run.
However, any language that addresses parallelism must also map
efficiently onto some architecture. That is not a simple mapping,
since multicomputer architectures are so diverse. With LANs now
common, it has become standard practice to consider the parallel
architecture of the LAN (or WAN) to be the default architecture, but
that is not always the case.
Regards,
Steven
On Feb 24, 2013, at 7:08 AM, Phil Murray <pcmurray2000@xxxxxxxxx> wrote:
> I doubt that a
> specific language limits what a good programmer thinks should be
> possible.
|
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (01)
|