7 ms·

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You c

No offence, but I don't think you fully grasp the situation here. This is an extremely optimized fully native server written with low-level CPU awareness. You can absolutely not, in any possible way, write this in Python.

Thaxll 10y ago
Because Nodejs is known to be highly performant with its single thread model...
- alexhultman 10y ago
  Node.js has nothing to do with the performance of this server.
  - Thaxll 10y ago
    My answer was directed to the comment you made about performance for Python and yet the lib you provide has binding for Nodejs which is not a very fast runtime.
e12e 10y ago
"TL;DR asyncio is an asynchronous I/O framework shipping with the Python Standard Library. In this blog post, we introduce uvloop: a full, drop-in replacement for the asyncio event loop. uvloop is written in Cython and built on top of libuv. uvloop makes asyncio fast. In fact, it is at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework. The performance of uvloop-based asyncio is close to that of Go programs." The question asked was if there is "anything [similar in] python", so there's an obvious requirement of being able to use it from python. That leaves either something with a bit of a friendly python wrapper, or just calling out directly to (only) pure C/C++ code. The latter might be even faster, but at that point it's questionable if calling it from python really is worth the trouble at all. So, I think it's fair to say that "uvloop may be 'something [similar in]' python".
- e12e 10y ago
  Although, thinking a bit more on this (and your more helpful reply to another poster), it might very well be that for web sockets, a better performing solution for python might be to write a wrapper for uWebSockets (the c++ implementation) in python. I'm guessing that the scaffolding code for the websocket-part in python when working with uvloop might indeed give a meaningful performance and/or memory hit (I'm leaning towards memory probably being the most significant difference here). I'd be interesting to compare a python+uvloop websocket implementation and uWS (both using nodejs and c++) -- and at some point see if wrapping uWS for python would make a meaningful difference.
- alexhultman 10y ago
  WARNING ----> NO OFFENCE: You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while. This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tcp_t. This is the level of optimizations we are talking about -> when libuv is considered too heavyweight... When libuv becomes too heavyweight to keep up, having this discussion about how a Python async network library could implement similar performance is just purely ridiculous. WARNING -> NO OFFENCE
barkingdog 10y ago
I can understand that you might be a bit frustrated right now, because perhaps that level of performance in pure python may literally be difficult to impossible in this case. But, the question the person was asking was a very reasonable one -- something along the lines of "I'm using this solution in python right now, and I'd like more performance -- what are my options?" It seems like you not only misunderstand the question, but felt the need to question their intelligence and give a rude, vague, and overall unhelpful answer. As a piece of communication, it is overall useless to everyone involved. Please be mindful of the way you come across. There's no need to insult, dismiss and disrespect others. It only takes a single moment, and saves time and energy for both you and them. You could rephrase like "No. You can approach this to a level of <percentage_of_perf>, but it will be hard to pass that point, due to the way the library is written." If you did that, you'd add some very valuable information to the conversation with little effort. It would be a win win for everyone. Beyond that, assuming your benchmarks are accurate, this seems like a prime library for someone to write a python wrapper for! There's autobahn-twisted right now, but I'm not sure how well it performs in comparison.
- ddlerk 10y ago
  I've actually had run-ins with Alex Hultman before and his tone here seems to follow what I've seen elsewhere. This project looks nice, but I would need to vet it pretty well before I trust it as the lead maintainer continually acts like a child on Reddit and promptly deletes all his comments shortly after. I'm surprised he is on hacker news as he won't be able to delete his juvenile and argumentative comments here.
- alexhultman 10y ago
  Toss a coin and it will land on someones holy ground.. My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.
  - barkingdog 10y ago
    You've written what potentially appears to be a promising library. Great! In fact, it seems so promising that people are trying to find the equivalent in the language of their choice. Even better! Why not encourage them to write a wrapper for your fine library in their language of choice? Not everyone uses Node, after all. Maybe that person asking for equivalents in Python would've written a binding if you told them "Hey, you could try to do this in pure python but because of the relative performance of my library, you might want to consider writing a binding to µws." I doubt you are trying to harm anyone. But you're not being very helpful. You say that you've "landed on someone's holy ground" but there is a very low chance that is going on. They probably just want to get a job done, and they want to figure out if your tool's a good fit. All it takes is a little bit more thought before you type out a response. I'm not telling you to censor yourself. I'm telling you to stop worrying about explaining yourself, and start thinking about being more helpful. I'm telling you to do it, because it will make things easier for you. You might have written the library, but other people are going to be the ones who use it. They're going to ask you questions, and you're going to think some of those questions are stupid. It's okay. But if you try to be helpful to them even if you think their questions are stupid, you'll spend far less time writing defensive comments on HN, and far more time watching adoption for your library grow, which I assume is something you may want. Best of luck!

Thaxll 10y ago

Because Nodejs is known to be highly performant with its single thread model...

