Live data from Hacker News

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

bugs.python.org

101–105 of 105 posts

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

#101
post #46

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

This is recalling the old Linus debates, but the aggressiveness _doesn't improve the clarity_, and is basically upping the word count. I'm not tone policing but contesting the premise that "aggressive tone" = "direct". For example >(Windows took a different approach and got it right. In Windows, it's okay for multiple DLLs to provide the same symbol, and there's no sad and desperate effort to pretend that a single na…

No, your rewritten version misses the fact that they're trying to work around the problem, which is what takes it from "X is wrong because I say so" to "X is causing them tangible problems".

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

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

Interposing libc.so symbols in a shared object is not affected by -fno-semantic-interposition or -Bsymbolic

https://maskray.me/blog/2021-05-16-elf-interposition-and-bsy...

Solaris offers a similar model called direct bindings.

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

#103
I tested this.

tldr; I could not replicate speed benefits except for heavy stack usage. Python 3.10 is 8% slower than python 3.8. Python 3.10 with said optimization is 3% slower overall than Python 3.10 without it except for stack usage.

  Python 3.8
  python-speed v1.2 using python v3.8.5
  string/mem: 1476.42 ms
  pi calc/math: 1817.37 ms
  regex: 1984.63 ms
  fibonnaci/stack:  1085.79 ms
  
  total:  6364.21 ms (lower is better)



  Python 3.10 no optimization
  python-speed v1.2 using python v3.10.0
  string/mem: 1580.52 ms
  pi calc/math: 1796.23 ms
  regex: 2110.86 ms
  fibonnaci/stack:  1337.18 ms
  
  total:  6824.79 ms (lower is better)


  Python 3.10 with optimization
  python-speed v1.2 using python v3.10.0
  string/mem: 1559.45 ms
  pi calc/math: 1821.25 ms
  regex: 2387.64 ms
  fibonnaci/stack:  1299.8 ms
 
  total:  7068.13 ms (lower is better)
Anything I am missing? Tested using https://github.com/vprelovac/python-speed
Post reply on HN