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

How many lines of C it takes to execute a + b in Python

codeconfessions.substack.com

Post reply on HN
Print view View original

11–20 of 224 posts

Re: How many lines of C it takes to execute a + b in Python

#11

Post by eesmith »

andai wrote: post #4

A while back someone posted their patch to cpython where they replaced the hash function with a fast one and claimed this dramatically sped up the whole Python runtime. They claimed that the hash function was used constantly —e.g. 11 times in print("hello world")—because it's used to look up object properties. Apparently the default implementation is not optimized for performance but for security, just in case the so…

Your "just in case the software is exposed to the web" should be "exposed to untrusted data." The very old Python hash could be DoS'ed reading a data file. The original randomized version required some feedback to figure out the hash, so generally required some sort of interaction.

I find that hard to believe that's a performance bottleneck. String hashes are all cached, and names like "print" are interned.

For a 2x overall gain I would expect to see the hash function pop up easily in my profiling, but I haven't seen it in my own profiling which was looking for simple things like that.

When siphash was evaluated, quoting https://peps.python.org/pep-0456/#performance , "In general the PEP 456 code with SipHash24 is about as fast as the old code with FNV" and "The summarized total runtime of the benchmark is within 1% of the runtime of an unmodified Python 3.4 binary".

Since then they switched from siphash24 to the faster siphash13. https://github.com/python/cpython/pull/28752

Re: How many lines of C it takes to execute a + b in Python

#14

Post by ynik »

andai wrote: post #4

A while back someone posted their patch to cpython where they replaced the hash function with a fast one and claimed this dramatically sped up the whole Python runtime. They claimed that the hash function was used constantly —e.g. 11 times in print("hello world")—because it's used to look up object properties. Apparently the default implementation is not optimized for performance but for security, just in case the so…

AFAIK Python strings cache their hash value. All the hash table lookups for object properties should be compile-time constant strings that reuse the string object, and thus also reuse the cached hash value. It may take 11 hash computations for the first print("hello world"), but the second call shouldn't take any.

Re: How many lines of C it takes to execute a + b in Python

#15

Post by petters »

andai wrote: post #4

A while back someone posted their patch to cpython where they replaced the hash function with a fast one and claimed this dramatically sped up the whole Python runtime. They claimed that the hash function was used constantly —e.g. 11 times in print("hello world")—because it's used to look up object properties. Apparently the default implementation is not optimized for performance but for security, just in case the so…

Do you mean this post? https://www.reddit.com/r/Python/s/raofvsKCiz That speedup was disputed in the comments. I haven’t tried it myself though

Re: How many lines of C it takes to execute a + b in Python

#16

Post by eesmith »

a_humean wrote: post #9
andai wrote: post #4

A while back someone posted their patch to cpython where they replaced the hash function with a fast one and claimed this dramatically sped up the whole Python runtime. They claimed that the hash function was used constantly —e.g. 11 times in print("hello world")—because it's used to look up object properties. Apparently the default implementation is not optimized for performance but for security, just in case the so…

I'm aware that Rust has something similiar for things like `std::collections::HashMap`. By default: > The default hashing algorithm is currently SipHash 1-3, though this is subject to change at any point in the future. While its performance is very competitive for medium sized keys, other hashing algorithms will outperform it for small keys such as integers as well as large keys such as long strings, though those alg…

Python 3.11 appears to have switched to SipHash 1-3 for strings, from 2-4, following the lead of Rust and Ruby. https://github.com/python/cpython/issues/73596

However, Python does not use it for integers;

  >>> hash(10)
  10
  >>> hash(100)
  100
  >>> hash(2**61-2) == 2**61-2
  True
  >>> hash(2**61-1)
  0

Re: How many lines of C it takes to execute a + b in Python

#17

Post by unnah »

rhabarba wrote: post #5

Sounds like it would be easier to just use C anyway.

Yes, but C is a much more arcane and complicated language. Case in point: instead of writing a+b in Python, in C you would have to write a+b

(Jokes aside, it would really be more complicated in C if a and b were actually strings or lists.)

Re: How many lines of C it takes to execute a + b in Python

#18

Post by rhabarba »

globular-toast wrote: post #12
rhabarba wrote: post #5

Sounds like it would be easier to just use C anyway.

It's even easier to just buy a desk calculator or even just learn long addition and do it with pencil and paper.

Actually, I generally recommend to not leave easy tasks to the computer. The brain likes to have to do stuff sometimes.

Re: How many lines of C it takes to execute a + b in Python

#19

Post by yakubin »

a_humean wrote: post #9
andai wrote: post #4

A while back someone posted their patch to cpython where they replaced the hash function with a fast one and claimed this dramatically sped up the whole Python runtime. They claimed that the hash function was used constantly —e.g. 11 times in print("hello world")—because it's used to look up object properties. Apparently the default implementation is not optimized for performance but for security, just in case the so…

I'm aware that Rust has something similiar for things like `std::collections::HashMap`. By default: > The default hashing algorithm is currently SipHash 1-3, though this is subject to change at any point in the future. While its performance is very competitive for medium sized keys, other hashing algorithms will outperform it for small keys such as integers as well as large keys such as long strings, though those alg…

Which is why the Rust compiler itself uses a non-cryptographic hash, which takes just 3 x86 instructions and can work on 8 bytes at a time: https://github.com/rust-lang/rustc-hash/blob/master/src/lib....>
Post reply on HN