[FRIAM] Large Memory Java Applications

[Jim Rutt]

Indeed.   A grid is not a grid is not a grid.  A loosely coupled "roomful 
of linux boxes" running on a couple legs of gigabit ethernet has far 
different attributes than  does a closely coupled system like the IBM SP2 
or the the Cray XD1.

The one and only "really big cluster" thing I did was back in the late 90s 
we bought one of the first really big Sun T10000 configurations, put 100 
gig of memory in it, and loaded the most heavily used part of our Westlaw 
legal database.  $2 million of Sun stuff replaced $50million of Plug 
Compatible VM mainframes.  That project, though was done using C and a 
homebrew in memory knockoff of adabase.

=jim




At 10:16 AM 5/26/2006, you wrote:
>Hi Dan, that seems like a clever approach..  One remark on this bit:
> > In fact, with
> > today highly non-uniform memory hierarchies (L1 cache -> L2 cache ->
> > ... -> main memory), even using RAM by way of random access can make
> > large computations infeasible.
>By Little's law (http://en.wikipedia.org/wiki/Little's_law), concurrency
>= bandwidth * latency.
>If it's possible to parallelize the search, then the latency of the
>memory system can be tolerated, as there are more threads of execution
>that can do useful work.  Chances are they won't all be blocked on
>memory access.  For example, with a distributed shared memory package on
>an Infiniband cluster (e.g. Intel's Cluster OpenMP*), or a highly
>multithreaded CPU architecture (UltraSparc T1), I think there's still a
>practical hope not to give up on random access algorithms.
>
>Marcus
>
>
>============================================================
>FRIAM Applied Complexity Group listserv
>Meets Fridays 9a-11:30 at cafe at St. John's College
>lectures, archives, unsubscribe, maps at http://www.friam.org

===================================
Jim Rutt
voice:  505-989-1115