#13634 closed enhancement (fixed)
nss: do not force -j1
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | 10.0 |
Component: | BOOK | Version: | SVN |
Severity: | normal | Keywords: | |
Cc: |
Description ¶
As noted in the ticket for 3.53,
When using the Makefiles, NSS can be built in parallel, speeding up those builds to more similar performance as the build.sh/ninja/gyp system. (Bug 290526)
Therefore, stop forcing -j1 and remeasure for parallelism=4 for the build (unfortunately, tests seem to be single-threaded).
Change History (9)
comment:1 by , 5 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 5 years ago
follow-up: 4 comment:3 by , 5 years ago
I'm not sure what's causing this. I took the measurements on my development system, which is a Intel Core i5 machine (Skylake - i5-6600k).
Note that I don't run this build off an SSD, but rather a 1TB HDD. I don't have the money laying around to buy another SSD, although last time I did install LFS onto one I had an SBU value decrease of about 4 seconds (this was in the GCC-9.1 days though).
Note that I haven't tried at -j4 :)
For what it's worth, here's my script (and the /usr/src/stats file that this references). This is for the update, with tests. The notests script just has the tests here commented out. A DESTDIR= build is run because we're looking for build size + installed files size (what you'll have after running 'make install', prior to deleting your source directory):
#!/bin/bash source /usr/src/stats #################### VERSION=3.53 DIR=`pwd` PROGRAM=nss-${VERSION} LOG=$DIR/$PROGRAM.log TITLE=$PROGRAM TIMEFORMAT="$TIMEFMT $TITLE" BUILDDIR=/sources/$PROGRAM DEST=$BUILDDIR/install SUDO= rm -f $LOG rm -f $BUILDDIR mkdir $BUILDDIR cd $BUILDDIR before=`df -k /sources | grep / | sed -e "s/ \{2,\}/ /g" | cut -d' ' -f3` tar -xf $DIR/${PROGRAM}.tar.gz || exit 1 cd $PROGRAM { time \ { echo Making $TITLE date patch -Np1 -i $DIR/nss-3.53-standalone-1.patch && cd nss && make BUILD_OPT=1 \ NSPR_INCLUDE_DIR=/usr/include/nspr \ USE_SYSTEM_ZLIB=1 \ NSS_ENABLE_WERROR=0 \ ZLIB_LIBS=-lz \ $([ $(uname -m) = x86_64 ] && echo USE_64=1) \ $([ -f /usr/include/sqlite3.h ] && echo NSS_USE_SYSTEM_SQLITE=1) -j1 && cd tests && HOST=localhost DOMSUF=localdomain ./all.sh | tee $DIR/nss-$VERSION-tests.log && cd ../ echo "BLFS Start INSTALL" && cd ../dist && mkdir -pv $DEST/usr/{lib/pkgconfig,include,bin} && $SUDO install -v -m755 Linux*/lib/*.so $DEST/usr/lib && $SUDO install -v -m644 Linux*/lib/{*.chk,libcrmf.a} $DEST/usr/lib && $SUDO install -v -m755 -d $DEST/usr/include/nss && $SUDO cp -v -RL {public,private}/nss/* $DEST/usr/include/nss && $SUDO chmod -v 644 $DEST/usr/include/nss/* && $SUDO install -v -m755 Linux*/bin/{certutil,nss-config,pk12util} $DEST/usr/bin && $SUDO install -v -m644 Linux*/lib/pkgconfig/nss.pc $DEST/usr/lib/pkgconfig } } 2>&1 | tee -a $LOG if [ $PIPESTATUS -ne 0 ]; then exit 1; fi; stats $LOG $DIR/${PROGRAM}.tar.gz $before exit 0
renodr [ /sources ]$ cat /usr/src/stats #!/bin/bash function stats() { log=$1 tarball=$2 b4=$3 base_sbu=100 free_now=`df -k /sources | grep / | sed -e "s/ \{2,\}/ /g" | cut -d" " -f3` buildtime=`tail -n1 $log|cut -f1 -d" "` sbu=`echo "scale=3; $buildtime / $base_sbu" | bc` psizeK=`du -k $tarball | cut -f1` psizeM=`echo "scale=3; $psizeK / 1024" | bc` bsizeK=`echo "$free_now - $b4" | bc` bsizeM=`echo "scale=3; $bsizeK / 1024" | bc` echo "SBU=$sbu" | tee -a $log echo "$psizeK $tarball size ($psizeM MB)" | tee -a $log echo "$bsizeK kilobytes build size ($bsizeM MB)" | tee -a $log (echo -n "md5sum : "; md5sum $tarball) | tee -a $log (echo -n "sha1sum: "; sha1sum $tarball) | tee -a $log } TIMEFMT='%1R Elasped Time -' SUDO='sudo -E' ARCH=$(uname -m) PLATFORM=systemd
comment:4 by , 5 years ago
Replying to renodr:
I'm not sure what's causing this. I took the measurements on my development system, which is a Intel Core i5 machine (Skylake - i5-6600k).
Note that I don't run this build off an SSD, but rather a 1TB HDD. I don't have the money laying around to buy another SSD, although last time I did install LFS onto one I had an SBU value decrease of about 4 seconds (this was in the GCC-9.1 days though).
Note that I haven't tried at -j4 :)
For what it's worth, here's my script (and the /usr/src/stats file that this references). This is for the update, with tests. The notests script just has the tests here commented out. A DESTDIR= build is run because we're looking for build size + installed files size (what you'll have after running 'make install', prior to deleting your source directory):
Thanks for those details. If I'm reading correctly, your SBU is 100 seconds ? That might go a long way to flattering my SBU for the tests if they typically take a similar amount of time.
I've been building in /tmp, and I use du to measure the build and DESTDIR rather than measuring changed space on the filesystem. Will give this a go on my SSD to see if that varies.
comment:6 by , 5 years ago
Completed a j1 build followed by tests. The tests took about 30 seconds longer, but for me they still round to 20 SBU. Interestingly, this time the build used 299 MB, which is an extra 118 MB for the tests compared to my initial build. Will use these figures.
Tests completed in 38m53,
I'm quoting that because my measurements are very different from what is in the book for -j1.
I can appreciate that my SBU measurements may differ (this is a ryzen and it seems to have become very slow on this gcc-10 build, an SBU is now 117.868 seconds), but what I've got for space is:
build and install without tests: build 281MB, install 7.5MB, rounds to 288MB. then run the tests: build is now 393MB i.e. +112 MB.
j4 build and DESTDIR install just under 5m15, 2.7 SBU, tests 38m53 or 20 SBU.
For all j1 the book has 291 MB (add 195 MB for tests) and 6.6 SBU (add 37 SBU for tests). What particularly concerns me is the difference in timing and space for the tests, so leaving this pending for a little while in case anyone has any observations. If not, I'll go with my figures.