first post introduction and question regarding lto
Hello This is my first post after I just have subscribed to the Python-Dev mailing list. In this context, the welcome confirmation message suggested to introduce myself. My name is Octavian Soldea and I am with the Python optimization team in DSLOT group in Intel, Santa Clara, California. In the past I have received a PhD in Computer Science from the Technion, Israel Institute of Technology in Computer Vision. I would like to ask regarding the possibility of compiling Python with lto only. My question is if is the community interested to enable the possibility of compiling Python with lto only, i.e. without pgo? I have followed https://bugs.python.org/issue29243 and https://bugs.python.org/issue29641 however, it is not clear if the separate compilation is already implemented. In my opinion this is a good option since pgo is not always desired. Best regards, Octavian
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter. I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments. If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in targets as well as updating the help text for --with-lto in configure.ac. [untested] -gps On Mon, Aug 7, 2017 at 12:00 PM Soldea, Octavian <octavian.soldea@intel.com> wrote:
Hello
This is my first post after I just have subscribed to the Python-Dev mailing list. In this context, the welcome confirmation message suggested to introduce myself.
My name is Octavian Soldea and I am with the Python optimization team in DSLOT group in Intel, Santa Clara, California. In the past I have received a PhD in Computer Science from the Technion, Israel Institute of Technology in Computer Vision.
I would like to ask regarding the possibility of compiling Python with lto only. My question is if is the community interested to enable the possibility of compiling Python with lto only, i.e. without pgo? I have followed
https://bugs.python.org/issue29243
and
https://bugs.python.org/issue29641
however, it is not clear if the separate compilation is already implemented. In my opinion this is a good option since pgo is not always desired.
Best regards,
Octavian _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
Hello Gregory: Thank you for your message. I really appreciate it. In my opinion the use of lto only compilation mode can be of benefit from two reasons at least: 1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific. 2. Lto compilation is faster than an entire pgo + lto mode. While pgo can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto. In this context, I will be more than happy to receive more feedback and opinions. Best regards, Octavian From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter. I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments. If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in<http://Makefile.pre.in> targets as well as updating the help text for --with-lto in configure.ac<http://configure.ac>. [untested] -gps Python-Dev mailing list Python-Dev@python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
I don't think that PGO compilation itself is slow. Basically, I expect that it only doubles the compilation time, but compiling Python takes less than 1 minute usually. The slow part is the profiling task: run the full Python test suite, which takes at least 20 minutes. The tests must be run sequentially. It would help to reduce the number of tests run in the profiling task. We should also maybe skip tests which depend too much on I/O to get more reproductible PGO performances. Victor 2017-08-08 1:01 GMT+02:00 Soldea, Octavian <octavian.soldea@intel.com>:
Hello
Gregory: Thank you for your message. I really appreciate it.
In my opinion the use of lto only compilation mode can be of benefit from two reasons at least:
1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific.
2. Lto compilation is faster than an entire pgo + lto mode. While pgo can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto.
In this context, I will be more than happy to receive more feedback and opinions.
Best regards,
Octavian
From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter.
I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments.
If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in targets as well as updating the help text for --with-lto in configure.ac. [untested]
-gps
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
We evaluated different tests before setting down and proposing regrtest suite for PGO training, including using OpenStack benchmarks for OpenStack applications. The regrtest suite was found consistently giving the best in terms of performance across applications/workloads. So I would hesitate to remove any test from the training suite (for the purpose of reducing build time), unless we are absolute sure it will not hurt performance across the board. Thanks, Peter -----Original Message----- From: Python-Dev [mailto:python-dev-bounces+peter.xihong.wang=intel.com@python.org] On Behalf Of Victor Stinner Sent: Monday, August 07, 2017 4:43 PM To: Soldea, Octavian <octavian.soldea@intel.com> Cc: Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto I don't think that PGO compilation itself is slow. Basically, I expect that it only doubles the compilation time, but compiling Python takes less than 1 minute usually. The slow part is the profiling task: run the full Python test suite, which takes at least 20 minutes. The tests must be run sequentially. It would help to reduce the number of tests run in the profiling task. We should also maybe skip tests which depend too much on I/O to get more reproductible PGO performances. Victor 2017-08-08 1:01 GMT+02:00 Soldea, Octavian <octavian.soldea@intel.com>:
Hello
Gregory: Thank you for your message. I really appreciate it.
In my opinion the use of lto only compilation mode can be of benefit from two reasons at least:
1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific.
2. Lto compilation is faster than an entire pgo + lto mode. While pgo can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto.
In this context, I will be more than happy to receive more feedback and opinions.
Best regards,
Octavian
From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter.
I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments.
If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in targets as well as updating the help text for --with-lto in configure.ac. [untested]
-gps
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gm ail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel...
Hello Thank you for your messages. I am not quite sure I understood, therefore, I would like to ask if you see beneficial to have the option of lto separately? Best regards, Octavian -----Original Message----- From: Wang, Peter Xihong Sent: Monday, August 7, 2017 5:00 PM To: Victor Stinner <victor.stinner@gmail.com>; Soldea, Octavian <octavian.soldea@intel.com> Cc: Python-Dev@python.org Subject: RE: [Python-Dev] first post introduction and question regarding lto We evaluated different tests before setting down and proposing regrtest suite for PGO training, including using OpenStack benchmarks for OpenStack applications. The regrtest suite was found consistently giving the best in terms of performance across applications/workloads. So I would hesitate to remove any test from the training suite (for the purpose of reducing build time), unless we are absolute sure it will not hurt performance across the board. Thanks, Peter -----Original Message----- From: Python-Dev [mailto:python-dev-bounces+peter.xihong.wang=intel.com@python.org] On Behalf Of Victor Stinner Sent: Monday, August 07, 2017 4:43 PM To: Soldea, Octavian <octavian.soldea@intel.com> Cc: Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto I don't think that PGO compilation itself is slow. Basically, I expect that it only doubles the compilation time, but compiling Python takes less than 1 minute usually. The slow part is the profiling task: run the full Python test suite, which takes at least 20 minutes. The tests must be run sequentially. It would help to reduce the number of tests run in the profiling task. We should also maybe skip tests which depend too much on I/O to get more reproductible PGO performances. Victor 2017-08-08 1:01 GMT+02:00 Soldea, Octavian <octavian.soldea@intel.com>:
Hello
Gregory: Thank you for your message. I really appreciate it.
In my opinion the use of lto only compilation mode can be of benefit from two reasons at least:
1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific.
2. Lto compilation is faster than an entire pgo + lto mode. While pgo can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto.
In this context, I will be more than happy to receive more feedback and opinions.
Best regards,
Octavian
From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter.
I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments.
If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in targets as well as updating the help text for --with-lto in configure.ac. [untested]
-gps
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gm ail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel...
I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac and Makefile.pre.in to make such a change. -@gpshead On Mon, Aug 7, 2017 at 5:08 PM Soldea, Octavian <octavian.soldea@intel.com> wrote:
Hello
Thank you for your messages. I am not quite sure I understood, therefore, I would like to ask if you see beneficial to have the option of lto separately?
Best regards, Octavian
-----Original Message----- From: Wang, Peter Xihong Sent: Monday, August 7, 2017 5:00 PM To: Victor Stinner <victor.stinner@gmail.com>; Soldea, Octavian < octavian.soldea@intel.com> Cc: Python-Dev@python.org Subject: RE: [Python-Dev] first post introduction and question regarding lto
We evaluated different tests before setting down and proposing regrtest suite for PGO training, including using OpenStack benchmarks for OpenStack applications. The regrtest suite was found consistently giving the best in terms of performance across applications/workloads.
So I would hesitate to remove any test from the training suite (for the purpose of reducing build time), unless we are absolute sure it will not hurt performance across the board.
Thanks,
Peter
-----Original Message----- From: Python-Dev [mailto:python-dev-bounces+peter.xihong.wang= intel.com@python.org] On Behalf Of Victor Stinner Sent: Monday, August 07, 2017 4:43 PM To: Soldea, Octavian <octavian.soldea@intel.com> Cc: Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto
I don't think that PGO compilation itself is slow. Basically, I expect that it only doubles the compilation time, but compiling Python takes less than 1 minute usually. The slow part is the profiling task: run the full Python test suite, which takes at least 20 minutes. The tests must be run sequentially.
It would help to reduce the number of tests run in the profiling task. We should also maybe skip tests which depend too much on I/O to get more reproductible PGO performances.
Victor
Hello
Gregory: Thank you for your message. I really appreciate it.
In my opinion the use of lto only compilation mode can be of benefit from two reasons at least:
1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific.
2. Lto compilation is faster than an entire pgo + lto mode. While
2017-08-08 1:01 GMT+02:00 Soldea, Octavian <octavian.soldea@intel.com>: pgo
can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto.
In this context, I will be more than happy to receive more feedback and opinions.
Best regards,
Octavian
From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter.
I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments.
If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in targets as well as updating the help text for --with-lto in configure.ac. [untested]
-gps
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gm ail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel... _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
Hi Gregory Thank you for your message. I will conduct several experiments and try to come back as soon as possible with a conclusion. Best regards, Octavian From: Gregory P. Smith [mailto:greg@krypto.org] Sent: Monday, August 7, 2017 5:13 PM To: Soldea, Octavian <octavian.soldea@intel.com>; Wang, Peter Xihong <peter.xihong.wang@intel.com>; Victor Stinner <victor.stinner@gmail.com> Cc: Python-Dev@python.org Subject: Re: [Python-Dev] first post introduction and question regarding lto I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac<http://configure.ac> and Makefile.pre.in<http://Makefile.pre.in> to make such a change. -@gpshead On Mon, Aug 7, 2017 at 5:08 PM Soldea, Octavian <octavian.soldea@intel.com<mailto:octavian.soldea@intel.com>> wrote: Hello Thank you for your messages. I am not quite sure I understood, therefore, I would like to ask if you see beneficial to have the option of lto separately? Best regards, Octavian -----Original Message----- From: Wang, Peter Xihong Sent: Monday, August 7, 2017 5:00 PM To: Victor Stinner <victor.stinner@gmail.com<mailto:victor.stinner@gmail.com>>; Soldea, Octavian <octavian.soldea@intel.com<mailto:octavian.soldea@intel.com>> Cc: Python-Dev@python.org<mailto:Python-Dev@python.org> Subject: RE: [Python-Dev] first post introduction and question regarding lto We evaluated different tests before setting down and proposing regrtest suite for PGO training, including using OpenStack benchmarks for OpenStack applications. The regrtest suite was found consistently giving the best in terms of performance across applications/workloads. So I would hesitate to remove any test from the training suite (for the purpose of reducing build time), unless we are absolute sure it will not hurt performance across the board. Thanks, Peter -----Original Message----- From: Python-Dev [mailto:python-dev-bounces+peter.xihong.wang<mailto:python-dev-bounces%2Bpeter.xihong.wang>=intel.com@python.org<mailto:intel.com@python.org>] On Behalf Of Victor Stinner Sent: Monday, August 07, 2017 4:43 PM To: Soldea, Octavian <octavian.soldea@intel.com<mailto:octavian.soldea@intel.com>> Cc: Python-Dev@python.org<mailto:Python-Dev@python.org> Subject: Re: [Python-Dev] first post introduction and question regarding lto I don't think that PGO compilation itself is slow. Basically, I expect that it only doubles the compilation time, but compiling Python takes less than 1 minute usually. The slow part is the profiling task: run the full Python test suite, which takes at least 20 minutes. The tests must be run sequentially. It would help to reduce the number of tests run in the profiling task. We should also maybe skip tests which depend too much on I/O to get more reproductible PGO performances. Victor 2017-08-08 1:01 GMT+02:00 Soldea, Octavian <octavian.soldea@intel.com<mailto:octavian.soldea@intel.com>>:
Hello
Gregory: Thank you for your message. I really appreciate it.
In my opinion the use of lto only compilation mode can be of benefit from two reasons at least:
1. Lto only can provide a platform for experimentations. Of course, it seems to be very application specific.
2. Lto compilation is faster than an entire pgo + lto mode. While pgo can take a lot of time, lto can provide significant optimizations, as compared to baseline, at the cost of less compilation time. Of course, lto is time consuming. To the best of my knowledge, compiling with lto only is shorter than combining pgo and lto.
In this context, I will be more than happy to receive more feedback and opinions.
Best regards,
Octavian
From: Gregory P. Smith [mailto:greg@krypto.org<mailto:greg@krypto.org>] Sent: Monday, August 7, 2017 3:12 PM To: Soldea, Octavian <octavian.soldea@intel.com<mailto:octavian.soldea@intel.com>>; Python-Dev@python.org<mailto:Python-Dev@python.org> Subject: Re: [Python-Dev] first post introduction and question regarding lto
I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter.
I have no problem with patches enabling an LTO only build for anyone who wants one if they do not already exist. At the moment I'm not sure which LTO toolchains actually work properly. We removed it from inclusion in --enable-optimizations because it was clearly broken in some common environments.
If LTO without PGO is useful, making it work is probably just a matter of making sure @LTOFLAGS@ show up on the non-PGO related Makefile.pre.in<http://Makefile.pre.in> targets as well as updating the help text for --with-lto in configure.ac<http://configure.ac>. [untested]
-gps
Python-Dev mailing list Python-Dev@python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
_______________________________________________ Python-Dev mailing list Python-Dev@python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gm ail.com<http://ail.com>
_______________________________________________ Python-Dev mailing list Python-Dev@python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/peter.xihong.wang%40intel... _______________________________________________ Python-Dev mailing list Python-Dev@python.org<mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
On 8 August 2017 at 10:12, Gregory P. Smith <greg@krypto.org> wrote:
I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac and Makefile.pre.in to make such a change.
Being able to separate them seems useful even if it's just from the performance research perspective of comparing "PGO only", "LTO only" and "PGO+LTO". The LTO only numbers may be of questionable relevance to us as CPython developers, but I can definitely see them being of interest to the folks working on C compiler toolchains. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, 9 Aug 2017 13:36:28 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 8 August 2017 at 10:12, Gregory P. Smith <greg@krypto.org> wrote:
I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac and Makefile.pre.in to make such a change.
Being able to separate them seems useful even if it's just from the performance research perspective of comparing "PGO only", "LTO only" and "PGO+LTO".
That does not mean "LTO only" deserves a configure option, though. PGO is difficult to set up manually so it's fair that we provide dedicated build support for it. LTO should just be a matter of tweaking CFLAGS and LDFLAGS. Regards Antoine.
There is already a ./configure --with-lto flag, why not using it? I'm using --with-lto without PGO for months, I never noticed that the option is fully ignored! Victor 2017-08-09 9:52 GMT+02:00 Antoine Pitrou <solipsis@pitrou.net>:
On Wed, 9 Aug 2017 13:36:28 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 8 August 2017 at 10:12, Gregory P. Smith <greg@krypto.org> wrote:
I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac and Makefile.pre.in to make such a change.
Being able to separate them seems useful even if it's just from the performance research perspective of comparing "PGO only", "LTO only" and "PGO+LTO".
That does not mean "LTO only" deserves a configure option, though. PGO is difficult to set up manually so it's fair that we provide dedicated build support for it. LTO should just be a matter of tweaking CFLAGS and LDFLAGS.
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.co...
On Wed, 9 Aug 2017 11:16:36 +0200 Victor Stinner <victor.stinner@gmail.com> wrote:
There is already a ./configure --with-lto flag, why not using it?
I'm using --with-lto without PGO for months, I never noticed that the option is fully ignored!
What are the reasons it is ignored? IIRC some compilers have buggy LTO support and it can lead to crashes during compilation. Regards Antoine.
2017-08-09 11:22 GMT+02:00 Antoine Pitrou <solipsis@pitrou.net>:
What are the reasons it is ignored? IIRC some compilers have buggy LTO support and it can lead to crashes during compilation.
Issues with LTO: http://bugs.python.org/issue28032 http://bugs.python.org/issue28605 But since --with-lto is now an opt-in option, I don't why it should ignored when PGO is not used? Victor
On 9 August 2017 at 17:52, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Wed, 9 Aug 2017 13:36:28 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
On 8 August 2017 at 10:12, Gregory P. Smith <greg@krypto.org> wrote:
I don't know whether it is beneficial or not - but having the capability to build LTO without PGO seems reasonable. I can review any pull requests altering configure.ac and Makefile.pre.in to make such a change.
Being able to separate them seems useful even if it's just from the performance research perspective of comparing "PGO only", "LTO only" and "PGO+LTO".
That does not mean "LTO only" deserves a configure option, though. PGO is difficult to set up manually so it's fair that we provide dedicated build support for it. LTO should just be a matter of tweaking CFLAGS and LDFLAGS.
I wouldn't be confident in my own ability to get those right for gcc, let alone getting them right for clang as well. Whereas if the "--with-lto" configure option just works, then I'd never need to worry about it :) It also means that if folks *do* investigate this, it eliminates a class of configuration bugs (i.e. "you didn't actually enable LTO correctly in your testing"). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (6)
-
Antoine Pitrou -
Gregory P. Smith -
Nick Coghlan -
Soldea, Octavian -
Victor Stinner -
Wang, Peter Xihong