I assume their network protocol benchmark meant to show how fast their protocol implementation is relative to others is not being bottlenecked on their network bandwidth because that would be positively idiotic.
Given the machine the benchmarks are running on has a 50 Gbps NIC, that would be double stupid since their bottleneck would then need to be the production side not producing enough data to show how fast their implementation is or bad network configuration doing the same.
And that all assumes they are not bypassing the NIC entirely since they are benchmarking the protocol implementation so the source of packets is largely irrelevant except for making sure they are not still in the cache after the producer synthesizes them.
Beyond that we look to memory bandwidth as a fundamental limiting factor on data shuffling from packets to the protocol client to attempt to bound the theoretical maximum throughput so we can see how far off a protocol implementation is from the theoretical maximum.
If you want a stable sort, you should always use https://pkg.go.dev/sort#SliceStable
This PR only modifies Slice method which is declared as "is not guaranteed to be stable"
Go already randomizes the order of keys in map iterations to discourage relying on undefined behavior. It would be funny if they randomized the order of equal elements in what would otherwise be a stable algorithm for the same reason.
huh, interesting. As far as I can tell the main advantage this has over IOCP is that you can get one completion for multiple read requests.
Looks like they took a lot of the concepts from Winsock RIO and applied them to file I/O. Which is fascinating because with network traffic you can't predict packet boundaries and thus your I/O rate can be unpredictable. RIO helps you get the notification rate under control, which can help if your packet rate is very high.
With files, I would think you can control the rate at which you request data, as well as the memory you allocate for it.
The other thing it saves just like RIO is the overhead of locking/unlocking buffers by preregistering them. Is that the main reason for this API then ?
I would be very interested to hear from people who have actually run into limits with overlapped file reads and are therefore excited about IoRings
That's talking about manipulating files in the LXSS filesystem from Windows tools. There's no problem with doing everything on your Windows mounts, assuming you don't mind everything getting +x.
Hey guy, what you found is DNS polution, which is applied for years and upgraded several times. The most recent upgrade increases polluted result from tens to thousands and introduced real ip pointing to real web sites.
