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

141–150 of 192 posts

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

#141

Post by anonymoushn »

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.

The real thing will be some mix of your code and the library's code, and in cases like this where you'd be writing all your logic in Python vs Golang, that will have a significant effect on the results.

A while back I implemented a game rules engine and MCTS in Torch (the Lua library). The training loop spent like half of its time running the rules engine. Writing it in Python would have been a disaster in comparison. To really make good use of the hardware and spend more time in the optimized machine learning code provided by libraries, one would have to write their rules engine in some language other than Lua or Python.

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

#142

Post by anthonygd »

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…

> Yet, I never see this when discussions exists about node libraries or other languages for that matter.

Huh? It's the first comment for pretty much any of these stupid performance comparisons. Does someone really think node performance is great, or pick node because of its performance?

> I still write my logic in Python and get this benefit anyway.

That's part of the point. Writing your logic in Python is fine, but then your app performance isn't winning any comparisons. No one cares about the performance this article is explicitly talking about.

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

#143

Post by [deleted] »

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.

[deleted]

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

#144

Post by commitpizza »

charles_f wrote: post #139
commitpizza wrote: post #131

Earlier quoted context omitted.

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

Well, it could be true IMHO. If I run my code that calls down to some ultra fast, mega well done C++ library that is much better than anything in the Go community my code then completes requests faster than the Go alternative.

If that is the case, that should influence the decision when it comes to performance. If performance is a very important deal in your app, you have to test this yourself so that you reach the performance you need.

Perhaps you can write C++ extensions to Python for the perf-heavy parts yourself instead of having to write the entire application in a language that takes much longer time to develop in?

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

#145

Post by doodlesdev »

anthonygd wrote: post #142
commitpizza wrote: post #131

Earlier quoted context omitted.

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

> Yet, I never see this when discussions exists about node libraries or other languages for that matter. Huh? It's the first comment for pretty much any of these stupid performance comparisons. Does someone really think node performance is great, or pick node because of its performance? > I still write my logic in Python and get this benefit anyway. That's part of the point. Writing your logic in Python is fine, but…

NodeJS might be slow, but it still is orders of magnitude faster than any interpreted or JIT Python implementation. I agree that no one really chooses Node because it is fast, but I think they choose it because it is fast _enough_ whereas if using Python you'd probably find multiple performance bottlenecks that could be show-stoppers.

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

#146

Post by jacobr1 »

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.

But that isn't the question. The question is what tool delivers the best performance. If I want to build some end-use-case software, should I adopt "Python Framework X" or "Golang Framework Y" to build this system? One consideration amongst many is performance. If you assume that the overall system with Go will be faster than the overall system with Python (and c modules) then you'd be wrong in this case. Other factors would inform your overall decision, but having more knowlege about tradeoffs enables one to make better engineering decisions.

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

#147

Post by pdpi »

okaleniuk wrote: post #13

Good point! However, you bring in a common misconception I'm fighting with within my company for a long time. Python is not an interpreted language. There is no such thing as an "interpreted language", a language is just a set or rules and keywords. Everything you can fit into Backus–Naur form is already a language even if it doesn't have any implementation nor compiler neither interpreter. Just as a piece of evidenc…

> There is no such thing as an "interpreted language", a language is just a set or rules and keywords.

Sure there is. Even if it is technically possible to write an interpreter for a "compiled" language, or a compiler for an "interpreted" language, language design really pushes you towards one or the other. "Technically possible" can also represent a very real challenge, as that set of rules and keywords might make ahead-of-time compilation either impossible or pointless.

E.g. any language that exposes `eval` with an arbitrary argument will still need to ship an interpreter as part of the runtime even if you compile some of the code ahead of time. Monkey-patching is common in Python and Ruby, and is pretty hostile to compilation. Codon has several documented limitations around this. Perl 5 famously can't be statically parsed without evaluating the code as you go, which completely defeats any attempt at compiling it.

Inversely, You can write an interpreter for C++, but features like `consteval` and `constexpr` are meaningless without ahead-of-time compilation.

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

#149

Post by warinukraine »

nmz wrote: post #148
warinukraine wrote: post #138

Earlier quoted context omitted.

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

Technically, golang was written in C. Why so combative?

I was just highlighting how saying "technically it's C that's faster" is a stupid think to say. Thanks for helping me make my point :D

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

#150

Post by no_circuit »

LtWorf wrote: post #37
matsemann wrote: post #9

Earlier quoted context omitted.

Pydantic is unreasonably slow for big datastructures, though. For simple performance tests with simple requests/response it's probably fast. But with lots of the data marshalling happening in python some things are really slow in real life use cases.

Author of typedload here. Pydantic is indeed really slow ( https://ltworf.github.io/typedload/performance.html ) typedload is faster and written in pure python (unlike pydantic). I know they are rewriting it in rust… but I don't know what will come out of it. After all my pure python implementation already manages to beat pydantic's binary, and when unions are in use, also apischema's binary.

The perf part of the tests just seems to be a microbenchmark for seeing how fast the various frameworks can parse a 30000x300 dict of strings representing numbers [1].

If that is all one's application does, and can use your library in their organization/team, that's great. However a 2-3x performance boost for the parsing stage for a use case like an API call might not matter when that could be overshadowed by validation and/or upstream API calls. A realistic app would likely use a validation library like Pydantic's [2] to throw a custom typed-error that can be processed, e.g., localization, before returning it downstream.

[1] https://github.com/ltworf/typedload/blob/37c72837e0a8fd5f350...

[2] https://docs.pydantic.dev/usage/validators/

Post reply on HN