Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New backend using io_uring #129

Closed
ng5 opened this issue Oct 11, 2020 · 7 comments
Closed

New backend using io_uring #129

ng5 opened this issue Oct 11, 2020 · 7 comments

Comments

@ng5
Copy link

ng5 commented Oct 11, 2020

io_uring - New asynchronous IO eventing added since linux kernel 5.1. Could be a possible enhancement given uSockets has already abstracted event polling backends.

Some performance benchmarks compared to epoll
Provided by GitHub user https://github.com/frevib

https://github.com/frevib/io_uring-echo-server/blob/io-uring-op-provide-buffers/benchmarks/benchmarks.md

@ghost
Copy link

ghost commented Oct 11, 2020

@ghost ghost deleted a comment from mohsenomidi Nov 1, 2020
@ghost ghost deleted a comment from mohsenomidi Nov 1, 2020
@ghost
Copy link

ghost commented Nov 1, 2020

It is said Linux 5.11 will have optimizations to io_uring so rerunning benchmarks then can be a good idea.

@ghost
Copy link

ghost commented Nov 11, 2020

There are many disadvantages to io_uring, esp. when dealing with tons of mostly-idle connections like with websockets. It's the same disadvantages as Windows IOCP has - mainly that you have to bind tons of user space memory to something that may happen in the future. This has massive disadvantages to memory usage and goes against much of what the point of uWS is. Further on the supposed performance improvements have been very mild, if none at all.

IO_uring should still be experimented with and assessed, but it should not be added just because of the hype. It should only be added if a significant, scientific gain can be shown (this, I'm still waiting for). We don't do things out of hype here - this is why we skip things that are hyped like sendfile and writev when the gains are impractical or none, for the core use cases.

Nobody has really presented anything that can outperform uWS either way, so we don't really need to respond to hype just because it is hyped. I don't care about new things unless there is real, scientific gain that significantly outweighs the disadvantages.

@ghost
Copy link

ghost commented Nov 11, 2020

It can also be said that we kind of already do support IO_uring since we support libuv - maybe not an ideal support but we definitely do support it (can always be improved, but still).

@ghost
Copy link

ghost commented Dec 7, 2020

io_uring is slower than epoll.

@ghost ghost closed this as completed Dec 7, 2020
@LifeIsStrange
Copy link

LifeIsStrange commented Feb 14, 2021

@alexhultman you should reconsider, as you know from the latests comment of your own issue on liburing, on kernel 5.12 (and even 5.11?) the performance is better vs plain epoll, even with mitigations=off

Also, I'd like to thank you for your efforts on rigorous thinking and benchmarking. This is a great example of applied rationalism and I'm sure you would like websites such as lesswrong.com
Learning cognitive biases would probably interest you too
https://en.m.wikipedia.org/wiki/List_of_cognitive_biases
https://en.m.wikipedia.org/wiki/List_of_fallacies
I'm becoming off topic but I would like to have debates with you on interesting intellectual topics as you are one of the rare examples of truth seekers.
In order to do so, if you're potentially interested, please create an empty issue on this repository with your name. :)
https://github.com/LifeIsStrange/CollectionOfInterestingBrains/issues

@ghost
Copy link

ghost commented Feb 15, 2021

I first need a benchmark that shows a significant gain on my computer otherwise it is impossible for me to develop for this API. I need to be able to benchmark as I go to know if I am doing it correctly, can't just develop and hope it will run fast when done.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants