December 20th, 2011, 3:24 pm
Thanks for an exhaustive reply! I'm still trying to get my bearings in the world of quantitative finance, but it would be good to see if/how I/we (PETSc) can contribute.Specifically, I'm trying to understand if/when performance becomes a factor, and how the community deals with that. I understand (correct me, if I'm wrong) that dense linear algebra prevails in quantitative finance, hence the emphasis on BLAS, etc.In that case I would expect to see memory limitations becoming a factor for substantial problem sizes.PETSc was initially developed as a PDE-oriented package with the emphasis on sparse linear algebra and iterative solvers.That is still the case, but we have more support for large-scale dense linear algebra. That's one of the directions we are interested in moving as well,for example, with large-scale rank-revealing QR factorization, better support for least-squares solvers, etc.On the other hand, I keep hearing about "free boundary problems" in quantitative finance and "PDE methods". For those I expect PETSc to be very effective. Maybe quantitative finance is more segmented than I realize and there is no one overarching theme to the computation and,hence, no "one-fits-all" linear algebra library solution here?I understand that usability is very important in this community. It's non-trivial to make usability and high-performance coexist nicely.At this point I feel like the community here emphasizes usability (inferring from your mentioning of operator overloading to make code look like math).Sooner or later, however, I suspect that performance issues will become too important to ignore.I would be very interested in understanding exactly what the performance requirements for the linear algebra in quantitative finance areto see if we can target that performance/usability sweet spot -- possibly along the lines of what you called "PETSc Lite".I want to point out that while the PETSc programming model is based on MPI, there is not need to actually have or build MPI to use PETSc, if only sequential (non-parallel, non-cluster) use is required. For that purpose we have a "stub MPI" called mpiuni (for uniprocessor),which fakes the MPI API in an efficient so that the rest of PETSc can proceed as usual. This is enabled using --with-mpi=0.Even if no high performance is necessary, good iterative algorithms might still be desirable. And as you pointed out, we offer interfaces to manyother packages (e.g., SUNDIALS, although we have greatly improved our native time-integrator support), which might be desirable in its own right.Finally, we are aggressively developing GPU and multicore (pthreads) support, so that high performance is possible without a cluster.Having a discussion on this subject would be great. Since I'm a novice at this forum, however, how does one PM here?Thanks!Dmitry.