On Tue, Apr 28, 2015 at 7:31 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
[...snip...]
> FWIW: There is a "neat trick" one can use involving distcc.
>
[...snip...]
> While I've not tried building gcc this way (but might try now with
> --disable-bootstrap) I've found this far faster than compiling inside the
> emulator, and yet easier to maintain than a classic cross-compile
> environment
>
[...snip...]
Some totally NON-scientific results for the curious.
Commands:
/usr/bin/time [...]/gcc-4.9.2/configure \
CC=arm-linux-gnueabihf-gcc-4.9 \
CXX=arm-linux-gnueabihf-g++-4.9 \
--disable-nls --disable-bootstrap --disable-multilib \
--disable-libsanitizer --disable-libcilkrts --disable-libitm \
--enable-languages=c,c++
/usr/bin/time make -j2 all-gcc
System 1: hardware
Raspberry Pi B+ running with 1GHz turbo-mode enabled.
This is a single-core cpu.
gcc tuple = armv6l-unknown-linux-gnueabihf
Running Raspbian (installed at Wheezy and updated to Jessie)
Elapsed configure time: 32 seconds
Elapsed make time: 3hr 42min
System 2: emulator + distcc (
QEMU-emulated guest: "qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -smp 4"
Even though emulating a 4-core cpu, QEMU is single-threaded.
gcc tuple = armv7l-unknown-linux-gnueabihf
Guest is running Ubuntu Utopic
Guest $PATH setup so $CC and $CXX use distcc for ssh-based remote compile
(on a 2-core x86-64 KVM-guest on the same host)
Host: 32-core Opteron at 2.7GHz
Elapsed configure time: 2min 32sec
Elapsed make time: 2hr 14min
So the winner in this race: a split-decision
Because distcc runs configure tests (source file == "conftest.{c,cc}")
locally (meaning in the emulator), the real hardware beat the emulator on
the configure step by a factor of roughly 4.5.
On the "make -j2" step, however, the use of distcc resulted in a nearly
40% reduction in elapsed time.
Note that this set of commands is designed to avoid, as much I could, any
use of the built-compiler.
Results for a full build (with bootstrap and/or builds of the target libs),
would probably produce a different aggregate result because the in-emulator
execution of the just-built compiler will be horribly slow.
The point of the test, other than my curiosity, was to demonstrate that
applying this approach can be genuinely profitable (under
not-entirely-contrived circumstances).
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
_______________________________________________
Gcc-cfarm-users mailing list
Gcc-cfarm-users@gna.org
https://mail.gna.org/listinfo/gcc-cfarm-users
