Hi Brian, Thanks for reading and responding to my comments. On Wed, May 21, 2008 at 8:11 AM, Brian Granger <[EMAIL PROTECTED]> wrote: >> IPython1 is a Python library that Sage ships that builds on MPI. >> Maybe Fernando or Brian (who I've just cc'd) can comment. >> We also build on Twisted, which is somewhat relevant for >> certain types of problems.. > > A few comments along these lines: > > - mpi these days is actually really easy to build. I use openmpi and > I have to try pretty hard to get it to not build right. mpi4py should > build as easy as anything else in sage. As William mentioned, there > is not a strong demand yet for MPI in Sage, but if there were it would > not be too difficult a problem. >
I suppose I'm expressing the view that if users express a desire to use parallel routines, (distinct from a desire to have a particular implementation MPI vs PVM, etc.), then MPI, PETSc and other tools have been extensively developed and are worthy of being part of the basic infrastructure SAGES builds on from the bottom up, rather than leaving them as add on's. William seemed to indicated SAGE is intended to be a grid/cloud application rather than a desktop application +some optional parallel routines. This is an extremely abitious goal, but more likely to be achieved if existing efforts are utilized which seems to be part of the SAGE philosophy. For example, if I started SAGE on a dual processor the parallel (MPI or some other parallel library) universe would be set to 2. >From a users point of view it seems gridMathematica is an example of the sequential-to-parallel-application development. The result didn't seem natural to me, mainly because so many core issues can be quite different, and very difficult in parallel settings. William points out correctly that having a grid application that runs sequential code better than any other will be tricky - there is overhead and the communicate vs calculate choice is not always axiomatic. I also found that parallel code sometimes altered the way I thought about a problem and led me to make choices I would not make in the sequential setting. > - IPython1 doesn't exactly "build on MPI" It is implemented in pure > python using Twisted. It does interoperation with MPI though. > Great, and maybe that is the best choice for SAGE's current or future needs. > - I don't think going in the direction of globus is a wise idea. As you point out it Globus is huge, and their use case is not SAGE, but I would be very surprised if components of their 'toolkit' didn't have something to offer. Their dev's might even have some experiences to share? My experience is that just the search costs involved in defining, and evaluating what I needed was substantial, so I'm certainly not suggesting this would offer an immediate silver bullet. All the more so in the case of SAGE given that this would be the first grid/cloud application (that I'm aware of) of this type. I do think though there is an opportunity to build something that offers opportunities that are fundamentally different to the 4M's. > Globus was created with a spirit that is completely orthogonal to that > of Python, web 2.0, Sage, IPython1, etc. It is extremely heavyweight, > difficult to install/maintain/admin, it has horribly complex APIs and > (in my opinion) and would _never_ be used by the types of people that > are using Sage (OK, maybe this is a generalization - I can't really I obviously haven't been clear. I'm trying to advocate that these components are worth considering as the foundation/chassis and would typically lie 'under the hood'. That they are there means a user could employ the components if they wanted to. They could also be oblivious (in an ideal world) to them. > speak for all users of Sage). Compared to Globus, MPI is super > lightweight, especially is used from Python through mpi4py. I am not > saying that Sage should use MPI, only that if it needed it, it is not OK, I am saying that SAGE should use MPI :) Just kidding, I'm not too concerned, and I'm happy with SAGE exactly as it is! I just thought some early choices might leave greater scope for some things further down the road. > a big deal. Globus is a whole different ball game though. Hmm, my experience was that things I thought were simple quickly became a big deal :) But I feely admit to being an amateur in the field. The discovery of PETSc and TAO libraries stirred deep gratitude to their developers :) As I mentioned earlier, I was eventually crushed by the weight of trying to debug parallel code that run fine in MPI universe of 1, and 2 but blew up in other cases. > > - Python does have a number of really good Object relational mapping > projects. The best is currently SQLAlchemy (which Sage already uses). > Thanks I will look into that. Cheers Mark > Cheers, > > Brian > >>> Of course all this is moot if the goal is a desktop application that >>> has some parallel compute options. >> >> That is not the goal of Sage. >> >>> My 2c :) >>> >>> Cheers >>> Mark >>>> >>> >> >> >> >> -- >> William Stein >> Associate Professor of Mathematics >> University of Washington >> http://wstein.org >> > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
