Re: [boinc_dev] Astonishing effect of Link Time Optimisation on BOINC client
BTW, only the floating-point benchmarks are used by BOINC (for runtime estimation and credit calculation). Those didn't change much. -- David On 5/9/2016 3:07 AM, Steffen Möller wrote: 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 3490430864 -16% /usr/bin/boinccmd 3657424 2292936 -37% /usr/bin/boincmgr 26464264640% /usr/lib/x86_64-linux-gnu/libboinc_crypt.so.7.6.32 665960 6659600% /usr/lib/x86_64-linux-gnu/libboinc.so.7.6.32 467392 4673920% /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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
Re: [boinc_dev] Astonishing effect of Link Time Optimisation on BOINC client
Doesn't the formal definition of the benchmarks (both Dhrystone and Whetstone) attempt to exclude compiler optimisations? OK, so we've already broken that principle by allowing optimisation in the Android benchmark code, but I think that it would be wise to evaluate the effect of LTO on a sample Linux project science applications, before distorting the x86 operating system balance in this way. You raise the dread word "credit". It is possible to distort the supposed definition of the cobblestone in various ways, by optimising or dis-optimising either the benchmark code, the scientific application code, or both. Rather than making unilateral changes, wouldn't it be better to have a proper review of the now rather elderly CreditNew framework? On Monday, 9 May 2016, 11:07, Steffen Möllerwrote: 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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. ___ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
[boinc_dev] Astonishing effect of Link Time Optimisation on BOINC client
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 3490430864 -16% /usr/bin/boinccmd 3657424 2292936 -37% /usr/bin/boincmgr 26464264640% /usr/lib/x86_64-linux-gnu/libboinc_crypt.so.7.6.32 665960 6659600% /usr/lib/x86_64-linux-gnu/libboinc.so.7.6.32 467392 4673920% /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 boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.