> I am giving a talk on beowulf clustering to a local lug and was wondering > if you had some interesting themes that I could talk about.
I think an interesting topic is the relationship between beowulf and cloud computing. (which basically boils down to a question of build-it or rent-it.) if the audience is academics, I think an interesting topic is: transient versus career-scale HPC tools. for instance, if you're undertaking a project using Cuda, you really must think about the timescale of the project. will Cuda exist in N years? will you have access to NVidia GP-GPU resources of appropriate scale for M years? it's really a question of tool choice: how to judge the longevity of a tool versus its possible payoff in performance. (MPI is a great counterexample, since it's been around and is not going away any time soon.) another interesting topic is how beowulf should respond to web2.0. what I mean is that web2.0 involves a whole raft of techniques that are culturally quite different from the usual linux/scheduler/MPI stack. things like 0mq, redis, mongodb, even node.js. of course hadoop and other, more recent big-data stuff. I don't think there is a conflict, exactly, but it's worth pondering, especially when parts of the HPC "establishment" are hot to trot about exascale. you could make an interesting talk just on "scale". for instance, if you wanted to run a 60-rank MPI job a few years ago, it would cost you a rack of nodes. everyone knows the name "Moore's Law", but it is sometimes interesting to make it tangible. now, for instance, you could do it with a single 4-socket server or a 1-socket server and a Phi card. or rent some EC2 instances! maybe just a survey of interconnects. Infiniband is pretty much de rigeur for large-scale/intensive MPI clusters, but obviously the volume market is almost totally Gb still. there is some 10G happening, and may perhaps become cheaper than IB (though it doesn't really match in performance.) vendors are talking about DCE, and Cisco is starting to try to draw attention to their stuff (including claims of IB-level performance.) topic: concurrency. examining the concurrency inherent to your problem, and deciding how to implement that on a cluster. for instance, you really need to break a workflow down into dataflow: the paths that particular values take, from setup to first computations, which create new values that follow further paths through computation or communication or storage. if your dataflow graph has long sequential sections, that means independent computations and can be done very nicely with serial jobs. lots of value "fan out" means that some form of communication must happen. the dataflow graph determines whether you can reasonably use master/slave, or more tightly coupled MPI with inter-node communication. or whether you can run a flock of serial jobs with only pre/post-processing to connect the pieces. _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
