David Barbour wrote:
On Wed, Apr 4, 2012 at 9:00 AM, Miles Fidelman
<mfidel...@meetinghouse.net <mailto:mfidel...@meetinghouse.net>> wrote:
The whole point of architecture is to generate the overall outline
of a system, to address a particular problem space within the
constraints at hand. The KISS principle applies (along with "seek
simplicity and distrust it"). If there isn't a degree of
simplicity and elegance in an architecture, the architect hasn't
done particularly good job.
I agree.
In the past, limitations of hardware, languages, and run-time
environments have dictated against taking parallel (or more
accurately, concurrent) approaches to problems, even when massive
concurrency is the best mapping onto the problem domain -
resulting in very ugly code.
I'd say the bigger problem is that there haven't been very good
concurrency models that ever reached mainstream. The choices have been
threads and locks, processes, maybe a transactional database.
Sort of depends on the scale you're looking at. At a systems level,
pretty much everything is concurrent these days - lots of clients
hitting lots of servers, with very loose coupling, and huge numbers of
transactions happening all at once. Some pieces tend to get serialized
as you get closer to databases, but that's about it.
As you get into the architecture of a specific service, again things
look pretty concurrent - say a web server spawning a process to handle a
request.
Outside of mainstream, there are a lot more options. Lightweight time
warp. Synchronous reactive. Temporal logic. Event calculus. Concurrent
constraint. Temporal concurrent constraint. Functional reactive
programming.
Few of which, however, are conceptually simple (maybe elegant).
Yes, there are additional problems introduced by modeling a
problem as massively concurrent
Well, not inherently. I'd note that your example of 5 loops with 2000
tanks at 20Hz is essentially an implementation of a step-clocked
concurrency model. It just happens to be represented in a sequential
programming language, so you get a bunch of semantic noise (i.e. as an
outside observer you know that all 2000 computations of line-of-sight
are independent of one another, but that isn't obvious in the language).
I wouldn't consider anything that's inherently synchronous as an example
of concurrency. Parallel yes.
Re. LOS calcuations: right off that bat, from a global viewpoint I see
an n-squared problem reduced to an n-factorial problem (if I can see
you, you can see me - don't need to calculate that twice). But that's
an optimization that's independent of concurrency.
But your particular choice for massive concurrency - asynchronous
processes or actors - does introduce many additional problems.
And eliminates many more - at least if one takes a shared-nothing,
message passing approach.
- control latency, support replay, testing, maintenance,
verification: these are nothing new at the systems level (think
about either all the different things that run on a common server,
or about all the things that go on in a distributed system such as
the federated collection of SMTP servers that we're relying on
right now)
Yes, these are old problems at the systems level. Mostly
unsolved. I've seen e-mails take 5-6 days to get through. We have
almost no ability to reason about system invariants. We need constant
human administration to keep our systems up and running. I'm quite
familiar with it.
- consistency: is not your message "Avoid the Concurrency Trap by
Embracing Non-Determinism?" -- is not a key question: what does it
mean to "embrace non-determinism" and how to design systems in an
inherently indeterminate environment? (more below)
Uh, no. But I see below you confused me with another David. Perhaps
see my Mar 28 comment in this thread. I reject Ungar's position.
Yup. Sorry about that. I don't reject his position.
The old sequential model, or even the pipeline technique I
suggest, do not contradict the known, working structure for
consistency.
But is consistency the issue at hand?
Yes. Of course, it wasn't an issue until you discarded it in pursuit
of your `simple` concurrency model.
We're talking about "fundamentals of new computing" - and a far as I can
tell, Ungar and Hewitt have it about right in pointing out that
consistency goes out the window as systems scale up in size and
complexity. The question to me is what are design patterns that are
useful in designing systems in an a world where inconsistency is a
given. Probabilistic and biological models seem to apply.
This line of conversation goes back to a comment that the limits
to exploiting parallelism come down to people thinking
sequentially, and inherent complexity of designing parallel
algorithms. I argue that quite a few problems are more easily
viewed through the lens of concurrency - using network protocols
and military simulation as examples that I'm personally familiar with.
I have not argued that people think sequentially or that parallel
algorithms are inherently complex. I agree that many problems are well
viewed through the lens of concurrency.
Ahh... but that is the point I was responding to that led to this branch
of discussion.
But your proposed approach to concurrency is not easier, not once you
account for important problems solved by the original simulator that
you chose to ignore.
You seem to be making the case for sequential techniques that
maintain consistency.
Pipelines are a fine sequential technique, of course, and I think we
should use them often. But more generally I'd say what we need is
effective support for synchronous concurrent behavior - i.e. to model
two or more things happening at the same time.
And I find that synchronous behavior, at least at the micro level, leads
to huge amounts of problems, and very brittle systems. Where
synchronous behavior is needed, I find it easier to apply at higher
levels of a protocol stack, where application-behavior can drive
specific synchronization models. (TCP over IP for example, return
receipts for mail, 2-phase commits for databases, forward error
correction for media streams, ...).
I also disagree with Hewitt (most recently at
http://lambda-the-ultimate.org/node/4453). Ungar and Hewitt both argue
"we need indeterminism, so let's embrace it". But they forget that
every medicine is a poison if overdosed or misapplied, and it doesn't
take much indeterminism to become poisonous.
To accept and tolerate indeterminism where necessary does not mean to
embrace it. It should be controlled, applied carefully and explicitly.
Then we're in violent disagreement. I've yet to see a complex system
where indeterminism isn't the norm, and where attempts to impose
determinism cause huge, often insurmountable problems (think societies,
or mono-culture agriculture).
a) you selectively conceptualize only part of the system - an
idealized happy path. It is much more difficult to
conceptualize your whole system - i.e. all those sad paths you
created but ignored. Many simulators have collision detection,
soft real-time latency constraints, and consistency
requirements. It is not easy to conceptualize how your system
achieves these.
In this one, I write primarily from personal experience and
observation. There are a huge class of systems that are inherently
concurrent, and inherently not serializeable. Pretty much any
distributed system comes to mind - email and transaction
processing come to mind. I happen to think that simulators fall
into this class - and in this regard there's an existence proof:
In general, the asynchronous semantics you get with processes and
actors are also a poor map to simulation problems. In my experience,
the best approaches to simulation involve synchronous programming of
some sort - event calculus, step clock, synchronous reactive, temporal
logic, functional reactive, reactive demand programming, etc.
Well, clearly, we have very different experiences (or are working on
very different kinds of simulations).
The basic reason for this is that you: (a) want to model lots of
things happening at once (not `asynchronously` but truly `at the same
time`), (b) you don't want any participant to have special advantage
by ordering in a turn, (c) you want consistency, freedom from glitches
and anomalies, and ability to debug and regression-test your model,
(d) you want precise real-time reactions - i.e. as opposed to delaying
messages indefinitely.
not when you're building things like wargames - things are very
probabilistic at the macro level - if you want to understand a range of
outcomes, you have to re-run the exercise, possibly many times using
monte carlo techniques
In the case of email, I can't even begin to think about applying
synchronous parallelism to messages flowing a federation of mail
servers.
That's a rather facetious case, of course. E-mail is defined by an
asynchronous protocol. But I can easily model asynchronous
communication in a synchronous system by use of intermediate shared
state (a database, for example).
Not at all. The world is asynchronous. Email provides a very good
model for the environment that we're building systems in today.
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
