[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for
From:       drago01 <drago01 () gmail ! com>
Date:       2019-11-10 7:16:10
Message-ID: CAMqY-FcsvHojcGMm0HVh1udPrXB-dr5sy2bKOfy3ER0pV7yKnw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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
> 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.

[Attachment #5 (text/html)]

<br><br>On Sunday, November 10, 2019, Kevin Kofler &lt;<a \
href="mailto:kevin.kofler@chello.at">kevin.kofler@chello.at</a>&gt; \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">Frantisek Zatloukal wrote:<br> &gt; How is statically \
linked libpython hack? It&#39;s just a different way to do<br> &gt; it, isn&#39;t \
it?<br> <br>
It means you are shipping 2 copies of the Python interpreter, one statically <br>
linked into the python3 binary and one as a shared library. This is much <br>
less elegant than shipping a single shared copy of the code.<br>
<br>
You also need to actually build all the code twice to actually get the <br>
performance improvements, because if you just statically link the PIC <br>
objects (built for the shared library) into the binary, the performance will <br>
not noticeably improve.<br>
<br>
&gt; And if toolchain needs some improving, fine, but why should we have lower<br>
&gt; performance and keep waiting on it if there is a solution available right<br>
&gt; now?<br>
<br>
Because sometimes it is better to wait a bit for an elegant solution than to <br>
rush out a quick hack that we then end up stuck with.<br>
<br>
&gt; And size increase? It&#39;s so tiny, I can&#39;t imagine why should that matter \
at<br> &gt; all.<br>
<br>
We are talking about megabytes! That is not tiny at all!<br>
<br></blockquote><div><br></div><div>It is - even ssd storage is reasonably cheap \
nowadays.</div><div>Other changes like &quot;upgrade foo to n+1&quot; are most likely \
also increase size no one seem to care because it&#39;s not that written in the \
change proposal.</div><div><br></div><div>Anyways the performance win here easily \
justifies the tine space increase that no one would notice in practice.  </div>


[Attachment #6 (text/plain)]

_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


[prev in list] [next in list] [prev in thread] [next in thread]