Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #16677

70% [* SPAM *] Re: multiprocessing.Queue blocks when sending large object

Path csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!cs.uu.nl!news.stack.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Return-Path <dpalao.python@gmail.com>
X-Original-To python-list@python.org
Delivered-To python-list@mail.python.org
X-Spam-Status OK 0.028
X-Spam-Evidence '*H*': 0.94; '*S*': 0.00; 'received:141': 0.03; 'memory.': 0.05; 'received:localnet': 0.07; 'subject:object': 0.07; 'subject:when': 0.07; 'python': 0.08; 'lie,': 0.09; 'am,': 0.12; 'combined.': 0.16; 'extension,': 0.16; 'justify': 0.16; 'numpy': 0.16; 'pipe,': 0.16; 'solution?': 0.16; 'subject:sending': 0.16; 'this:': 0.16; "wouldn't": 0.17; 'wrote:': 0.18; 'modified': 0.18; 'ryan': 0.18; 'convert': 0.19; 'memory': 0.21; 'trying': 0.21; 'input': 0.22; '(or': 0.22; 'header:In-Reply-To:1': 0.22; '(usually': 0.23; 'conversions': 0.23; 'end,': 0.23; 'gil': 0.23; 'produces': 0.23; 'cc:2**0': 0.24; 'code': 0.25; '(in': 0.26; 'code.': 0.26; "i'm": 0.26; 'tried': 0.27; 'cc:addr:gmail.com': 0.28; 'elements': 0.29; 'problem': 0.29; 'array': 0.30; 'arrays': 0.30; 'processes.': 0.30; 'queue': 0.30; 'worker': 0.30; 'url:library': 0.31; 'shared': 0.31; "didn't": 0.31; 'skip:( 20': 0.31; 'version': 0.32; 'does': 0.32; 'done,': 0.32; 'break': 0.32; 'typically': 0.32; 'message-id:@gmail.com': 0.33; 'header:User-Agent:1': 0.33; 'there': 0.33; 'object': 0.33; 'to:addr:python-list': 0.34; 'size,': 0.34; 'be,': 0.34; 'lie': 0.34; 'thank': 0.35; 'copying': 0.35; 'running': 0.35; 'url:python': 0.36; 'post': 0.36; 'david': 0.36; 'none': 0.37; 'but': 0.37; 'run': 0.37; 'hello,': 0.37; 'another': 0.37; 'doing': 0.38; 'using': 0.38; 'too,': 0.38; 'some': 0.38; 'put': 0.38; 'url:docs': 0.39; 'url:org': 0.39; 'should': 0.39; 'tasks': 0.39; 'to:addr:python.org': 0.40; 'within': 0.60; 'type': 0.61; 'achieve': 0.61; 'your': 0.61; 'header:Message-Id:1': 0.62; 'back': 0.62; 'cost': 0.63; 'vary': 0.64; 'believe': 0.65; 'share': 0.66; 'attractive': 0.67; 'transferring': 0.67; 'benefit': 0.69; 'url:2011': 0.74; 'forth': 0.77; 'received:93': 0.78; '"standard"': 0.84; '12)': 0.84; 'blocks.': 0.84; 'most,': 0.84; 'received:93.45': 0.84; 'url:28': 0.84; 'diciembre': 0.91; 'working,': 0.93; 'forever.': 0.95; 'subject:SPAM': 0.96
From DPalao <dpalao.python@gmail.com>
To python-list@python.org
Subject 70% [* SPAM *] Re: multiprocessing.Queue blocks when sending large object
Date Mon, 5 Dec 2011 19:28:22 +0100
User-Agent KMail/1.13.7 (Linux/2.6.39-gentoo-r3; KDE/4.6.5; x86_64; ; )
References <23330_1322593803_pATJ9jRv011464_201111292009.44527.dpalao.python@gmail.com> <jbidcg$4p3$1@dough.gmane.org>
In-Reply-To <jbidcg$4p3$1@dough.gmane.org>
MIME-Version 1.0
Content-Type Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding quoted-printable
X-Greylist Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.7 (monster.roma2.infn.it [141.108.255.100]); Mon, 05 Dec 2011 19:28:28 +0100 (CET)
X-PMX-Version 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.12.5.181814
X-PMX-Spam 70%
X-PMX-Spam-report The following antispam rules were triggered by this message: Rule Score Description RDNS_SUSP_FORGED_FROM 3.500 From domain appears to be forged, and arrived via a host with a known suspicious rDNS. SXL_IP_DYNAMIC 3.000 Received via a known dynamic IP (SXL lookup): 208.137.45.93.fur FORGED_FROM_GMAIL 0.100 Appears to forge gmail in the from FROM_NAME_ONE_WORD 0.050 Name in From header is a single word BODY_SIZE_3000_3999 0.000 Message body size is 3000 to 3999 bytes BODY_SIZE_5000_LESS 0.000 Message body size is less than 5000 bytes. BODY_SIZE_7000_LESS 0.000 Message body size is less than 5000 bytes. RDNS_GENERIC_POOLED 0.000 Sender's PTR record matches generic pooled pattern RDNS_SUSP 0.000 rDNS is suspicious RDNS_SUSP_GENERIC 0.000 rDNS is generic or doesn't exist
Cc Lie Ryan <lie.1296@gmail.com>
X-BeenThere python-list@python.org
X-Mailman-Version 2.1.12
Precedence list
List-Id General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-list>
List-Post <mailto:python-list@python.org>
List-Help <mailto:python-list-request@python.org?subject=help>
List-Subscribe <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups comp.lang.python
Message-ID <mailman.3314.1323109714.27778.python-list@python.org> (permalink)
Lines 75
NNTP-Posting-Host 2001:888:2000:d::a6
X-Trace 1323109714 news.xs4all.nl 6851 [2001:888:2000:d::a6]:40856
X-Complaints-To abuse@xs4all.nl
Xref x330-a1.tempe.blueboxinc.net comp.lang.python:16677

