[prev in list] [next in list] [prev in thread] [next in thread]
List: beowulf
Subject: Re: [Beowulf] 1 multicore machine cluster
From: "Peter St. John" <peter.st.john () gmail ! com>
Date: 2009-04-29 23:17:40
Message-ID: e4d4fd070904291617v31c4885es611c823bd9fbe5ea () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I think (as I've said before, sorry if I'm banging a drum) that the new ide=
a
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 singl=
e
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 b=
y
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 <hahn@mcmaster.ca> wrote:
>
> I think the term =B4node=A1 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 multip=
le
> 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 hardwar=
e
> 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
>
>
[Attachment #5 (text/html)]
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.<br>
<br>
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:<br>
<br>
fat node -- has it's own NIC and disks.<br>
fast node -- has a fast connection, maybe faster than most nodes on the cluster, \
100GigE whatever.<br> thread node -- the node for a compute intensive app.<br>
leaf node -- relative; maybe fat for some apps, threads for others.<br>
etc.<br>
<br>
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 :-)<br>
<br>
Peter<br>
<br>
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
> -)<br>
<br>
<br><br><div><span class="gmail_quote">On 4/29/09, <b class="gmail_sendername">Mark \
Hahn</b> <<a href="mailto:hahn@mcmaster.ca">hahn@mcmaster.ca</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;"> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think the term ´node¡ is a loaded term in HPC. This is what comes<br>
</blockquote></blockquote>
<br>
I think it's just a bit sloppy or at least contextual - I've never<br>
heard it used for anything other than "box". a node on a conventional<br>
message-passing cluster is clearly one computer, which may contain
multiple cores, but has a single memory domain. on an
Origin/Altix,<br>
people seem to prefer "brick", but sometimes use "node", and is \
obviously<br> not a single memory domain. MPI programmers usually use \
"rank" or<br> "processor", and don't get hung up on \
nodes.<span class="q"><br> <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> There is an awful lot of software \
around which refers to "nodes" when in<br> your nomenclature it means \
core[1], most of it harks back to when nodes<br> </blockquote>
<br></span>
hmm, a contrary example is gromacs - it explicitly talks about nodes<br>
but permits threads within a node. ie, an 8-core box could be a single<br>
node with 8 threads or 8 nodes, 1th each.<br>
<br>
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?)<span class="q"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> had one CPU and a CPU had one core. \
Even the concept of cores<br> themselves are only six or seven years old, before then \
a CPU was just a<br> CPU and you would refer to "a N CPU cluster".<br>
</blockquote>
<br></span>
and to be on the safe side (wrt forms of simultaneous multi-threading),<br>
we should probably try to use "thread" instead. meaning a single hardware \
execution context.<br>_______________________________________________<br> Beowulf \
mailing list, <a onclick="return top.js.OpenExtLink(window,event,this)" \
href="mailto:Beowulf@beowulf.org">Beowulf@beowulf.org</a> sponsored by Penguin \
Computing<br> To change your subscription (digest mode or unsubscribe) visit <a \
onclick="return top.js.OpenExtLink(window,event,this)" \
href="http://www.beowulf.org/mailman/listinfo/beowulf" \
target="_blank">http://www.beowulf.org/mailman/listinfo/beowulf</a><br>
<br></blockquote></div><br>
_______________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic