On 26 May, 20:09, Carlos Nepomuceno <carlosnepomuc...@outlook.com> wrote: > ---------------------------------------- > > > > > > > > > > > Date: Sun, 26 May 2013 10:21:05 -0700 > > Subject: Re: Solving the problem of mutual recursion > > From: peter.h.m.bro...@gmail.com > > To: python-l...@python.org > > > On May 26, 5:09 pm, Jussi Piitulainen <jpiit...@ling.helsinki.fi> > > wrote: > > >> A light-weighter way is to have each task end by assigning the next > >> task and returning, instead of calling the next task directly. When a > >> task returns, a driver loop will call the assigned task, which again > >> does a bounded amount of work, assigns the next task, and returns. > >> Tasks can even pass parameters in the same way. > > > Yes, that's true - there are a number of ways of making it linear. > > > What I'm particularly pleased about with my method is the parallelism > > that it achieves - with so little effort! The simulation is going to > > be computationally intense and this is going to make sure that the > > CPUs are all giving it their best shot. When I run this on my macbook, > > the python interpreter takes over 140% of CPU - with a bit of fine- > > tuning, it should be possible to have more concurrent threads and to > > use the four cores optimally. > > > Naturally I'll need to be careful with the concurrency, but this is so > > simple and clean that it should be easy to avoid the main problems > > with accessing the same variables. > > -- > >http://mail.python.org/mailman/listinfo/python-list > > Python threads run in the same process and won't run concurrently: > > "CPython implementation detail: In CPython, due to the Global Interpreter > Lock, only one thread can execute Python code at once (even though certain > performance-oriented libraries might overcome this limitation). If you want > your application to make better use of the computational resources of > multi-core machines, you are advised to use multiprocessing. However, > threading is still an appropriate model if you want to run multiple I/O-bound > tasks simultaneously."[1] > > How can you get 140% of CPU? IS that a typo?? > No, on a multi-core machine it's normal. The machine shows python running multiple threads - and the number of threads change as the program runs. Perhaps the OS/X implementation of python does allow concurrency when others don't. It certainly looks like it!
-- http://mail.python.org/mailman/listinfo/python-list