Live data from Hacker News

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

codeconfessions.substack.com

71–80 of 224 posts

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

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

This may be a somewhat uninformed opinion, but I think CPython is just straight up not particularly good software. There are a million and one optimizations that other major scripting runtimes (V8, LuaJIT, PyPy, Ruby YJit etc.) have had for years that CPython is lacking. This is by design though. CPython has never been focused on performance, that's why it's not even JIT. It optimizes for simplicity and easy interope…

If this is by design and it optimizes for simplicity and easy interoperability with C, why would you assess its quality as 'good software' based on criteria that are non-goals?

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

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

This may be a somewhat uninformed opinion, but I think CPython is just straight up not particularly good software. There are a million and one optimizations that other major scripting runtimes (V8, LuaJIT, PyPy, Ruby YJit etc.) have had for years that CPython is lacking. This is by design though. CPython has never been focused on performance, that's why it's not even JIT. It optimizes for simplicity and easy interope…

I don't disagree with you but, now you can retrofit a JIT into python. https://blog.pyston.org/2022/09/29/announcing-3-7-3-10-suppo...

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

#73
post #61

[flagged]

Isn't that just the Substack default? so much better than Medium's or others, at least it closes. Besides, Substack is one of the more writer-friendly platforms re: take-home-pay and no ads, so maybe reconsider?

Writer-friendliness doesn't need to be at odds with reader-friendliness.

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

#74
post #17
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.)

> much more arcane and complicated

How much more, though? The conventional wisdom here seems to be that it's worth taking the unavoidable performance hit of dynamically typed scripting languages because the productivity boost to programmers balances it out... but I don't believe I've seen that productivity boost measured. Once you know what you're doing in C, you can do that same things you can do in Python. There's some (fascinating) syntactic sugar in there, but Python can easily be just as incomprehensible as C.

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

#75
post #73

Earlier quoted context omitted.

Isn't that just the Substack default? so much better than Medium's or others, at least it closes. Besides, Substack is one of the more writer-friendly platforms re: take-home-pay and no ads, so maybe reconsider?

Writer-friendliness doesn't need to be at odds with reader-friendliness.

Sometimes it seems like they do need to be opposed. For the writer to get paid, the reader needs to be asked to pay, or exploited quietly. I don’t know a way out :(

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

#76
post #73

Earlier quoted context omitted.

Writer-friendliness doesn't need to be at odds with reader-friendliness.

Sometimes it seems like they do need to be opposed. For the writer to get paid, the reader needs to be asked to pay, or exploited quietly. I don’t know a way out :(

It's not about what, it's about when though — like the GP, I got a pop-up fairly immediately before I'd engaged in the article so I just closed the tab.

The best time to engage me is after I've enjoyed the article and hopefully interested to hear more from the writer rather than immediately landing on the page.

It's the equivalent to sales staff jumping on customers in shops the minute they walk in the door — "can I help you with anything today?" — before you even have a chance to see what the shop is like.

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

#77
post #61

[flagged]

As disrespectful and annoying as it is, don't sites do this because it's a net gain in conversions for them? I think we're a minority here. At scale, do not the masses submit to these popups and end up converting into sales?

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

#79

Earlier quoted context omitted.

Didn't see that. I guess that's just uBO working as intended.

My uBO didn't catch them for the record. I just added the following rule to be sure: substack.com##[class^="frontend-components-SubscribePrompt-"]

Thanks for that filter. I was trying to make one on my own, but couldn't quickly figure out the documentation. How did you learn making these?

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

#80

Earlier quoted context omitted.

This may be a somewhat uninformed opinion, but I think CPython is just straight up not particularly good software. There are a million and one optimizations that other major scripting runtimes (V8, LuaJIT, PyPy, Ruby YJit etc.) have had for years that CPython is lacking. This is by design though. CPython has never been focused on performance, that's why it's not even JIT. It optimizes for simplicity and easy interope…

If this is by design and it optimizes for simplicity and easy interoperability with C, why would you assess its quality as 'good software' based on criteria that are non-goals?

In my eyes, "good software" does not necessarily just mean something that accomplishes its goals. You can set a goal of being bad, and that's kind of what CPython is doing.

Of course, "good" and "bad" are relative. If you don't care about performance then there's nothing wrong with CPython.

Post reply on HN