Live data from Hacker News

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

bugs.python.org

91–100 of 105 posts

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

#91
post #90

This is true for _libpython_ (the shared library version), which is the default on some distros (RedHat, Fedora, Arch), but many others (Debian, Ubuntu) use statically linked Python and never paid this performance tax.

So what do Redhat, Fedora, Arch gain by using the shared libpython? Who except python is using the library?

Software that embeds Python uses the library (even on Debian and Ubuntu: they end up building the whole Python source base twice).

For example Vim (if so configured), or Postgres PL/Python, or the old Apache mod_python.

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

#92
post #56

Python is like the cockroach equivalent of those shell scripting languages that came out of the late 80s to early 90s. Perl, Ruby, PHP, TCL, and Lua have definetly declined over the years. Python's biggest asset seems to be featured rich libraries, rather than the language itself.

Ruby is a much better designed language than Python but the community unfortunately made the mistake of focusing too much on Rails and web development at the expense of diversification. Python is the Skoda of scripting languages.

What does it mean in your country? For me, its a company priced out by carmakers who manufactured locally, and screwed over by dealers who didn't service cars properly. Ex Fabia owner from India.

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

#93
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…

[deleted]

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

#94
post #68
post #57

Earlier quoted context omitted.

> Someone wrote that inanimate object. Someone likes that inanimate object. You'll find somebody liking everything you can name. Even every attrocity has been done by somebody. Not attacking the person is of course the correct thing. But if you can't even attack the attrocity or bad choice, we've gone too far with this sensitivity thing.

But in this case it's not an atrocity, and whether or not it was even a bad choice (at the time or today) is debatable. It's fine to present an opinion you hold about something, but belittling that thing also tends to implicitly belittle the intellect of people who might agree with that thing, not to mention the people who designed and built that thing. > But if you can't even attack... Why do we need to attack somet…

>Why do we need to attack something? If we can't explain and support our view that something is wrong or a bad decision without resorting to attacks, perhaps our argument isn't really that strong?

It's rather the opposite: if we don't resort to attack, comdent the practice, raise the tone, our argument will be weak.

That's because it's not enough to be right. It also need to be memorable and resontant. Else people's eye will just glaze over it.

That's why this post has 218 comments as of now, and you where involved and will remember it better tomorrow, than some purely technical explanation that probably wouldn't even have made it in the first page (or have 0-10 comments, typical of such posts).

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

#95
post #57

Earlier quoted context omitted.

> Someone wrote that inanimate object. Someone likes that inanimate object. You'll find somebody liking everything you can name. Even every attrocity has been done by somebody. Not attacking the person is of course the correct thing. But if you can't even attack the attrocity or bad choice, we've gone too far with this sensitivity thing.

Why can't they just present the argument without any abuse at all? Why is there ever any need for the abuse?

Well, the argument here is:

(a) if you attack the practice is not abuse. Abuse is when you attack the person.

(b) if you don't have a colorful tone and strongly condemn something, for most the complaint wont even register

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

#96
post #55

Earlier quoted context omitted.

> This is recalling the old Linus debates, but the aggressiveness _doesn't improve the clarity_, and is basically upping the word count. It drives the point home though, and keeps the energy levels higher.

> It drives the point home though Is the argument too weak to do that on its own without the abuse?

That's the case for all technical arguments.

Arguments are seldom weak or strong based on their technical details.

Heck, the technical details about this were already known to many people including several involved in build setups, but nobody cared anyway.

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

#97
post #95

Earlier quoted context omitted.

Why can't they just present the argument without any abuse at all? Why is there ever any need for the abuse?

Well, the argument here is: (a) if you attack the practice is not abuse. Abuse is when you attack the person. (b) if you don't have a colorful tone and strongly condemn something, for most the complaint wont even register

> if you don't have a colorful tone and strongly condemn something, for most the complaint wont even register

Maybe the argument isn't actually that good if you need to resort to theatrics to make the point register?

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

#98
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.…

Design decisions don't appear, they are made by people. Going over the top with profanity or LOL's or l33t speak might make it more entertaining to read, but anyone even a little predisposed to disagree with your assessment is a lot more likely to go on the defensive. If I said was talking to someone and telling them a design decision I encountered was shitty and bad, and it turns out that was the person who made the decision, I'm going to be a lot less likely to convince them of my assessment then if I just said "Choosing to do X instead of Y will make it 1.3x faster".

This means the writer is choosing to write for audience entertainment instead of technical advancement & improving the status quo. It's not impossible to do both at the same time, without the insulting tone.

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

#99
post #91
post #90

Earlier quoted context omitted.

So what do Redhat, Fedora, Arch gain by using the shared libpython? Who except python is using the library?

Software that embeds Python uses the library (even on Debian and Ubuntu: they end up building the whole Python source base twice). For example Vim (if so configured), or Postgres PL/Python, or the old Apache mod_python.

Interesting. Performancewise not having to call a separate executable is of course a good thing. Securitywise process boundaries are better.

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

#100
post #6

Earlier quoted context omitted.

I think using Pypy instead of CPython will give you several times the performance boost as any of this.

Assuming pypy does what it says it does: Python -> RPython -> C -> LLVM Clang -> LLVM IR -> 'JIT', you're still paying a large tax compared to something like RPython -> Some IR -> 'JIT'

I think you've misinterpreted something. The pypy interpreter is written in rpython, but executed code itself never gets translated to rpython.
Post reply on HN