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

21–30 of 105 posts

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

#21

Post by zitterbewegung »

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 actually seems to miss a few points. (I also agree that the post has not enough levity to balance out the negative tone).

1. PEP 445 makes the use case of LD_PRELOAD irrelevant.

2. A change like this would go under obvious code review and testing to make it into a released version.

3. The risk of a regression would still exist but that can either be caught by #2 or the existing unit testing already in Python.

(Disclaimer: I have contributed to the Python codebase)

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

#24

Post by Lammy »

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.

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

#25

Post by jchw »

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.

This is interesting. Not saying you are incorrect, but, I have worked at Google for a few years and didn't pick up on this, most people seem abundantly polite. But, I can just as easily chalk that up to limited experience, since there is clearly quite a lot of different things going on in any large company.

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

#26

Post by dathinab »

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…

This has interesting parallels with how some languages include the library version in the "symbolic name" (mangled name, fully qualified name etc).

This often allows loading of multiple versions of the same dependency in the same program without ugly hacks. Which is grate if you have multiple dependencies which both have the same sub-dependency (each internal only to their dependent) but need different versions.

It's kinda a nightmare if you run into this problem in languages which don't support it.

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

#27

Post by CalChris »

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. His points are still valid.

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

#28

Post by ineedasername »

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 thread said it's not bad to write like that for catharsis... I guess to blow off steam or something. But if the method of blowing off steam is belittling other smart people that don't always make perfect decisions then it's probably not a great way to go. If you need to write it for catharsis, go for it, but there's no need to publish it.

Otherwise, my questions on the technical side: Would this performance hit and the alternative option have been obvious at the time? If so, was there a reasonable trade off for why this approach was taken? Or was this choice only wrong in retrospect?

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

#29

Post by OJFord »

qwertox wrote: post #14
mct wrote: post #10

Earlier quoted context omitted.

I'm seeing "You must log in to continue," with no "not now" option.

Probably expects JavaScript enabled or something. I also don't have a "not now" option. No JavaScript, no CSS. Honestly, how can someone into tech post something like this on FB?

Leaving aside whether or not they should want to post it there, I'm surprised it has an audience.

Someone saw it and shared it to HN; enough read it to upvote it this much.. maybe Facebook's more popular than I thought! (That sounds silly or sarcastic, but 'among HN users and similar' I'm serious.)

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

#30

Post by ineedasername »

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.

Would this tone of expression be appropriate in navigating performance reviews? I mean the question honestly: My own answer is "no", but I don't know the culture of performance reviews at companies like that.
Post reply on HN