Comments on: The End Of The HPC Server (As We Know It) http://www.linux-mag.com/id/7810/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: laytonjb http://www.linux-mag.com/id/7810/#comment-8520 laytonjb Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7810/#comment-8520 <p>Doug,</p> <p>The last several columns have been great! I really enjoy the examination of the traditional higher-power CPUs and the new \"cloud\" oriented lower-power processors. Really cool stuff.</p> <p>I hope your wife understands all the noise when you start cutting up the chips. I recommend a Dremel tool and good work gloves (don\'t forget to ground yourself).</p> <p>Keep them coming!</p> <p>Thanks!</p> <p>Jeff </p> Doug,

The last several columns have been great! I really enjoy the examination of the traditional higher-power CPUs and the new \”cloud\” oriented lower-power processors. Really cool stuff.

I hope your wife understands all the noise when you start cutting up the chips. I recommend a Dremel tool and good work gloves (don\’t forget to ground yourself).

Keep them coming!

Thanks!

Jeff

]]> By: kalloyd http://www.linux-mag.com/id/7810/#comment-8521 kalloyd Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7810/#comment-8521 <p>Doug,</p> <p>The traditional configuration of CPU exclusive nodes with combinations of Ethernet and Infiniband can be \"repurposed\" to management and distribution functions to and between the compute nodes. These \"sergeant\" nodes become intermediaries between the head and compute nodes. </p> <p>The idea is to balance high power consumption with lower duty cycles given the various throughput bandwidths. In other words, it is a balancing act.</p> <p>Oh, and have a good time tweaking the hardware, Sparky!</p> <p>Ken </p> Doug,

The traditional configuration of CPU exclusive nodes with combinations of Ethernet and Infiniband can be \”repurposed\” to management and distribution functions to and between the compute nodes. These \”sergeant\” nodes become intermediaries between the head and compute nodes.

The idea is to balance high power consumption with lower duty cycles given the various throughput bandwidths. In other words, it is a balancing act.

Oh, and have a good time tweaking the hardware, Sparky!

Ken

]]> By: margravezakhur http://www.linux-mag.com/id/7810/#comment-8522 margravezakhur Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7810/#comment-8522 <p>Hmmm,</p> <p>You might want to look at the Cell Broadband Engine. It is too expensive in its current incarnations for most independent developers (now that the OS of the PS3 no longer allows a second OS), but 18 cores with division of labor and 2.5Mb Cache for each core is interesting, especially since the access to main memory has been moved to the software side (where it may belong for purposes of efficiency). The design seems to work rather well, and some HPCs were built off of a single worldly node and a bunch of PS3s not too long ago. </p> Hmmm,

You might want to look at the Cell Broadband Engine. It is too expensive in its current incarnations for most independent developers (now that the OS of the PS3 no longer allows a second OS), but 18 cores with division of labor and 2.5Mb Cache for each core is interesting, especially since the access to main memory has been moved to the software side (where it may belong for purposes of efficiency). The design seems to work rather well, and some HPCs were built off of a single worldly node and a bunch of PS3s not too long ago.

]]> By: x95tobos http://www.linux-mag.com/id/7810/#comment-8523 x95tobos Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7810/#comment-8523 <p>Trying hard not to be rude, but having fuzzy memories on VLSI topics and CPU design, and without ANY pictures of the process, this seems complete BS to me- OK, a good gedanken experiment, in the spirit of Albert Einstein, but I\'ll have to see you using a \"sharp saw\" to cut a chip with submilimeter features like vias and so on, in order to believe it, no matter how good your soldering skills may be. </p> Trying hard not to be rude, but having fuzzy memories on VLSI topics and CPU design, and without ANY pictures of the process, this seems complete BS to me- OK, a good gedanken experiment, in the spirit of Albert Einstein, but I\’ll have to see you using a \”sharp saw\” to cut a chip with submilimeter features like vias and so on, in order to believe it, no matter how good your soldering skills may be.

]]> By: markhahn http://www.linux-mag.com/id/7810/#comment-8524 markhahn Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7810/#comment-8524 <p>isn't the question really about programming models? the Cuda model is pretty clumsy, and I'm guessing Fusion will still have separate x86 and GPU universes. to me, the goal should be to provide a reasonable programming model (x86_64 isn't bad, since no one really pays attention to instruction encoding anymore) that leverages the kind of stackless minicores that GPUs provide. in other words, CPU architects should be asking "how can I add a bunch of lighter-weight threads to _extend_ our conventional architecture". I don't think there's anything magic about how GPUs are implemented except that the omit all the fancy dynamic scheduling, OoO, renaming etc that conventional CPUs use to make non-streaming code go fast. even if there are sticking points (say, CPU and streaming sides differing in how they want to do caching), it seems like there could be fairly simple workarounds (2MB streaming pages?) </p> isn’t the question really about programming models? the Cuda model is pretty clumsy, and I’m guessing Fusion will still have separate x86 and GPU universes. to me, the goal should be to provide a reasonable programming model (x86_64 isn’t bad, since no one really pays attention to instruction encoding anymore) that leverages the kind of stackless minicores that GPUs provide. in other words, CPU architects should be asking “how can I add a bunch of lighter-weight threads to _extend_ our conventional architecture”. I don’t think there’s anything magic about how GPUs are implemented except that the omit all the fancy dynamic scheduling, OoO, renaming etc that conventional CPUs use to make non-streaming code go fast. even if there are sticking points (say, CPU and streaming sides differing in how they want to do caching), it seems like there could be fairly simple workarounds (2MB streaming pages?)

]]>