Great to have Google back again. This is an excellent, and well-reasoned talk.
@wdavid31162 жыл бұрын
Number of threads is an interesting one. I recently wrote a system that had to process a ludicrous number of files as fast as possible with different files processed different ways and some requiring socket communications to virtual machines running a different OS. The number of threads involved in various tasks had a lot of performance implications but the correct values depended on what other unrelated tasks were occurring at the same time. For what I was doing it made the most sense (and worked) for me to use conservative estimates and a little bit of testing to get values that worked well and hard code them. They aren't necessarily perfect but they fit my use case and the specific hardware the code runs on. Anyway I was thinking about semantic meaning related to thread count. If all of your thread creation is centrally managed I suppose you could estimate based on task priority, expected parallelization potential (ie are your threads forcing each other to sleep or working totally independently? Are they bound on io from the same device?) and position in a potential dependancy chain. In theory you could measure how long threads spend doing work vs sleeping and lower the total number of threads (picking which threads to destroy based on that info,) if you see performance issues from having too many threads for the available processors. You'd have to have a construct for your threads that allowed a manager thread to shut down instances gracefully and start up new ones. Probably a concept of tasks vice threads which I guess is pretty much how async_io works but extending the concept to manage processing resources as well and adding prioritization based on criteria other than the availability of data. You'd want to default to one thread per core (or 2 per if you have hyperthreading or similar,) but adjust from there based on processor usage for other processes on the host.