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

Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

github.com

Post reply on HN
Print view View original

131–140 of 192 posts

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#131

Post by commitpizza »

cyber1 wrote: post #113

Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.

> Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm.

This is the case for basically every programming language or performant library that exists. Yet, I never see this when discussions exists about node libraries or other languages for that matter. I mean you could argue that node itself is just a thin wrapper around fast C++ libraries.

Who the fuck cares if the request goes down to some compiled C++ library? I still write my logic in Python and get this benefit anyway. This is what makes it great.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#132

Post by carlsborg »

cyber1 wrote: post #113

Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.

Would golang interfaced with the C++ implemenation be as fast? IMO one of the nice features of Python is being able to seamlessly drop to numba, or a C++ module when you need an optimized fastpath, but the rest of your application, the bulk of it, need not.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#133

Post by warinukraine »

inglor wrote: post #119
cyber1 wrote: post #113

Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.

I'm so happy this is (currently) the top comment and people are starting to realize measuring perf with these well tuned micro-benchmarks is a sham.

Why is it a sham? It's useful to know that x is faster. As a user of x I don't really care if the reason it's faster is it's C++ under the hood. That's really an implementation detail for me.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#134

Post by dgb23 »

melenaboija wrote: post #77
meling wrote: post #67

Earlier quoted context omitted.

Technically, it is C that’s faster.

Technically (not sure what you mean with this but with the context I will use it too as it seems to match with what I want to say) you could never talk about Python (the most common and original implementation) without making reference to C then. And if you are not making reference to a specific implementation then the comparison does not make any sense.

> you could never talk about Python (the most common and original implementation) without making reference to C then.

Good. Because otherwise people would be mislead to think that Python itself is fast. The Python plus C combo has opposite tradeoffs in many dimensions.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#135

Post by lupire »

warinukraine wrote: post #133
inglor wrote: post #119

Earlier quoted context omitted.

I'm so happy this is (currently) the top comment and people are starting to realize measuring perf with these well tuned micro-benchmarks is a sham.

Why is it a sham? It's useful to know that x is faster. As a user of x I don't really care if the reason it's faster is it's C++ under the hood. That's really an implementation detail for me.

What happens when you use X because it's fast at one thing in a microbenchmark, but it locks you into an environment that is slow at the rest of your program?

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#136

Post by inglor »

warinukraine wrote: post #133
inglor wrote: post #119

Earlier quoted context omitted.

I'm so happy this is (currently) the top comment and people are starting to realize measuring perf with these well tuned micro-benchmarks is a sham.

Why is it a sham? It's useful to know that x is faster. As a user of x I don't really care if the reason it's faster is it's C++ under the hood. That's really an implementation detail for me.

Because it's measuring a scenario that's not representative of real usages of X and is usually tweaked for the framework/tool the author is trying to showcase.

For example: all the deno/bun benchmarks often use the Node.js frameworks in an unnecessarily slow way and don't measure apples to apples. (like using uWS in bun but not uWS for Node in the benchmark).

This one in particular just measures the speed of "hello world" in plaintext and JSON with very specific parameters.

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#138

Post by warinukraine »

meling wrote: post #67
melenaboija wrote: post #63

Earlier quoted context omitted.

It does not say that Python is faster than Go it clearly says "Python framework". > It only proves that wrapping C code in Python is fast. Yes, it proves that for this specific use case Python is faster.

Technically, it is C that’s faster.

Technically, python is written in C. What's your point?

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#139

Post by charles_f »

commitpizza wrote: post #131
cyber1 wrote: post #113

Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. Without real problem-solving (business logic) written in Python, this is only lightweight wrapper on C/C++. When the number of Python code start growing in the hot path, then these blazing-amazing thruput numbers tremendously will be going down.

> Yet another "X faster than Y" where inside X all hot jobs are done by really good-tuned C or C++. Facepalm. This is the case for basically every programming language or performant library that exists. Yet, I never see this when discussions exists about node libraries or other languages for that matter. I mean you could argue that node itself is just a thin wrapper around fast C++ libraries. Who the fuck cares if th…

> Who the fuck cares if the request goes down to some compiled C++ library?

The way this is titled, you know someone will read this as "Python can be faster than go" and influence their decision when it comes to performance ; that's actually why I clicked on that, thinking "how the hell did they achieve faster speed with Python".

Re: Show HN: Socketify.py: Http/Https and WebSockets servers for PyPy3 and Python3

#140

Post by svth »

throwaway894345 wrote: post #127
cirospaciari wrote: post #71

Earlier quoted context omitted.

PyPy work well with CPython modules but the performance is not that great, with CFFI performance is really good in PyPY, HPy project will change this https://hpyproject.org/

Last I checked, Pypy wasn’t compatible with many important packages in the Python ecosystem. As of a couple years ago, there was no trustworthy, supported package for talking to a Postgres database with Pypy because psycopg2 wasn’t supported.

I've been using PyPy and psycopg2cffi in production for the last 5-6 years or so without any issues.

https://pypi.org/project/psycopg2cffi/

Post reply on HN