User: Password:
|
|
Subscribe / Log in / New account

Fedora mulls ARM as a primary architecture

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 13:36 UTC (Thu) by dlang (subscriber, #313)
In reply to: Fedora mulls ARM as a primary architecture by hanwen
Parent article: Fedora mulls ARM as a primary architecture

go read rob landley's blog http://landley.net/notes.html for a peek into the horror story that cross compiling, and even trying to compile with qemu can run into. doing this for an entire distro seems like a risky thing.

That being said, I am amazed that anything more than a one-person distro isn't using distcc or similar to spread the compile load over a farm of machines.

Getting lots of ARM machines for this sort of thing is pretty easy, and power wise is far more efficient than any x86 machine. People make off-the-shelf boxes which have dozens of ARM SoC systems plugged into them. individually they are poor, but as a compile farm they would be very efficient (the final serialized link step would still be a bottleneck, but that's a small part of the overall CPU time)


(Log in to post comments)

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 15:10 UTC (Thu) by rwmj (subscriber, #5474) [Link]

There's no problem using distcc (in fact, it's fairly trivial to add).

The problem is that you get hit by Amdahl's law: single builds are simply not very parallelizable. Recursive Makefiles have to be run sequentially. Even a large project may only have dozens of C files, but to really exploit multicore ARM you need hundreds of parallel tasks. Tests have to run sequentially (at least, they do when using automake). There's a fixed "top and tail" overhead of unpacking the tarball and constructing the final package.

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 15:42 UTC (Thu) by dlang (subscriber, #313) [Link]

The article seemed to be indicating that distcc was receiving almost as much pushback as cross compiling.

as for the "tip and tail" overhead, that's one place where I would say to use a amd64 machine, use it to unpack the tarball onto a network accessible drive and then package up the result. Ideally you do this on the machine providing the network accessible drive so that it's all local I/O.

This isn't going to scale linearly with the number of machines for any one package build, but there are a LOT of packages that need to be built, so overall you should be able to keep dozens, if not hundreds of cores busy.

Fedora mulls ARM as a primary architecture

Posted Mar 22, 2012 19:33 UTC (Thu) by nix (subscriber, #2304) [Link]

Automake grew support for parallel tests in 1.11.

Fedora mulls ARM - Is tar holding us back?

Posted Mar 25, 2012 3:33 UTC (Sun) by ndye (guest, #9947) [Link]

Amdahl's law [shows up in] a fixed "top and tail" overhead of unpacking the tarball . . .

With horizontal scaling defining the future, should we consider an archive format with a random-access catalog (like ZIP) to replace linear tar? (Just an idea.)

Fedora mulls ARM - Is tar holding us back?

Posted Mar 26, 2012 4:19 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

There's Duplicity[1], but AFAICS, it's gone approximately nowhere so far.

[1]http://duplicity.nongnu.org/new_format.html

Fedora mulls ARM as a primary architecture

Posted Apr 4, 2012 19:53 UTC (Wed) by cmsj (guest, #55014) [Link]

You also hit cmsj's law, which states that all ARM hardware is fundamentally opposed at a sub-atomic level, to the calm and peaceful mental state of sysadmins ;)

(which is to say that all of the currently available ARM hardware is extremely unreliable under continuous duress, and none of the hardware is built for low friction remote management. This will change when ARM servers are a real thing, but for now I welcome the work being done by Linaro folks to enable Ubuntu building ARM packages with qemu!)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds