This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
add parallel support 4 Win32 dmake-uudmap+no 2nd run of config_h.PL part 3
authorDaniel Dragan <bulk88@hotmail.com>
Sat, 15 Aug 2015 09:39:55 +0000 (05:39 -0400)
committerTony Cook <tony@develop-help.com>
Mon, 7 Sep 2015 01:23:57 +0000 (11:23 +1000)
commitc2c7bda0885d19e01f0d998f22d2248d7663e957
tree6398aa4c976f57379b14a59ea3f84b7b4b4a5cfc
parentd89ea36076afa0a17a3faa7cb33a1c9c215a26eb
add parallel support 4 Win32 dmake-uudmap+no 2nd run of config_h.PL part 3

-in $(CONFIGPM) target, remove config_h.PL running dmake again to rebuild
 $(CONFIGPM) target, configpm the script does not use config.h as input.
 The $(CONFIGPM) target is a choke/serialization point for parallel
 building, so it is high value to make it as fast as possible.
 Maybe a long time ago, configpm read config.h but it doesn't anymore.
 Nearly all the dynamic config vars are determined in config_sh.PL script
 and ..\config.sh target. config_h.PL contains very little logic, and this
 logic is only for config.h, and only when you want a var to be different
 in config.h than it is in Config.pm/Config_heavy.pl. Putting a breakpoint
 ("system 'pause';") in config_h.PL, copying Config.pm/Config_heavy.pl to
 ".old" versions, continuing execution in config_h.PL, then diffing the
 2 new Configs with the old 2 Configs before pre-config_h.PL and
 "$(PLMAKE) $(MAKEMACROS) $(CONFIGPM) $(MAKEFILE)" shows no differece.
 When dmake runs needlessly a 2nd time it emits a warning that nothing
 changed. This is intentional, since configpm doesn't update the timestamps
 /update the files if the Config files are identical to the old ones to
 prevent mass clean+rebuild of all modules when nothing global changed.

dmake:  Warning: -- Target [..\lib\Config.pm] was made but the time stamp
has not been updated.

-reduce number of steps to build generate_uudmap.exe.
 Compiling (140 ms on GCC 4.8.3) and linking (561 ms) is heavy weight
 compared to running generate_uudmap.exe (31 ms) and compiling globals.c
 (483 ms). dmake's algo for doing parallel is poor. On the main parallel
 pass with all the mini core .c files compiling ("MINI_OBJ"),
 only generate_uudmap.o will be generated as part of the chain of deps
 hanging off globals.o, after the 1st tier of MINI_OBJ has compiled in
 parallel, dmake will do another sweep of MINI_OBJ, this time it will find
 generate_uudmap.exe node and run linking, at this 2nd tier nothing ran
 except linking generate_uudmap. No parallel anything. This is a
 chokepoint. Then dmake does a 3rd sweep and runs the 3rd tier, which is
 run generate_uudmap.exe, again nothing parallel happens here. By
 combining compiling and linking in 1 target, the time spent serially
 linking generate_uudmap.exe, is moved into parallel time when the rest of
 MINI_OBJ compiles. Also a little bit of CPU and IO is saved by launching
 less processes (less cmd.exe shells, gcc/g++ process ran only once
 (gcc/g++ still run many standalone procs internally but now only 1 gcc
 was started not 2)).

-suppress warnings from dmake with .UPDATEALL, the 3 generated headers
 are made at the same time in real life, in the makefile it was written
 as if they weren't
dmake: Warning:--Found file corresponding to virtual target [..\uudmap.h].
dmake: Warning:--Found file corresponding to virtual target [..\mg_data.h].

-move generating the headers to the target that generates
 generate_uudmap.exe, this moves some serialization time, albeit small
 (30 ms) from right before miniperl link, to parallel time during 1st
 pass of MINI_OBJ

-collapse 3 shell runs of xcopy into 1 run of shell

"timeit cmd /c "cmd /c xcopy /f /r /i /d /y ..\perl.exe ..\t\ && cmd /c
xcopy /f /r /i /d /y ..\perl523.dll ..\t\
&& cmd /c xcopy /f /r /i /d /y ..\perlglob.exe ..\t\"" takes 140 ms

"timeit cmd /c "xcopy /f /r /i /d /y ..\perl.exe ..\t\
&& xcopy /f /r /i /d /y ..\perl523.dll ..\t\
&& xcopy /f /r /i /d /y ..\perlglob.exe ..\t\"" takes 78 ms on my machine
win32/makefile.mk