[Discuss] I need a recommendation for a Linux-compatible high-end PC builder

pw p.willis at telus.net
Fri Jan 12 20:06:07 PST 2018


On 2018-01-12 03:51 PM, Alan W. Irwin wrote:
> On 2018-01-12 07:01-0800 pw wrote:
> 
>> Is GNU 'make' compiled with OpenMPI/MPICH these days?
> >....  they apparently don't use MPI in this
> implementation so the result only works for single computers and
> not clusters.


I downloaded the most recent GNU make source. The important file in this
context is 'jobs.c' which does all the queueing of recipes to the 
'jobserver'.  There is no MPI or MPICH involved there at all.
The ideology behind the jobserver approach was to keep parallel build
code as simple as possible with only operating system related
dependencies. Thus, pipes and RPC as POSIX like as possible.


> After drawing that conclusion last night, I did find the distmake
> project <https://sourceforge.net/projects/distmake/> which apparently
> implements exactly what I need with the caveat that all computers have
> to mount the relevant source and build trees using NFS. It is not
> stated exactly this way, but I think you should think of distmake as a
> simple load balancer for GNU make tasks across NFS-connected
> computers.
> 
> Some concerns for me with this approach are the following:
> 
> * distmake development stopped in 2006, but others keep
>    downloading it (thousands of downloads since then) which is a good
>    sign.
> 
> * Compatibility between cmake (which simply configures GNU-make
>    compatible Makefiles) and distmake might be an issue.  My guess is
>    everything is OK in that regard since I believe distmake only sets
>    up servers to control what GNU-make does without interfering with
>    GNU-make at all. But it would be good to get that confirmed
>    by someone with combined cmake and distmake experience.
> 
> * The NFS security configuration and security concerns.  More than
>    a decade ago I did have two computers set up with NFS, but I
>    never liked it that much, and it was buggy/insecure back then.

NFS can be quite slow even over gigabit ethernet when compared to direct 
disk access. Not my favorite for fast disk access.


> * The system admin tasks for 5 M3's will be at least quintupled which
>    is likely my principal concern with this idea.


> So for now, I am going to keep this distmake idea for NFS-connected
> computers in mind, but I do have some cold feet about it. 

You could also try GNU 'Parallel' command which can distribute processes 
over multiple computers.

https://www.gnu.org/software/parallel/

I'm not particularly familiar with it.

> Therefore, if
> instead a nice ARM-based "Green" solution pops up for one computer
> with 64 cores whose total power use is less than ~50 watts, I would buy 
> that system in a heartbeat (primarily because it would simplify my sysadmin
> life so much and also simplify my development since the -j option for
> GNU make should "just work" up to -j64 or so for such a single system.
>

I'm not so sure how 'green' ARM is compared to anything else. The power
usage is less but how much work do you get done? Not everything can run 
on a phone. Also, the materials represent a huge environmental cost.
AMD CPUs will also run on a wind turbine of solar panel.


> So, Peter, you have already dug up one reference to a single ARM-based
> system that had considerably more than the 8 cores on the M3, but
> there were no monetary or power costs I could find for that system. So 
> if you could find those or it you find other ARM-based single
> computer systems with lots of cores that consume little total power,
> please let me know.
> 

That chip is vaporware so far. It was only introduced in November 2017.
Vendors would need to design hardware. It is a system on chip (SOC), 
which will make design easier, but it's expensive for designers to
work up systems from scratch.


I'm always on the hunt for the next better tech. I will certainly
give you a heads up if I see anything.

I really like the idea of using a bunch of $39 Pi devices as a
cluster. But my attentions are pretty divided. Even though much
easier methods for making every application massively parallel
could be put to use most of my personal applications end up being
multi-threaded at best.

P



More information about the Discuss mailing list