Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python is 1.3x faster by just adjusting some compiling options for libpython

bugs.python.org

Post reply on HN
Print view View original

31–40 of 105 posts

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#31

Post by dathinab »

derefr wrote: post #15

Doesn’t gVisor require symbol interposition to do its sandboxing thing? (At least, for binaries with static-linked runtimes, like the type Golang produces by default.)

If you have a fully static-linked library you already don't have symbol interposition.

Furthermore this options still allow the thinks you need interposition for, for calls from/to external dynamic linked libraries like libc.

But most important gVisor is based around intercepting system calls (over simplified), for which you don't need symbol interposition.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#32

Post by ineedasername »

rocqua wrote: post #20
stereo wrote: post #3

Text if you don't want to visit Facebook: Summary: Python is 1.3x faster when compiled in a way that re-examines shitty technical decisions from the 1990s. ELF is the executable and shared library format on Linux and other Unixy systems. It comes to us from 1992's Solaris 2.0, from back before even the first season of the X-Files aired. ELF files (like X-Files) are full of barely-understood horrors described only in…

Not sure this is ok copyright wise.

I'm not sure Facebook's privacy intrusions are ok ethically wise. So there's competing value systems at work.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#33

Post by ineedasername »

BurningFrog wrote: post #22

I'm confused. Is this about something I can do to speed up our 3.8 Python code, or about why Python 3.8 is faster than 3.7?

I think it was addressed by python already:

Eventually, someone working on Python (ironically, of all things) noticed this waste of good performance

But It would be good to know when & what versions.

I'm also not sure why this is "ironic". Who else but the experts on python would be more likely to discover this & resolve the issue? Which basically makes the whole thing a non-issue:

Python creators made a choice when creating python. A while later they realized they could improve performance by revisiting that choice.

The tone of the article makes it sound like this was an embarrassing mistake of massive proportions.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#35

Post by ineedasername »

eptcyka wrote: post #8
kevingadd wrote: post #2

Anyone got an archive link? I can't read this without making a Facebook account and signing in

I read it without signing in. The "Not now" link is greyed out and 4 points smaller and not a button. But it's there.

I did the first time around, but then I closed the tab, and when I wanted to go back to look at something in more detail I was blocked unless I signed in. Luckily someone posted the full text in another comment.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#36

Post by jordigh »

CalChris wrote: post #27
jchw wrote: post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read. But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing.…

> I found his no holds barred clarity

Being right is no excuse for being an asshole.

The attitude will appeal to some. It will strike many others in the wrong way and put them on the defensive.

There's no reason to write this way. A concise, well-articulated, non-combative post will appeal to everyone and still convey the same information.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#37

Post by CalChris »

jordigh wrote: post #36
CalChris wrote: post #27

Earlier quoted context omitted.

The OP was writing about a 29 year old design decision, and he wasn’t writing about a person. Design decisions don’t have feelings. I found his no holds barred clarity about something as obscure as dynamic linking namespaces made for an easier if still not easy read. But that said, I don’t think dynamic linking is in the ELF spec. I believe that’s a de facto OS + dev tools thing rather than an ELF spec de jure thing.…

> I found his no holds barred clarity Being right is no excuse for being an asshole. The attitude will appeal to some. It will strike many others in the wrong way and put them on the defensive. There's no reason to write this way. A concise, well-articulated, non-combative post will appeal to everyone and still convey the same information.

I don’t think it’s possible to be an asshole to an inanimate object.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#38

Post by blopker »

For what it's worth, Python 3.10 will add -fno-semantic-interposition when built with --with-optimizations by default. However, the slow down only affects Pythons built with --enabled-shared anyway.

The issue is discussed here [0]. I also attempted to backport the fix to the official Python Docker image [1], but wasn't able to get much traction. I wish this would land since everyone using these images would get an instant speedup.

[0]: https://bugs.python.org/issue38980 [1]: https://github.com/docker-library/python/issues/501

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#39

Post by Twirrim »

Lammy wrote: post #24
jchw wrote: post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

> It has an immensely combative energy for what is not really a charged subject matter. It becomes a charged subject matter when one works at companies like Google and Facebook and gets used to navigating performance reviews.

> It becomes a charged subject matter when one works at companies like Google and Facebook and gets used to navigating performance reviews.

The way things were at Amazon when I was there, posts like this would count against a Principal Engineer promotion. One of the standards engineers are expected to meet is "Respect what has gone before". You don't know the full details of what was going on at the time, you don't know the trade-offs and why, you don't know what they did and didn't know about the situation and what couldn't have been foreseen at the time decisions were made.

Generally speaking people aren't idiots. They do the best they can with what they have, under the circumstances they're operating within, to meet the goals they have.

Almost no one sets out to make a monster impossible to maintain, or with diabolical performance.

Treat it with respect, even while you work to replace it.

Re: Python is 1.3x faster by just adjusting some compiling options for libpython

#40

Post by galangalalgol »

ineedasername wrote: post #28
jchw wrote: post #11

There’s nothing wrong with this post factually, but the tone sucks. It has an immensely combative energy for what is not really a charged subject matter. Like sure. Today, a lot of the historical reasons for things seem silly and irrelevant. At one point, they did not seem silly and irrelevant. For compatibility with stuff sticking around from those days, we get some performance penalties that are not strictly necess…

Agreed. I was trying to find the words for what I was so put off by the article, but you nailed it. The tone made me want to disagree with it just by default. Luckily I 1) recognize that I am not qualified to have an opinion on the technical details and 2) Ruthlessly crush instinctual responses until I've thought them through with less emotion. (most of the time... I'm not robot, or perfect) Someone in a sibling thre…

I read it as a way to make a tedious topic more entertaining. It didn't seem combative at all. I do identify with your desire to disagree with people whose tone I dislike, even if I intellectually think they are right. I wish I could turn that off.
Post reply on HN