On Tuesday 16 June 2009 03:29:47 pm Satish Balay wrote: > On Tue, 16 Jun 2009, Alex Peyser wrote: > > On Tuesday 16 June 2009 02:29:14 pm Matthew Knepley wrote: > > > This is a common misconception. In fact, most time is spent in MatVec > > > or BLAS1, neither of which benefit from MT BLAS. > > > > Interesting. At least my misconception is common. > > That makes things tricky with ATLAS, since the number of threads is a > > compile-time constant. I can't imagine it would be a good idea to have an > > 8x BLAS running 8xs simultaneously -- unless the mpi jobs were all > > unsynchronized. It may be only 10-20% of the time, but that's still a > > large overlap of conflicting threads degrading performance. > > > > I'll have to do some benchmarks. Is the 10-20% number still true for > > fairly dense matrices? > > Its just a number I pulled out of a hat [for sparse matrix > solves]. -log_summary would be the correct thing for a given > application. > > If using MATDENSE - a much higher percentage of time will be in blas. > > Satish > > > Ah, another layer of administration-code may now be required to properly > > allocate jobs. > > > > Alex
Unfortunately, I'm writing a language. I don't know the application apriori. I have my current application -- which I can benchmark and is dense. But I would hate to predetermine the situation for future problems. Recompiling BLAS (and everything depending on it) on a per-use basis isn't a terribly attractive solution -- but that's a future problem. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20090616/7964b718/attachment.pgp>
