New submission from Charles-François Natali:

Here's an implementation of the idea posted on python-ideas 
(http://mail.python.org/pipermail/python-ideas/2013-January/018846.html).

The principle is really simple, we just serialize/unserialize the objects 
before/after holding the locks. This leads to reduced contention.

Here are the results of a benchmark using from 1 reader/1 writer up to 4 
readers/4 writers, on a 8-cores box:

without patch:
$ ./python /tmp/multi_queue.py
took 0.8340198993682861 seconds with 1 workers
took 1.956531047821045 seconds with 2 workers
took 3.175778865814209 seconds with 3 workers
took 4.277260780334473 seconds with 4 workers

with patch:
$ ./python /tmp/multi_queue.py
took 0.7945001125335693 seconds with 1 workers
took 0.7428359985351562 seconds with 2 workers
took 0.7897098064422607 seconds with 3 workers
took 1.1860828399658203 seconds with 4 workers

I tried Richard's suggestion of serializing the data inside put(), but this 
reduces performance quite notably:
$ ./python /tmp/multi_queue.py
took 1.412883996963501 seconds with 1 workers
took 1.3212130069732666 seconds with 2 workers
took 1.2271699905395508 seconds with 3 workers
took 1.4817359447479248 seconds with 4 workers

Although I didn't analyse it further, I guess one reason could be that if the 
serializing is done in put(), the feeder thread has nothing to do but keep 
waiting for data to be available from the buffer, send it, and block until 
there's more to do: basically, it almost doesn't use its time-slice, and spends 
its time blocking and doing context switches.

----------
files: queues_contention.diff
keywords: patch
messages: 180532
nosy: neologix, pitrou, sbt
priority: normal
severity: normal
status: open
title: reduce multiprocessing.Queue contention
type: performance
Added file: http://bugs.python.org/file28812/queues_contention.diff

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17025>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to