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