I think (as I've said before, sorry if I'm banging a drum) that the new idea of "node" is going to be relative, and we will end up with more elementary concepts. To a trivially distributed, compute intenstive application (like, crunching a long time to factor one big integer), a node would be just an independent hyperthread within a core. To a latency intensive, message passing appliation, like the N body problem or weather forecasting, a node would be something with it's own NIC, like a motherboard level, not a single core.
I believe that sooner or later applications will be smart and adaptable about it, and request different kinds of nodes for different kinds of tasks. So we will have terms like: fat node -- has it's own NIC and disks. fast node -- has a fast connection, maybe faster than most nodes on the cluster, 100GigE whatever. thread node -- the node for a compute intensive app. leaf node -- relative; maybe fat for some apps, threads for others. etc. Every since coining the term "groupie" (for a node that has few neighbors, but is connected to nodes with lots of neighbors) which got into the literature (graph theory) I've been ambitious about this sort of thing :-) Peter P.S. the mathematician Leonard Carlitz (I wrote his wiki entry) taught me by example how much better you work when you group terms into the right level of abstraction. You think as efficiently as the concepts are appropriately loaded in your brain, with handles. Like OO programming except back then it was grouping algebraic terms on paper :-) On 4/29/09, Mark Hahn <h...@mcmaster.ca> wrote: > > I think the term ´nodeĄ is a loaded term in HPC. This is what comes >>> >> > I think it's just a bit sloppy or at least contextual - I've never > heard it used for anything other than "box". a node on a conventional > message-passing cluster is clearly one computer, which may contain multiple > cores, but has a single memory domain. on an Origin/Altix, > people seem to prefer "brick", but sometimes use "node", and is obviously > not a single memory domain. MPI programmers usually use "rank" or > "processor", and don't get hung up on nodes. > > There is an awful lot of software around which refers to "nodes" when in >> your nomenclature it means core[1], most of it harks back to when nodes >> > > hmm, a contrary example is gromacs - it explicitly talks about nodes > but permits threads within a node. ie, an 8-core box could be a single > node with 8 threads or 8 nodes, 1th each. > > incidentally, any gromacs experts comment on scalability of using the > thread support? (ie, for four 8c boxes with IB, 32 nodes vs 4 nodes, 8 > threads each?) > > had one CPU and a CPU had one core. Even the concept of cores >> themselves are only six or seven years old, before then a CPU was just a >> CPU and you would refer to "a N CPU cluster". >> > > and to be on the safe side (wrt forms of simultaneous multi-threading), > we should probably try to use "thread" instead. meaning a single hardware > execution context. > _______________________________________________ > Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing > To change your subscription (digest mode or unsubscribe) visit > http://www.beowulf.org/mailman/listinfo/beowulf > >
_______________________________________________ Beowulf mailing list, Beowulf@beowulf.org sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
