[SciPy-Dev] vectorized scipy.integrate.quad

[Anne Archibald]

On Tue, Oct 6, 2015 at 3:45 AM Sturla Molden <sturla.molden at gmail.com>
wrote:

> On 03/10/15 01:26, Anne Archibald wrote:
>
> > The additional hack where I used coroutines is a different kind of
> > concurrency; it's a way to squeeze extra concurrency out of recursive or
> > other more-complex algorithms. You can actually do the same using
> > threads; I have thread- and coroutine-based versions of the integrator,
> > and they look very similar.
>
> Personally I find that I prefer to make pipelines with threads (or
> processes) and queues, because coroutines make my brain overheat.
>

Well, that's kind of the point - threads, processes, coroutines, even
multiple inheritance and other "normal" flow-control procedures can be
hopelessly confusing if used raw. We need abstractions that make
concurrency mentally manageable but also allow reasonable parallelism.

Fortunately the language designers have been thinking about this and have
come up with some models for concurrency with less foot-shooting potential.
Although concurrency by definition introduces non-determinism, some
structures for concurrency can completely hide this from the programmer.
Futures can be used this way, for example. Pipelines can be another way to
express concurrency; taken to an extreme you can get dataflow languages
like pd. A sufficiently smart pipeline implementation can prevent headaches
with buffering and order of evaluation.

Coroutines generally can be quite confusing, but python's asyncio
implementation is essentially just cooperative multitasking: "async def"
marks a function that can be suspended (and therefore needs to be run from
a scheduler ("event loop")), and "await" marks a potential suspension
point. Otherwise it looks just like threads.

Anne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20151007/4f918b70/attachment.html>