We'll start looking into it here at NIST later this summer. We have some expressions on the order of 10,000 terms and things do tend to slow down ;>
William On Tue, Jun 22, 2010 at 2:50 PM, Kevin Hunter <khun...@sandia.gov> wrote: > If you haven't programmed a multi-execution style algorithm before, > it's a bit of a mental leap. However, the thought process involved > with multi-threading vs multi-processing vs multi-machine scales. > There is a growing movement to teach college students and younger > folks to think "in parallel" from the get-go, but there will be a > delay while the ecosystem waits for the current core of linearly- > trained professors and teachers to retire. (i.e. Parallel is here to > stay. Programmers and engineers not trained to think in parallel are > effectively wasting compute power.) > > In the meantime, Python has some direct support for this. For example > > http://docs.python.org/library/subprocess.html > http://docs.python.org/library/multiprocessing.html > > However, if you're looking for the pragma style "this loop is SIMD, do > the work for me," I'm not aware that Python has that. (SIMD = Single > Instruction Multiple Data, such as an increment of 1 to every element > in an array. Check out the Wikipedia on OpenMP for more info: > http://en.wikipedia.org/wiki/OpenMP ) > > Do you have to completely rewrite algorithms? Depends on what you > want to do. Without delving into SymPy code (which I unfortunately > can't do at the moment), I'd guess that your analysis is correct: > implementing it wouldn't be a win except for some compute intensive > areas, especially since it sounds like the coder base doesn't have a > whole lot of experience thinking in parallel. > > I will say, that a good chunk of the /well written/ Python code that > I've run across lends itself very well to parallel interpretation. On > the flip side, I find that folks who think more in an imperative > style, tend to write much more linear-restricted algorithms and code. > Often this boils down to reimplementing the many wheels of their > programs, but I digress. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sy...@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com <sympy%2bunsubscr...@googlegroups.com>. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sy...@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
