924 karma · joined September 3, 2015
Gcc and llvm can tell you if they can’t Auto vec a function, maybe rust could turn this into an error at comptime.
That’s one of the biggest issues keeping Linux small on the desktop since nearly no commercial oriented company works that way.
But it looks like we will soon be able to „virtualize“ the dynamic loader so glibc has no say in this matter anymore.
One could build a IR emitter but you need soldering skills for that or buy a usb one which cost north of 30€ + shipping.
I believe LG doesn’t advertise such an api via Bluetooth
i open the file, mmap it, close it and tell io_uring_prep_send which bytes from the mapping to send, this also saves me from a possible SIGBUS cause the access to the mmap happen inside the kernel, and when a SIGBUS would happen in userspace the kernel just reports a shorter send in cqe->res
mmap and io_uring_prep_send were faster than everything else, no matter the size as long as you keep the map around for the lifetime of the process.
for one off sends when a file is smaller than 256kb then io_uring_prep_read + prep_send are faster than everything else.
Its a new web server i am building and its the fastest way i could find out.
Just switching from epoll to liburing made the server ~45% faster too, its ridiculous. It can serve 10 gigabyte per second with a single thread, or around 10 million responses per second with h2 and 32 multiplexed requests.
I had to write a new http load generator for that since i couldn't find one which could generate enough load to saturate my server or be fast enough to withstand it.
There is another Museum of his, which is still funded.
On my ryzen 9 it needs around 8 cores to do the same work in a threaded io loop than you can do single threaded. And the mechanism doesnt matter, you could share an fd, use SO_REUSEPORT or just share memory between threads.
Just doing the sharing makes everything extremely slow. One context switch becomes more expensive than just doing it single threaded.