On Thu, Jul 16, 2009 at 3:47 PM, Aaron S. Meurer wrote:
>
> So I was trying to try out the parallel testing that Ondrej has setup
> in his par branch (see this old thread:
> http://groups.google.com/group/sympy/browse_thread/thread/379f13863348f80/af9d58ab53418e0f?lnk=gst&q=parallel#af9d58ab53418
OK. I didn't realize that I had to run the process in a separate
terminal. I worked when I did that. I think the other thing is still
a bug.
Aaron Meurer
On Jul 16, 2009, at 4:16 PM, Ondrej Certik wrote:
>
> On Thu, Jul 16, 2009 at 3:47 PM, Aaron S. Meurer
> wrote:
>>
>> So I was trying
On Thu, Jul 16, 2009 at 4:27 PM, Aaron S. Meurer wrote:
>
> OK. I didn't realize that I had to run the process in a separate
> terminal. I worked when I did that. I think the other thing is still
> a bug.
Which "other thing" do you mean?
Ondrej
--~--~-~--~~~---~--
Never mind. I was referring to the mec = client.MultiEngineClient()
command, but it seems that you need to have ipcluster running for that
to work too.
Aaron Meurer
On Jul 16, 2009, at 4:29 PM, Ondrej Certik wrote:
>
> On Thu, Jul 16, 2009 at 4:27 PM, Aaron S. Meurer
> wrote:
>>
>> OK. I
On Thu, Jul 16, 2009 at 4:31 PM, Aaron S. Meurer wrote:
>
> Never mind. I was referring to the mec = client.MultiEngineClient()
> command, but it seems that you need to have ipcluster running for that
> to work too.
Yes, the ipcluster starts ipengines on your machine, or remote
cluster/server.
Yep. It is definitely faster:
$ time ./bin/test
real8m18.517s
user4m6.898s
sys 0m4.019s
$ time python t.py (with ipcluster local -n 2)
real5m31.959s
user0m0.602s
sys 0m0.290s
$ time python t.py (with ipcluster local -n 4)
real4m30.470s
user0m0.494s
sys 0m0.
On Thu, Jul 16, 2009 at 5:16 PM, Aaron S. Meurer wrote:
>
> Yep. It is definitely faster:
>
> $ time ./bin/test
>
> real 8m18.517s
> user 4m6.898s
> sys 0m4.019s
> $ time python t.py (with ipcluster local -n 2)
>
> real 5m31.959s
> user 0m0.602s
> sys 0m0.290s
> $ time pytho
I reran the tests with 8 threads on my machine and watched it in the
built in GUI process manager on the Mac (Activity Monitor), and I see
what you mean. The load is distributed evenly until near the end,
when the processes drop one by one and only one is left. I don't
think it matters h
On Thu, Jul 16, 2009 at 5:54 PM, Aaron S. Meurer wrote:
>
> I reran the tests with 8 threads on my machine and watched it in the
> built in GUI process manager on the Mac (Activity Monitor), and I see
> what you mean. The load is distributed evenly until near the end,
> when the processes drop on
So Ondrej and I were able to get this working. We now just need to
hook it into the regular testing. If any one wants to give this a
shot, the branch to pull from is http://github.com/certik/sympy/tree/par2
. See t.py
Aaron Meurer
On Jul 16, 2009, at 5:58 PM, Ondrej Certik wrote:
>
> O
> Now some thoughts about load balancing:
[...]
> And finally I collect the results:
>
> http://github.com/certik/sympy/blob/55de47b6f0a7bee01249fc24c03e5567695c4569/t.py#L69
>
> and report the results to the user. This should of course be
I forgot to ask the question:
how could this be made m
On Thu, Mar 19, 2009 at 12:56 AM, Ondrej Certik wrote:
[...]
> I forgot to ask the question:
>
> how could this be made more efficient using some native ipython parrallel
> tools?
And last question:
Currently all the engines must be able to import sympy and I noticed
it is not even enough to i
On Thu, Mar 19, 2009 at 8:52 AM, Ondrej Certik wrote:
> All tests pass, except 4 mpmath tests, but I suspect it could be some
> bug in mpmath.
I suspect this is just due to tests being run out of the expected
order. Probably, adding "mp.dps = 15" at the top of each failing test
will fix it. I sh
On Thu, Mar 19, 2009 at 1:27 AM, Fredrik Johansson
wrote:
>
> On Thu, Mar 19, 2009 at 8:52 AM, Ondrej Certik wrote:
>> All tests pass, except 4 mpmath tests, but I suspect it could be some
>> bug in mpmath.
>
> I suspect this is just due to tests being run out of the expected
> order. Probably,
On Mar 19, 9:09 am, Ondrej Certik wrote:
> On Thu, Mar 19, 2009 at 12:56 AM, Ondrej Certik wrote:
>
> [...]
>
> > I forgot to ask the question:
>
> > how could this be made more efficient using some native ipython parrallel
> > tools?
>
> And last question:
>
> Currently all the engines must be
>> And what about a big cluster --- wouldn't it be handy to just tell
>> ipython: take this library and make it available on the engines,
>> without me requiring to install it manually and then restarting the
>> ipcluster?
>
> You can tell Python to import/reload a module using an explicit path,
>
Yes, we do have built-in dynamic load balancing. Check out the following:
client.TaskClient
client.StringTask
client.MapTask
All of this is dynamically load balanced. Here is how I would approach this:
1. Use MultiEngineClient to setup all the basic imports and variables
that all the engines
On Thu, Mar 19, 2009 at 10:29 AM, Brian Granger wrote:
>
> Yes, we do have built-in dynamic load balancing. Check out the following:
>
> client.TaskClient
> client.StringTask
> client.MapTask
>
> All of this is dynamically load balanced. Here is how I would approach this:
>
> 1. Use MultiEngine
Ondrej,
I need to take my kids somewhere but the answer to your question is
*yes absolutely*, you can interact with a controller and engine
running on a cluster somewhere from an ipython session on your laptop
sitting in starbucks. This is *the* main focus of our parallel stuff
in ipython. More
On Thu, Mar 19, 2009 at 1:13 PM, Brian Granger wrote:
>
> Ondrej,
>
> I need to take my kids somewhere but the answer to your question is
> *yes absolutely*, you can interact with a controller and engine
> running on a cluster somewhere from an ipython session on your laptop
> sitting in starbuck
20 matches
Mail list logo
