[Beowulf] High Performance for Large Database

[Robert G. Brown]

On Wed, 27 Oct 2004 hanzl at noel.feld.cvut.cz wrote:

> Hello RGB,
> 
> I had no intention to take up your whole morning :-) (Neither did I
> intend to exploit your susceptibility to DoS attack by making
> provocative comments :-)) )

Naaa, it was fun.  And the list has always been fairly tolerant of a
broad definition of HPC as long as it is fun and relevant (I really
think that fun more the criterion than whether it is floating point
intensive) just as it is tolerant of those people who do HPC on clusters
that aren't really "beowulf" style clusters in the original sense of its
definition (like me:-).

I'm also very interested in just what sort of symbolic manipulation you
are working on.  I've worked with some of the various algebraic
manipulation packages that have existed running back into the dawn of
time -- FORMAC, Macsyma, maple, mathematica .. and agree that there is
much in the token parsing and algebraic reconstruction process that
could be parallelized as parts of algebra are intrinsically independent.
There are also still an abundance of problems (in physics, especially)
where a good non-commutative algebra engine that can be taught about a
set of generators/commutators can really help out.  And then there is
geometric algebra (the descendent of quaternions, Grassman algebras,
Clifford algebras) where I think of things as barely being begun,
especially since there is a geometric/visualization component that tags
along with the algebraic component.

Anything like that?

    rgb

> 
> Of course, I agree with your explanation about databases. However,
> 
> > MOST of the energy of this list is devoted to HPC -- numerical
> > computations and applications.
> > ...
> > Nevertheless, databases per se are not numerical HPC, and a cluster
> > built to do SQL transactions on a collective shared database is not
> > properly called a "beowulf"
> 
> yes, but I still have a feeling that you are trying to squeeze
> _numerical_ to definition of beowulf which would be a pity because
> there are problems with _numerical/symbolic_ mix best solved on
> exactly the same type of hardware as the _numerical_ ones. I hope
> these can live on this list as well, unless cooling the FPU portion of
> the chip bacames the main topic here :-))
> 
> OK, I do confess that I do pursue my selfish goals because my problems
> are numerical/symbolic mix :-) And no, I do not use SQL databases for
> them. However I know people who do misuse SQL databases this way (in
> the similar manner we lazy people waste computer power with perl or
> Matlab) and who could make easy progress by MPI implementing very very
> limited subset of SQL, just enough to run those stupid select()s found
> in their code.
> 
> But I repeat, normal SQL databases are mostly out of topic here, no
> doubt.
> 
> Best Regards
> 
> Vaclav Hanzl
> 
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu