On Wed, 04 Apr 2007 22:37:29 PDT, William Lee Irwin III said: > The actual phenomenon of concern here is dense matrix code with sparse > matrix inputs. The matrices will typically not be vast but may span 1MB > or so of RAM (1024x1024 is 1M*sizeof(double), and various dense matrix > algorithms target ca. 300x300). Most of the time this will arise from > the use of dense matrix code as black box solvers called as a library > by programs not terribly concerned about efficiency until something > gets explosively inefficient (and maybe not even then), or otherwise > numerically naive programs. This, however, is arguably the majority of > the usage cases by end-user invocations, so beware, though not too much.
Amen, brother! :) At least in my environment, the vast majority of matrix code is actually run by graduate students under the direction of whatever professor is the Principal Investigator on the grant. As a rule, you can expect the grad student to know about rounding errors and convergence issues and similar program *correctness* factors. But it's the rare one that has much interest in program *efficiency*. If it takes 2 days to run, that's 2 days they can go get another few pages of thesis written while they wait. :) The code that gets on our SystemX (a top-50 supercomputer still) is usually well-tweaked for efficiency. However, that's just one system - there's on the order of several hundred smaller compute clusters and boxen and SGI-en on campus where "protect the system from cargo-cult programming by grad students" is a valid kernel goal. ;)
pgpw3HTPdfUax.pgp
Description: PGP signature
