kirby urner wrote:
On Tue, Apr 13, 2010 at 10:30:49AM -0700, David MacQuigg wrote:
That's not to say the 1% is unimportant. Here we will find brilliant
programmers working on sophisticated techniques to break large problems
into pieces that can be executed concurrently by hundreds of processors.
Each problem is very different, and we may find programs for circuit
simulation using very different techniques than programs for weather
prediction. These programs will be run in an environment controlled by
Python. The circuit designer or atmospheric scientist will not be
concerned about the details of concurrency, as long as the result is fast
and accurate.
There's a school of thought out there that says operating systems are
supposed to handle concurrency pretty well. Some designs boot
multiple Pythons as multiple processes and let the OS take care of
concurrency issues. Why reinvent the wheel and rely on internal
threading? Instead of multiple threads within Python, make each
Python its own thread.
These concurrently running Pythons are then trained to communicate in
a loosely coupled fashion by reading and writing to centralized SQL
tables, which double as audit trails.
If a process dies, there might need to kill a process (zombie snake
problem), and maybe the controlling process (like air traffic control)
launches a new one -- depends on many factors.
As long as the coupling is loose, this kind of "concurrency" is easily
handled by Python (either with threads, or separate processes). The
more challenging concurrency problems involve tight coupling, tighter
than can be achieved with inter-process communications. Think of a
large system of equations, with 1000 outputs depending on 1000 input
variables.
The challenge is in partitioning that problem into smaller problems that
can be solved on separate processors, with manageable requirements
relating to interprocess communication. Strategies tend to be
domain-specific. If the domain is circuit design, the equations follow
the modularity of the design, e.g. a collection of subcircuits, each
with only one input and one output. That strategy won't work in other
domains, so we have no partition() function that will do it
automatically, and (in my opinion) not much chance that some new
language will come to the rescue. For problems that really need
partitioning, we need programmers that understand the problem domain.
The question for teachers using Python is - Will there be some future
"concurrency" language that is:
1) So different that its features can't be unobtrusively merged into
Python (not burdening those who don't need it).
2) So easy that it will replace Python as a general-purpose language,
even for those 99% that don't need concurrency.
I'll keep an open mind. Meanwhile, I've got to make a choice for
PyKata. We need to be ready for next semester.
_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig
