| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 30 01:13AM +0100 On Sat, 29 Apr 2017 13:36:24 -0700 > scaling. Avoiding the funnel is about scaling. Creating a server is > about scaling. > Also, again can you _please_ add proper _attributions_ Bonita. This discussion is in danger of being flogged to death, repeatedly. What Bonita said is obviously true. Asynchronous i/o works best when asynchronous events are waiting for things to happen, such as a file descriptor becoming ready. If the work load involves many high load tasks which do not wait, it is useless. What you said is also true, sort of, save that if the work load involves 500 tasks involving high load (non-waiting) tasks, and you only have 4 cores, no amount of native threads is going to help you. The more you have, the less good the performance will be. Requiescat in pacem. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 29 07:48PM -0700 On 4/29/2017 5:13 PM, Chris Vine wrote: > cores, no amount of native threads is going to help you. The more you > have, the less good the performance will be. > Requiescat in pacem. Agreed. Fwiw, I was trying to focus on "periods of load" in which a thread-per-connection model fails. Sure, your server might be working fine for a while, then a batch of work comes in all at once and things start to get slow. In the contrived scenario, these batch's start to be more and more frequent due to more requests and/or new connections, more users. 500 threads can spike to 2000+ threads. Just brainstorming here. |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Apr 29 11:18PM -0700 On Sunday, April 30, 2017 at 8:18:16 AM UTC+5:30, Chris M. Thomasson wrote: > start to get slow. In the contrived scenario, these batch's start to be > more and more frequent due to more requests and/or new connections, more > users. 500 threads can spike to 2000+ threads. Just brainstorming here. I couldnt really get how can 500 threads suddenly spike to 2000 threads |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 30 11:43AM +0200 >> than CPU-load. > It also saves CPU load. It also reduces pressure on mutexs wrt > hundreds of threads pounding them. The mutexes are usually part of a cv, and those mutexes are held in a poducer-consumer-pattern for a very short interval. The rest of the time the thread spends preparing or processing an item, which is a by magnitudes longer interval. So the likehood of a collision isn't high even with 500 threads. > This does not make sense to me. Context switching hundreds of > active threads, do to load, is absolutely terrible. No, context-switching even some thousand times a second isn't much load even on Windows and much les on Linux, which is by far more efficient. > AIO and IOCP is about scaling. They can be applied only in rare cases when there isn't much processing besides enqueuing or dequeuing asynchronous requests. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 30 02:43PM +0200 I've written two tiny applications. Both create a 1GB file wich is created unbuffered to simulate the behaviour in a DB-server where blocks are not in the cache. The file is read parallely in 4kB-blocks with either 500 threads or one thread using an IOCP. The multithreaded app can be found here: https://pastebin.com/ByC33n65 I had to use asynchronous I/O within the threads because I can't do SetFilePos on the same file-handle from multiple threads. So with overlapped I/O and immediately blocking after that, I can give the file-position to be read in the OVERLAPPED-structure. The singlethreaded app with IOCP can be found here: https://pastebin.com/WrmBjVMC On my 3,6GHz Ryzen 1800X the multithreaded code runs with about 7% CPU-load. And the singlethreaded code is about 6%. So there's not a big difference. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 30 02:57PM +0200 And the memory-consumption: The multithreaded app has a private commit of 19MB and a workingset of 13,7MB. The single-threaded app has a private commit of 740kB and a workingset of 2,7MB. So I was right to assume, that code that does parallel I/O via IOCPs is rather memory-saving than CPU-saving. |
| scott@slp53.sl.home (Scott Lurndal): Apr 30 01:37PM >of the time the thread spends preparing or processing an item, >which is a by magnitudes longer interval. So the likehood of a >collision isn't high even with 500 threads. Please learn to quote properly with attribution. Your assumption that the mutex _only_ protects the condition variable is faulty. It likely also protects other shared data, including e.g. listheads. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 30 03:41PM +0200 >> collision isn't high even with 500 threads. > Please learn to quote properly with attribution. Your assumption > that the mutex _only_ protects the condition variable is faulty. I didn't assume this. I only said, that the mutex is part of a cv. That doesn't exclude the rest. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 30 03:56PM +0200 > The multithreaded app can be found here: > https://pastebin.com/ByC33n65 There was a little mistake; the file created was larger than necessary and there was one | instead of || typo. So here's the corrected code: https://pastebin.com/wqiLFsmJ > The singlethreaded app with IOCP can be found here: > https://pastebin.com/WrmBjVMC Here ther was the same "bug" with the too large file: https://pastebin.com/yHvghReX |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment