You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Update message clustering and risk inference was previously executed asynchronously in batches of humans. The input data required for this was packaged into serializable structures and sent via ZMQ sockets to another process with various threads (broker, workers). At some point, the increase in update message counts (probably due to the fragmentation of long encounters to 15-minute chunks) made the serialization & packet exchange process longer than inline clustering+inference on the main thread. This is very sad, but lesson learned: multithreading/multiprocessing in Python SUCKS.
At some point, we will have to pick one of these options:
Get rid of all the remote inference logic and go back to a leaner codepath for clustering/inference. That would mean losing the possibility to do async stuff again, and getting rid of a lot of code that worked for a long time.
Rewrite the message batching and serialization logic to make I/O as lightweight as possible so that we can start using the inference server again. Back when it was introduced, the speedup for big simulations was ~10x, and it would be great to get that speedup again now that the rest of the code is not as slow as it once was. Delta encoding and compression might come in handy here...
Rewrite the entire clustering/inference pipeline in C++, and forget about pickling/multiprocessing altogether. This would require a significant time investment, but "breaking out of the GIL shackle" would definitely allow us to do big simulations.
The text was updated successfully, but these errors were encountered:
Update message clustering and risk inference was previously executed asynchronously in batches of humans. The input data required for this was packaged into serializable structures and sent via ZMQ sockets to another process with various threads (broker, workers). At some point, the increase in update message counts (probably due to the fragmentation of long encounters to 15-minute chunks) made the serialization & packet exchange process longer than inline clustering+inference on the main thread. This is very sad, but lesson learned: multithreading/multiprocessing in Python SUCKS.
At some point, we will have to pick one of these options:
The text was updated successfully, but these errors were encountered: