Switch from rand() to an XOR Shift to favor speed over random quality #89
Conversation
There was a problem hiding this comment.
Generally looks OK to me. It's too bad there isn't a fast PRNG reliably available via std/the system libraries; it's a bit of a shame to have to keep our own state for it.
That said, my preference would be to remove the stochastic behaviour entirely. I still have an unfinished patch that limits the number of outstanding poll events to 1 or 2 per client. The initial implementation added a queued polls counter to each AsyncClient, which is O(1) but must be managed under the mutex. An alternative would be to scan the queue (O(N)) and do a quick count of matching events before adding a new poll event, which trades CPU to save a little memory and complexity. In both cases it ensures that no unlucky client gets completely starved of poll events.
I agree ;-) |
|
ESP32 chips have actual hardware for random. That would be the proper fix here. Why was this merged so fast? |
|
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/random.html Please revert and use actual random hardware |
|
I considered suggesting it, but unfortunately there doesn't seem to be a nonblocking call to access the random hardware? We do not need cryptographic quality randomness, and we definitely do not want to block waiting for more entropy. |
rand() is called at 2 places, and we do not care about having a good distribution of random numbers.
So I think we can easily use a more appropriate implementation (xor shift) which can be enough for our need and definitely way faster than calling rand()