Dear all, some of you may be aware of the BOINC client shipping with Debian, Ubuntu, Mint and the other .deb-based Linux distributions [1]. While updating to 7.6.32 we have revised our invocation of the Link Time Optimisation (LTO) [2]. This had the effect of a notable reduction of the disk-space occupied by the (stripped) binaries:
previous revised change 7.6.31 7.6.32 1292528 932032 -28% /usr/bin/boinc 34904 30864 -16% /usr/bin/boinccmd 3657424 2292936 -37% /usr/bin/boincmgr 26464 26464 0% /usr/lib/x86_64-linux-gnu/libboinc_crypt.so.7.6.32 665960 665960 0% /usr/lib/x86_64-linux-gnu/libboinc.so.7.6.32 467392 467392 0% /usr/lib/x86_64-linux-gnu/libboinc_zip.so.7.6.32 We cannot assess the effect on BOINC. But we reckon that the effort to quickly bring BOINC functionality into action and then hide it again is likely proportional to the reduction of the code base. LTO is also know to help the computation - not surprisingly so since less code needs to be processed for the same functionality. Completely ignorant of the complexity of the BOINC benchmark, we just went and checked *boinccmd --run_benchmarks* with the following results: v7.6.31 (prior to revision) 09-May-2016 03:39:53 [---] 3973 floating point MIPS (Whetstone) per CPU 09-May-2016 03:39:53 [---] 17322 integer MIPS (Dhrystone) per CPU 09-May-2016 03:42:22 [---] 4087 floating point MIPS (Whetstone) per CPU 09-May-2016 03:42:22 [---] 17774 integer MIPS (Dhrystone) per CPU 09-May-2016 03:43:17 [---] 4069 floating point MIPS (Whetstone) per CPU 09-May-2016 03:43:17 [---] 17988 integer MIPS (Dhrystone) per CPU v7.6.32 (after revision) 09-May-2016 03:45:18 [---] 3961 floating point MIPS (Whetstone) per CPU 09-May-2016 03:45:18 [---] 78155 integer MIPS (Dhrystone) per CPU 09-May-2016 03:46:35 [---] 4057 floating point MIPS (Whetstone) per CPU 09-May-2016 03:46:35 [---] 76289 integer MIPS (Dhrystone) per CPU 09-May-2016 03:48:42 [---] 3962 floating point MIPS (Whetstone) per CPU 09-May-2016 03:48:42 [---] 76374 integer MIPS (Dhrystone) per CPU We tried two different computers with equivalent quadruplication of the integer performance only. The change is the same as for v7.6.32 without the LTO corrections, which vividly demonstrates how sensitive the LTO compiler flags are. The -flto flags we had first added one or two years ago. Expected was to observe a 20% speedup that is frequently reported for LTO. Without further investigation, the 300% we consider to be somehow explainable - with hindsight - such that the application could be optimised in a way that it is also faster for regular compilation. But why bother if LTO has become so usable. And helpful. And controllable by merely looking at what it does to the disk footprint. This email has two messages: * If using the Debian client already, please update to 7.6.32 that is now in Debian unstable and comes to you any time soon. It reduces the memory footprint, which helps the scientific app, a bit, and because of an astonishing effect on the benchmark, this also helps your RAC. (This is until BOINC developers adopt LTO also for their publicly offered builds.) * It hopes to be an eye opener. The scientific applications are the ones that should all adopt LTO. It is working, also for static binaries. But expect a 20% speedup, not as much as with the client's benchmarks. Keep crunching Gianfranco and Steffen [1] https://wiki.debian.org/BOINC [2] https://gcc.gnu.org/onlinedocs/gccint/LTO.html#LTO _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
