[Beowulf] Re: vectors vs. loops

[Jim Lux]

This gets into such famous discussions about "what language is most
computing done in?"  If you're looking at raw operations, at the application
level, it's probably COBOL or RPG or maybe, Java (compiled).  (What language
are ORACLE's products written in?)  If you count OS kernel, it might be C,
but it might also be Assembler.  What about all those cumulative MIPS in the
billions of cellphones?

But, if we talk about computationally intensive, single problem  (to
eliminate the enormous volume of transaction processing systems), there are
vectorizable things that get done all the time, albeit without much fanfare
and excitement.  Signal processing (like seismic data reduction) is
typically quite vectorizable.  Finite Element Models in many forms
(structural, thermal, electrical) are also vectorizable.  The processing for
these FEM things tend to look like building, then inverting a giant sparse
matrix, and by now, all the solvers have been optimized to store things in a
way to "keep the pipeline full".

Joe's comment on IDC's survey results for where HPCs are being bought should
be taken in the light that the users of FEM might not consider themselves
HPC users, even though they are.


Jim Lux

----- Original Message -----
From: "Joe Landman" <landman at scalableinformatics.com>
To: "Joachim Worringen" <joachim at ccrl-nece.de>
Cc: "beowulf" <beowulf at beowulf.org>
Sent: Tuesday, May 03, 2005 4:58 AM
Subject: Re: [Beowulf] Re: vectors vs. loops


> With all due respect, I think Robert is correct.  The majority of
> existing scientific code base is serial code with very limited (if any)
> vectorizable content, or parallelizable content.  This is in large part
> due to the way people write them.
>
> Aside from that, simply looking at the field of bioinformatics, I would
> be hard pressed to find a code capable of usting long vectors out of the
> box (HMMer can use short vectors, and even then a little rewriting is
> needed).  These codes tend to be trivially/embarrassingly parallel though.

>
> The issue may be one of labeling.  What you interpret as "the majority
> of scientific codes" may be very different than what I interpret as "the
> majority ..." and what Robert interprets as "the majority ...".
> Supercomputing and high performance computing in a more general sense,
> is not just about numerically intensive codes anymore.  IDC reports that
> the largest fractions of machine purchased for HPC in recent years have
> been going for "scientific research" and "life science computing".  The
> latter is effectively unvectorizable, and the former has a small
> fraction of overall content that is vectorizable.
>