alexhultman 10y ago
Node.js has nothing to do with the performance of this server.
- Thaxll 10y ago
  My answer was directed to the comment you made about performance for Python and yet the lib you provide has binding for Nodejs which is not a very fast runtime.

e12e 10y ago

"TL;DR asyncio is an asynchronous I/O framework shipping with the Python Standard Library. In this blog post, we introduce uvloop: a full, drop-in replacement for the asyncio event loop. uvloop is written in Cython and built on top of libuv. uvloop makes asyncio fast. In fact, it is at least 2x faster than nodejs, gevent, as well as any other Python asynchronous framework. The performance of uvloop-based asyncio is close to that of Go programs." The question asked was if there is "anything [similar in] python", so there's an obvious requirement of being able to use it from python. That leaves either something with a bit of a friendly python wrapper, or just calling out directly to (only) pure C/C++ code. The latter might be even faster, but at that point it's questionable if calling it from python really is worth the trouble at all. So, I think it's fair to say that "uvloop may be 'something [similar in]' python".

e12e 10y ago
Although, thinking a bit more on this (and your more helpful reply to another poster), it might very well be that for web sockets, a better performing solution for python might be to write a wrapper for uWebSockets (the c++ implementation) in python. I'm guessing that the scaffolding code for the websocket-part in python when working with uvloop might indeed give a meaningful performance and/or memory hit (I'm leaning towards memory probably being the most significant difference here). I'd be interesting to compare a python+uvloop websocket implementation and uWS (both using nodejs and c++) -- and at some point see if wrapping uWS for python would make a meaningful difference.
alexhultman 10y ago
WARNING ----> NO OFFENCE: You need to realize, that libuv itself was simply too heavyweight for this project. Think about that statement for a while. This is why I use UNIX syscalls directly, and only use uv_poll_t, not the full-on uv_tcp_t. This is the level of optimizations we are talking about -> when libuv is considered too heavyweight... When libuv becomes too heavyweight to keep up, having this discussion about how a Python async network library could implement similar performance is just purely ridiculous. WARNING -> NO OFFENCE

barkingdog 10y ago

I can understand that you might be a bit frustrated right now, because perhaps that level of performance in pure python may literally be difficult to impossible in this case. But, the question the person was asking was a very reasonable one -- something along the lines of "I'm using this solution in python right now, and I'd like more performance -- what are my options?" It seems like you not only misunderstand the question, but felt the need to question their intelligence and give a rude, vague, and overall unhelpful answer. As a piece of communication, it is overall useless to everyone involved. Please be mindful of the way you come across. There's no need to insult, dismiss and disrespect others. It only takes a single moment, and saves time and energy for both you and them. You could rephrase like "No. You can approach this to a level of <percentage_of_perf>, but it will be hard to pass that point, due to the way the library is written." If you did that, you'd add some very valuable information to the conversation with little effort. It would be a win win for everyone. Beyond that, assuming your benchmarks are accurate, this seems like a prime library for someone to write a python wrapper for! There's autobahn-twisted right now, but I'm not sure how well it performs in comparison.

ddlerk 10y ago
I've actually had run-ins with Alex Hultman before and his tone here seems to follow what I've seen elsewhere. This project looks nice, but I would need to vet it pretty well before I trust it as the lead maintainer continually acts like a child on Reddit and promptly deletes all his comments shortly after. I'm surprised he is on hacker news as he won't be able to delete his juvenile and argumentative comments here.
alexhultman 10y ago
Toss a coin and it will land on someones holy ground.. My intentions were not to harm, that was why I said "no offence, but". I cannot more than explain myself. Sorry if I offended anyone (despite explicitly saying "no offence"). Someone should probably censor me, like, a lot.
- barkingdog 10y ago
  You've written what potentially appears to be a promising library. Great! In fact, it seems so promising that people are trying to find the equivalent in the language of their choice. Even better! Why not encourage them to write a wrapper for your fine library in their language of choice? Not everyone uses Node, after all. Maybe that person asking for equivalents in Python would've written a binding if you told them "Hey, you could try to do this in pure python but because of the relative performance of my library, you might want to consider writing a binding to µws." I doubt you are trying to harm anyone. But you're not being very helpful. You say that you've "landed on someone's holy ground" but there is a very low chance that is going on. They probably just want to get a job done, and they want to figure out if your tool's a good fit. All it takes is a little bit more thought before you type out a response. I'm not telling you to censor yourself. I'm telling you to stop worrying about explaining yourself, and start thinking about being more helpful. I'm telling you to do it, because it will make things easier for you. You might have written the library, but other people are going to be the ones who use it. They're going to ask you questions, and you're going to think some of those questions are stupid. It's okay. But if you try to be helpful to them even if you think their questions are stupid, you'll spend far less time writing defensive comments on HN, and far more time watching adoption for your library grow, which I assume is something you may want. Best of luck!