On 2022/10/25 15:02, Mike Hommey wrote:
On Tue, Oct 25, 2022 at 03:01:07PM +0900, Mike Hommey wrote:
On Tue, Oct 25, 2022 at 02:57:23PM +0900, ISHIKAWA,chiaki wrote:
On 2022/10/25 2:48, ISHIKAWA,chiaki wrote:
Build System and Mach Environment
*
Starting with Bug 1746462
<https://bugzilla.mozilla.org/show_bug.cgi?id=1746462>you can use
the mold linker for linking Mozilla Firefox on most Linux
distributions. MacOS support will come shortly.
I tested "mold" for building C-C thunderbird.
I was impressed.
|The I/O speed during linking "libxul", the large libary, is near the
max bandwidth of my local disk setup (on a linux guest within VirtualBox
hosted under Windows 10).
I watched the xosview's disk I/O activity with amusement.
As is described in Bugzilla, then all of a sudden the multiple CPU's got
busy (I have assigned 7 vCPUs to my linux guest and 16GB of memory
assigned) and linking was over.
In contrast, with GNU gold which I have been using, I see prolonged I/O
not near the maximum bandwidth and single CPU getting busy during long
linking.
Of course, the linking is only a small portion of the whole build
process, but it *IS* a lengthy process.
This is a great work.
Keep the good work going!
Chiaki
I think this has a large impact on tryserver.
Before, I have noticed that typical build has a very long tail end of single
CPU usage. This was the long linking process, I think.
I mentioned once on one of the mailing list (or bugzilla?) that the link
ought to get started as early as possible to avoid this.
It seems it was started rather early after all, but slow linking showed this
behavior.
However, with mold, the link process actually ends rather early and such a
tail end of single CPU usage is not visible at all now.
In my local setup where I monitor the compilation through emacs shell
buffer, the verbose output of housechore commands (it seems build was
creating jar files under various directories)
is printed for like several seconds very quickly at the end (very light CPU
consumption way after the burst of heavy parallel usage is gone) and the
build ends then.
I have never seen such end behavior of build before. It used to be a very
long link process at the end and these housechore commands ended well before
link ended.
I believe someone ought to check the job workload profile in the tryserver
once mold becomes widely used.
It can possibly ends the jobs quicker, or the parallel CPU usage and large
memory footprint may impact the farm negatively.
It all depends on the workload profile. In my single build environment, mold
performs very well to my pleasant surprise.
I wonder if it will be available under Windows (!?).
THAT will change the CPU/IO workload of tryserver computer farm.
"tryserver" is using lld, which is not that much slower than mold.
Linking is not what's costly there.
Local builds default to lld too, by the way.
Mike
I should have mentioned the background of my local build.
I wanted to use -gsplit-dwarf option to GCC. Yes, I use gcc to compile
C-C TB, and this necessitated the use of gnu gold.
Using -gsplit-dwarf makes starting gdb makes much, much quicker (on my
local CPU at least a few years ago).
Unfortunately, lld did not produce complete -gdb-index (it initially did
not handle it at all IIRC).
I am not sure if it does today. From a post early last year.
https://groups.google.com/g/llvm-dev/c/hxnPll-6de0
Thus I was forced to use gnu gold for that reason alone.
mold is a complete replacement for this situation (-gsplit-dwarf to the
compiler and linker passed an option to create gdb-index.
I checked and I can use produced binary with gdb without an issue in a
few simple tests.)
For that situation, mold is a life saver.
(BTW, separating the debug info into independent files seems to speed up
gnu gold link time as well. That is why I tolerated the
gnu goldk, but I cannot recall the detailed performance numbers.
I DID compare gnu gold and lld. But I think I reverted to gnu gold to
enjoy the fast gdb startup when -gsplit-dwarf to GCC is used.
The only consternation I experience is, during local mochitest and
xpcshell test, the dumper that prints the stack backtrace does not
understand the split debug symbol files and thus prints numeric
addresses only when MOZ_ASSERT is hit during local test.
VERY OLD dumper script handled it, but a couple of years back, it was
replaced and it no longer handles the split debug symbol file).
For those developers who need to use gdb in edit-compile-debug cycle
often, GCC's -gsplit-dwarf makes the gdb startup very quick and I like it.
Highly recommended, but I know people may not go down to gdb that quite
often.
Even myself, I don't use gdb every day, but when it comes to really
subtle/complex bug, I have to use gdb often repeatedly :-(
(Note: the recent fast CPUs may have made the speedup factor not much
noticeable after all.
The absolute speed of recent CPUs may shrink the initial long time of
gdb without -gsplit-dwarf down to a tolerable level to the owners of
such very fast CPUs.)
I should have mentioned this feature of mold as a complete replacement
for gnu gold from the viewpoint of "-gsplit-dwarf" and necessary
gdb-index creation.
TIA
Chiaki
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/2bf9bc23-41ee-161b-2f41-05f49c934675%40yk.rim.or.jp.
