I'm thinking that multicore will make topology interesting again,
because of the difference between intercore on a common chip vs going
through a nic to even the fastest fabric.<br>
Peter<br><br><div><span class="gmail_quote">On 9/3/08, <b class="gmail_sendername">Lux, James P</b> <<a href="mailto:james.p.lux@jpl.nasa.gov">james.p.lux@jpl.nasa.gov</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I would say that the single biggest problem in HPC today is not getting<br> sufficient hardware horsepower, but in effectively using that power. 10<br> years ago, just getting a cluster going was a bit of a challenge, in terms<br>
of knowing what hardware to get, how to interconnect it, etc, but now, a lot<br> of that is cookbook (or available turnkey from a variety of vendors... A<br> very different matter from when Sterling, et al wrote their book back in<br>
98/99). Sure, there are still hardware issues that are worthy of discussion<br> on this list (details of interconnects, etc.), but one doesnıt see the<br> discussions about topologies that one saw back then. The hardware is now to<br>
the point where you rack up the computers, hook them all to a very fast<br> switch with huge bisection bandwidth, and youıre done.<br> <br> However, the topic of taking a simple problem and effectively parallelizing<br> it (either at a EP level as can be done with some Monte Carlo or systematic<br>
simulations, or at a fine grained level, as with matrix numerical modeling)<br> is very much grist for the mill.<br> <br> After all, what are all those folks building parallelizing/vectorizing<br> compilers trying to do but reduce the substantial software<br>
engineering/design problem, so that a scientist or engineer can just write<br> their problem out in simple form, and have ³the backend² figure out how to<br> do it efficiently (or at all).<br> <br> There are many problems which are, by their nature, software design complex<br>
enough that it is not reasonable to have the person ³asking the question²<br> also be knowledgeable enough to manage the substantial software development<br> project. This would be true, if for no other reason than managing a software<br>
development effort takes a different skill set than asking good science or<br> engineering questions.<br> <br> So, the real challenge facing builders (in the larger sense) of Beowulfs is<br> in developing methods to get the work actually done, and if that requires<br>
developing skills in ³eliciting requirements² or, more probably,<br> ³communicating between software speak and science speak², then this is an<br> appropriate place to do it (if not here, then where *would* be a place where<br>
itıs more germane.. I can't think of one off hand)<br> <br> It's sort of like our discussions about communicating with the facilities<br> folks about power requirements or HVAC. Someone building a cluster needs to<br>
know something about this to be an intelligent consumer, but nobody expects<br> the scientist to be down there sweating copper pipes for the chiller or<br> cabling up the EPO button for the UPS.<br> <br> The list is valuable because there *are* folks here who do know how to sweat<br>
pipes, manage software projects, and interpret the electrical code, and you<br> can ask a question about such things and get a host of responses, some more<br> useful than others.<br> <br> Jim<br> <br><br> <br> On 9/3/08 9:10 AM, "Prentice Bisbal" <<a href="mailto:prentice@ias.edu">prentice@ias.edu</a>> wrote:<br>
<br> > This discussion is still completely off-topic. This is a list about<br> > computing issues relating to beowulf clusters, not software engineering<br> > at large, sociology or psychology.<br> ><br> ><br>
><br> <br> <br> <br>_______________________________________________<br> Beowulf mailing list, <a href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a><br> To change your subscription (digest mode or unsubscribe) visit <a href="http://www.beowulf.org/mailman/listinfo/beowulf">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
</blockquote></div><br>