The charming adventures of an analyst and his solver.
Exploit multicore architectures with ease and the Python futures module!
Starting with a does of realism, it's possible this will turn out like the day when coroutines were introduced into Python 2.5. At the time I was extremely excited. Upon hearing the news I spent several hours trying to convince developers at my then-employer that the only way we could survive as an organization was to immediately abandon all our existing Java infrastructure, porting it to a new and beautiful world based on finite state machines implemented using Python coroutines. After a day of hand waving over a proof of concept, we all continued about our lives. Soon after, I left for a Python shop, but in the next half decade I still never found a good place to use this beloved feature in solving the daily challenges of my professional life.
As I come to terms more with switching to Python 3.2, the futures module emerges as a source of similar excitement. This is one of those would-have-made-my-life-so-much-easier features I wish I'd had years ago, and is almost reason in itself to upgrade from Python 2.7. Who cares if none of your libraries have been ported yet?
I think the real strength of this library springs from its ability to take any pre-existing function and distribute it over a process pool. Here is an example that computes minimum spanning trees for fully connected graphs. For purposes of testing, we generate 100-node fully connected graphs with random arc weights between 1 and 10. We then find their minimum spanning trees using the pygraph library, using groups of 4, 8, ..., 28 random graphs in serial and in parallel. Note how easy it is to take the minimum spanning tree function and map it over a process pool without any changes to its code.
from concurrent import futures from csv import writer from pygraph.algorithms import minmax from pygraph.classes.graph import graph import random import string import sys import time def generate_graph(): # Generates a randomly weighted, fully-connected, undirected graph nodes = [str(i) for i in range(100)] g = graph() for n in nodes: g.add_node(n) # Build an edge from each node to every other node for i, n in enumerate(nodes): for o in nodes[i+1:]: weight = random.uniform(1, 10) g.add_edge((n, o), weight) return g def serial_test(graphs): for g in graphs: tree = minmax.minimal_spanning_tree(g) def parallel_test(graphs, max_workers): with futures.ProcessPoolExecutor(max_workers=max_workers) as executor: for tree in executor.map(minmax.minimal_spanning_tree, graphs): pass # normally we'd do something with this... if __name__ == '__main__': out = writer(sys.stdout) out.writerow(['num graphs', 'serial time', 'parallel time']) # Run with a number of different randomly generated graphs for num_graphs in (4, 8, 12, 16, 20, 24, 28): graphs = [generate_graph() for _ in range(num_graphs)] start = time.clock() serial_test(graphs) serial_time = time.clock() - start start = time.clock() parallel_test(graphs, 4) parallel_time = time.clock() - start out.writerow([num_graphs, serial_time, parallel_time])
The output of this script shows that we get a fairly linear speedup in this particular example with little to no effort.
Given that the box I'm running this on has 4 cores, it's a little odd that the speedup factor is more like 2. It's probably just that the machine has a lot going on, so it's not really worth investigating right now. At the very least, each core is kept busy when the test forks.