Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #16677
| 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
70% [* SPAM *] Re: multiprocessing.Queue blocks when sending large object DPalao <dpalao.python@gmail.com> - 2011-12-05 19:28 +0100
csiph-web