hardbyte / hardbyte/scipy-sim

Convert from threading to multiprocessing

Open
#6 0 comments 0 reactions 0 assignees View on GitHub
auto-migrated Performance Priority-Medium Type-Enhancement
Dominant language
Python
Stars
0
Forks
1
PR merge metrics
No merged PRs in 30d

Description

```
I think that it's worth considering converting actor.py and the other core
classes of scipysim from using the threading library to using the
multiprocessing library
[http://docs.python.org/dev/library/multiprocessing.html]. Doing so seems
like it'd bring several advantages:

1. It would allow us to avoid the performance problems associated with the
Global Interpreter Lock, which is likely to become a problem as we move to
larger models.

2. It would put us in a position to take advantage of multicore systems,
which is nominally one of the benefits of using the "directorless" style
that we've adopted (and seems likely to be increasingly important in coming
years).

3. It appears that it might resolve the threading problems that we
previously ran into with matplotlib, allowing us to implement real-time
plotting.

Since we already require Python >= 2.6 for other reasons I don't see any
problems with version compatibility. The only obvious drawback I can see at
this point is that the multiprocessing library apparently suffers from low
performance on Windows (which seems to have fairly heavyweight processes).
Perhaps we could consider having actors (and the display) revert to the
current threaded implementation when running on Windows.

```

Original issue reported on code.google.com by `allan.mcinnes@gmail.com` on 8 May 2010 at 8:52

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.