From fedora-devel-list Sun Nov 10 07:16:10 2019 From: drago01 Date: Sun, 10 Nov 2019 07:16:10 +0000 To: fedora-devel-list Subject: Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for Message-Id: X-MARC-Message: https://marc.info/?l=fedora-devel-list&m=157337021123841 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1297826215748325538==" --===============1297826215748325538== Content-Type: multipart/alternative; boundary="00000000000025341b0596f8ca66" --00000000000025341b0596f8ca66 Content-Type: text/plain; charset="UTF-8" On Sunday, November 10, 2019, Kevin Kofler wrote: > Frantisek Zatloukal wrote: > > How is statically linked libpython hack? It's just a different way to do > > it, isn't it? > > It means you are shipping 2 copies of the Python interpreter, one > statically > linked into the python3 binary and one as a shared library. This is much > less elegant than shipping a single shared copy of the code. > > You also need to actually build all the code twice to actually get the > performance improvements, because if you just statically link the PIC > objects (built for the shared library) into the binary, the performance > will > not noticeably improve. > > > And if toolchain needs some improving, fine, but why should we have lower > > performance and keep waiting on it if there is a solution available right > > now? > > Because sometimes it is better to wait a bit for an elegant solution than > to > rush out a quick hack that we then end up stuck with. > > > And size increase? It's so tiny, I can't imagine why should that matter > at > > all. > > We are talking about megabytes! That is not tiny at all! > > It is - even ssd storage is reasonably cheap nowadays. Other changes like "upgrade foo to n+1" are most likely also increase size no one seem to care because it's not that written in the change proposal. Anyways the performance win here easily justifies the tine space increase that no one would notice in practice. --00000000000025341b0596f8ca66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sunday, November 10, 2019, Kevin Kofler <kevin.kofler@chello.at> wrote:
Frantisek Zatloukal wrote:
> How is statically linked libpython hack? It's just a different way= to do
> it, isn't it?

It means you are shipping 2 copies of the Python interpreter, one staticall= y
linked into the python3 binary and one as a shared library. This is much less elegant than shipping a single shared copy of the code.

You also need to actually build all the code twice to actually get the
performance improvements, because if you just statically link the PIC
objects (built for the shared library) into the binary, the performance wil= l
not noticeably improve.

> And if toolchain needs some improving, fine, but why should we have lo= wer
> performance and keep waiting on it if there is a solution available ri= ght
> now?

Because sometimes it is better to wait a bit for an elegant solution than t= o
rush out a quick hack that we then end up stuck with.

> And size increase? It's so tiny, I can't imagine why should th= at matter at
> all.

We are talking about megabytes! That is not tiny at all!


It is - even ssd storage is reasonably= cheap nowadays.
Other changes like "upgrade foo to n+1"= ; are most likely also increase size no one seem to care because it's n= ot that written in the change proposal.

Anyways th= e performance win here easily justifies the tine space increase that no one= would notice in practice.=C2=A0
--00000000000025341b0596f8ca66-- --===============1297826215748325538== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZGV2ZWwgbWFp bGluZyBsaXN0IC0tIGRldmVsQGxpc3RzLmZlZG9yYXByb2plY3Qub3JnClRvIHVuc3Vic2NyaWJl IHNlbmQgYW4gZW1haWwgdG8gZGV2ZWwtbGVhdmVAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRmVk b3JhIENvZGUgb2YgQ29uZHVjdDogaHR0cHM6Ly9kb2NzLmZlZG9yYXByb2plY3Qub3JnL2VuLVVT L3Byb2plY3QvY29kZS1vZi1jb25kdWN0LwpMaXN0IEd1aWRlbGluZXM6IGh0dHBzOi8vZmVkb3Jh cHJvamVjdC5vcmcvd2lraS9NYWlsaW5nX2xpc3RfZ3VpZGVsaW5lcwpMaXN0IEFyY2hpdmVzOiBo dHRwczovL2xpc3RzLmZlZG9yYXByb2plY3Qub3JnL2FyY2hpdmVzL2xpc3QvZGV2ZWxAbGlzdHMu ZmVkb3JhcHJvamVjdC5vcmcK --===============1297826215748325538==--