Arch Robison wrote:
>
> Does anyone have statistics to prove that average numerically intensive code
> spends a majority of time doing matrix math? (Whatever average means here.)
> I doubt it, for the following reasons:
>
> 1. DSP applications constitute a large fraction of numerically intensive
> code. Indeed, I wouldn't be surprised if cell phones were the major
> numerical cycle users these days. Typical DSP algoritms are:
>
> (a) FFT
> (b) Convolution and correlation
> (c) Discrete cosine transforms
> (d) Whatever I forgot (its been 6 years since I was a practicing DSP hack)
>
> Even though these can be expressed as matrix math, they simple are
> not normally coded that way, because doing so would be quite inefficient.
I suspect that the reason we tend to forget DSP is that it is not a
"researchy" area, or, to be more accurate, it is not _our_ researchy area.
To put it another way, DSP is actually being used for practical purposes
all the time. So it tends to be done with specialized chips rather than
software -- let alone software in a high-level language.
Disclaimer: Since DSP is not my area, it's possible I just spouted solid
waste.
>
> 2. Numerical integration is another big user, and is often not matrix math.
You can express integration as a discretized matrix operator, but it's
extremely clumsy. I'm not aware of a practical reason anyone would do
it that way. (And in any case, the operator tends to be triangular,
so dense matrix treatment is not appropriate.)
>
> 3. Methods that gain from complexity rather than raw number crunching
> are becoming popular. E.g., multigrid and other hierarchical decompositions.
> Thus effort is better applied to "figuring out how to control complexity" rather
> than raw number crunching speed.
For that matter, our efforts at developing a dynamically load-balanceable
parallel PDE solver on unstructured meshes relies heavily on lists. The
arrays we use are simply containers for the data on each topological
entity; such an array is in no sense a field value or a matrix.
>
> 4. Graphics is a big cycle user, and graphics code which is not DSP is typically
> tiny matrix manipulation.
>
> 5. I/O - my guess is that more and more codes are becoming I/O bound,
> as processors continue to grow in speed much faster than I/O.
This is a major problem with huge simulations on massively parallel machines.
>
> 6. Most numerically intensive programmers probably spend more time in the
> compile-debug-edit cycle than actually running their code.
> So in a sense, more numerically intensive codes probably eat up more
> "integer" cycles than anything else!
Yes, this has been my experience.
>
> - Arch (who, ironically, was at the top of his class in numerical linear algebra)
Not me. My professor seemed to regard linear algebra as too easy a
subject to produce a decent grade curve, so he spread out the test
scores by imposing a no-calculators testing policy. This turned the
class into a semester-long arithmetic contest, and I felt lucky to
squeeze by with an A-.
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:11 EST