Show key headers only | View raw


Hi Lie,
Thank you for the reply.

El Lunes Diciembre 5 2011, Lie Ryan escribió:
> On 11/30/2011 06:09 AM, DPalao wrote:
> > Hello,
> > I'm trying to use multiprocessing to parallelize a code. There is a
> > number of tasks (usually 12) that can be run independently. Each task
> > produces a numpy array, and at the end, those arrays must be combined.
> > I implemented this using Queues (multiprocessing.Queue): one for input
> > and another for output.
> > But the code blocks. And it must be related to the size of the item I put
> > on the Queue: if I put a small array, the code works well; if the array
> > is realistically large (in my case if can vary from 160kB to 1MB), the
> > code blocks apparently forever.
> > I have tried this:
> > http://www.bryceboe.com/2011/01/28/the-python-multiprocessing-queue-and-l
> > arge- objects/
> > but it didn't work (especifically I put a None sentinel at the end for
> > each worker).
> > 
> > Before I change the implementation,
> > is there a way to bypass this problem with  multiprocessing.Queue?
> > Should I post the code (or a sketchy version of it)?
> 
> Transferring data over multiprocessing.Queue involves copying the whole
> object across an inter-process pipe, so you need to have a reasonably
> large workload in the processes to justify the cost of the copying to
> benefit from running the workload in parallel.
> 
> You may try to avoid the cost of copying by using shared memory
> (http://docs.python.org/library/multiprocessing.html#sharing-state-between-
> processes); you can use Queue for communicating when a new data comes in or
> when a task is done, but put the large data in shared memory. Be careful
> not to access the data from multiple processes concurrently.
> 

Yep, that was my first thought, but the arrays's elements are complex64 (or 
complex in general), and I don't know how to easily convert from 
multiprocessing.Array to/from numpy.array when the type is complex. Doing that 
would require some extra conversions forth and back which make the solution 
not very attractive to me.
I tried with a Manager too, but the array cannot be modified from within the 
worker processes.
 
In principle, the array I need to share is expected to be, at most, ~2MB in 
size, and typically should be only <200kB. So, in principle, there is no huge 
extra workload. But that could change, and I'd like to be prepared for it, so 
any idea about using an Array or a Manager or another shared memory thing 
would be great.

> In any case, have you tried a multithreaded solution? numpy is a C
> extension, and I believe it releases the GIL when working, so it
> wouldn't be in your way to achieve parallelism.

That possibility I didn't know. What does exactly break the GIL? The sharing 
of a numpy array? What if I need to also share some other "standard" python 
data (eg, a dictionary)?

Best regards,

David

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread


Thread

70% [* SPAM *] Re: multiprocessing.Queue blocks when sending large object DPalao <dpalao.python@gmail.com> - 2011-12-05 19:28 +0100

csiph-web