- peformance of wait notify concept of condition variable - 12 Updates
- function type inside template - 2 Updates
- IWOMP 2017 CFP - 13th International Workshop on OpenMP - Extended submission deadline - 1 Update
- vector<double> hour {vector<double>(24, -7777)}; <--> vector<double> hour(24, -7777); - 1 Update
| kus <bhattacharya.kushal4@gmail.com>: Apr 26 05:26PM +0530 Hi, I am implementing a client server application as referred to my previous posts .The issue i am seeing,when i am notifying a waiting thread,that waiting thread sometimes takes around 10secs to repond to that notifying thread.I am seeing this situation when very large number of connections are opened simultaneously.Is it a normal behaviour or i am implementing something wrong here? Thanks, Kushal |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Apr 26 06:24AM -0700 On Wednesday, April 26, 2017 at 5:26:57 PM UTC+5:30, kushal bhattacharya wrote: > something wrong here? > Thanks, > Kushal To be more clear I just want to point out the facct that from the notifying thread ,I am using notify_all(),so according to the functionality of this fnuction it should notify all the waiting threads.Suppose I am using large number number of connections say,500 connections or more than that,then i am creating 500 notifying threads and 500 waiting threads.So, If i call notify_all() from any of the notifying threads,then all the 500 waiting threads will be notified,but within that it has some condtion to fulfil according to condition.wait().So,thinking about this,am i compromising some performance here and is it one of the culprit behind this delay? |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 26 04:37PM +0300 On 26.04.2017 14:56, kus wrote: > thread.I am seeing this situation when very large number of connections > are opened simultaneously.Is it a normal behaviour or i am implementing > something wrong here? Nobody remembers anything about your previous posts. But in any case 10 seconds seems extremely slow for just a simple responsiveness check (heck, even 10 ms would be slow). This may for example indicate that you have overloaded the machine and it is swapping memory to/from disk cache all the time. Check your memory usage. Alternatively there may be errors in your logic and 10 s is related to a timeout somewhere. BTW, what is "very large" number of connections? Is it the same as the number of running worker threads? If yes, then you are doing it wrong, there is in general no point to have more worker threads than the number of CPU cores. hth Paavo |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Apr 26 06:43AM -0700 On Wednesday, April 26, 2017 at 5:26:57 PM UTC+5:30, kushal bhattacharya wrote: > something wrong here? > Thanks, > Kushal Yes suppose i have 500 connections then 500 threads are created here,I am having some confusion regarding notify_all() and notify_one(), in this scenario will there be any performance gain if i use notify_one() and notify only one waiting thread |
| kushal bhattacharya <bhattacharya.kushal4@gmail.com>: Apr 26 06:44AM -0700 On Wednesday, April 26, 2017 at 5:26:57 PM UTC+5:30, kushal bhattacharya wrote: > something wrong here? > Thanks, > Kushal this architechture is done for scalability measures so i am just increasing the amount of connections now and accordingly distributing the work among those threads |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 26 06:48PM +0200 On 26.04.17 15.24, kushal bhattacharya wrote: >> Kushal > To be more clear I just want to point out the facct that from the notifying thread > ,I am using notify_all(),so according to the functionality of this fnuction it should notify all the waiting threads. > Suppose I am using large number number of connections say,500 connections or more than that, > from any of the notifying threads,then all the 500 waiting threads will be notified, > but within that it has some condtion to fulfil according to condition.wait(). > So,thinking about this,am i compromising some performance here and is it one of the culprit behind this delay? I think using 500 threads is the first problem. Since your computer probably is far away from 500 CPU cores this is not efficient. Waiting with 500 threads for a single condvar is even more ineffective. Each time you call notify_all 500 threads have to wake up, acquire a mutex, check a condition and probably most of the time release the mutex and return to waiting state. Or are you writing a chat server? Although this wastes several thousands of clock cycles this does not yet explain 10 seconds delay. Most probably you do some blocking I/O operation while you hold the mutex of the condvar. This could explain a delay in the order of 20 ms per thread. The answer is simple: don't do that. It leads multi-threading ad absurdum. Secondly you should not handle that much connection with individual threads. It is unlikely that all connections have do real work /concurrently/. This would most likely exhaust your hardware resources. Scalable server applications usually use a pool of worker threads that service a queue of incoming requests. This limits the parallelism to a reasonable level. Marcel |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 26 09:19PM +0300 On 26.04.2017 16:44, kushal bhattacharya wrote: >> Thanks, >> Kushal > this architechture is done for scalability measures so i am just increasing the amount of connections now and accordingly distributing the work among those threads Creating 500 threads is killing all your scalability if your hardware does not support 500 CPU cores. See examples in boost.asio about how to create a reasonable thread pool for servicing a large number of connections. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 26 08:51PM +0200 > does not support 500 CPU cores. > See examples in boost.asio about how to create a reasonable thread pool > for servicing a large number of connections. In cases where boost.asio is suitable you would otherwise do blocking i/o in the threads. And having 500 threads idle-waiting for completion of blocking i/o isn't a big deal for hardware for years. |
| Jerry Stuckle <jstucklex@attglobal.net>: Apr 26 02:57PM -0400 On 4/26/2017 2:19 PM, Paavo Helde wrote: > does not support 500 CPU cores. > See examples in boost.asio about how to create a reasonable thread pool > for servicing a large number of connections. Your initial premise is incorrect. According to you, machines with a single core should only be able to run MS-DOS, because pretty much every OS since then has had multiple threads. In fact, on my 2 core, 4 thread machine, I currently have hundreds of threads running. Often times I create multiple threads because I am waiting on multiple events. That doesn't mean all are running code concurrently; in actuality multiple threads in a wait state is very common in a multi-threaded program. In the OP's case, I bet he never has all 500 threads ready to run concurrently. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Paavo Helde <myfirstname@osa.pri.ee>: Apr 26 10:30PM +0300 On 26.04.2017 21:51, Bonita Montero wrote: > In cases where boost.asio is suitable you would otherwise do blocking > i/o in the threads. And having 500 threads idle-waiting for completion > of blocking i/o isn't a big deal for hardware for years. 500 idle threads might not be a big deal (at least not in 64-bit programs), but they might become a problem when they start doing something at the same time. If I understand correctly, that's what OP is doing, he's sending notify_all() and all threads wake up and start doing something, probably much more than they should. The point is that there is no reason to create much more threads than the number of cores, they just tend to eat up all the memory and start to fight with each other over resources. Been there, done that. Also I somehow have the feeling that OP's hardware predates the "for years" you mention. Cheers Paavo |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 26 01:44PM -0700 On 4/26/2017 9:48 AM, Marcel Mueller wrote: > On 26.04.17 15.24, kushal bhattacharya wrote: >> On Wednesday, April 26, 2017 at 5:26:57 PM UTC+5:30, kushal >> bhattacharya wrote: [...] > Most probably you do some blocking I/O operation while you hold the > mutex of the condvar. I basically have to concur here for 10s is a wild number for me wrt using a condvar for signalling. > This could explain a delay in the order of 20 ms > per thread. The answer is simple: don't do that. It leads > multi-threading ad absurdum. Agreed. |
| "Chris M. Thomasson" <invalid@invalid.invalid>: Apr 26 01:50PM -0700 On 4/26/2017 4:56 AM, kus wrote: > thread.I am seeing this situation when very large number of connections > are opened simultaneously.Is it a normal behaviour or i am implementing > something wrong here? Fwiw, my advise is to create a couple of threads per CPU and use async IO wrt the target platform. For instance, on windows use Input Output Completion Ports (IOCP), on a Posix system use the AIO API. Creating a thread per connection is not going to scale at all. |
| porparek@gmail.com: Apr 26 08:54AM -0700 Hi, When I create an object of type boost::function I do it e.g. as follows: boost::function<int(int,int)> boostFun2; Why I cannot create an object of type int(int,int) ? e.g. int(int,int) myFun; great thanks for help |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Apr 26 06:26PM +0200 > boost::function<int(int,int)> boostFun2; > Why I cannot create an object of type int(int,int) ? e.g. > int(int,int) myFun; because the syntax is wrong. The name has to be /before/ the braces. int myFun(int,int); declares a matching function. But, of course, this is not a function object. There are no function objects in the C/C++ language. They are part of the class library, e.g. std::function<> or boost::function. Marcel |
| OpenMP ARB <openmpinfo@gmail.com>: Apr 26 01:56AM -0700 CALL FOR PAPERS IWOMP 2017 - 13th International Workshop on OpenMP September 20-22, 2017 Stony Brook University, Stony Brook, NY, USA http://www.iwomp.org == Background For many years, the OpenMP API has provided a very rich and flexible programming model for shared memory architectures. OpenMP 4.0 is a major advance that adds new forms of parallelism: device constructs for accelerators, SIMD constructs for vector units, and several significant extensions for work-sharing, affinity, and task-based parallelism. OpenMP 4.5 further enhances OpenMP support for today’s complex heterogeneous architectures. To the benefit of applications using the API, a strong ecosystem of compilers, runtime systems, and tools from various vendors and community partners has also emerged. The International Workshop on OpenMP (IWOMP) is an annual workshop dedicated to the promotion and advancement of all aspects of parallel programming with OpenMP. It is the premier forum to present and to discuss issues, trends, recent research ideas, and results related to parallel programming with OpenMP. We solicit quality submissions of unpublished technical papers detailing innovative, original research and development related to OpenMP. == Topics All topics related to OpenMP are of interest, including OpenMP performance analysis and modeling, OpenMP performance and correctness tools, proposed OpenMP extensions, and OpenMP applications in any domain (e.g., scientific and numerical computation, video games, computer graphics, multimedia, information retrieval, optimization, text processing, data mining, finance, signal and image processing and machine learning). Advances in technologies, such as multi-core processors and OpenMP devices (accelerators such as GPGPUs, DSPs or FPGAs), Multiprocessor Systems on a Chip (MPSoCs), and recent developments in OpenMP itself (e.g., devices) present new opportunities and challenges for software and hardware developers. Recent advances in the C, C++ and Fortran base languages also offer interesting opportunities and challenges to the OpenMP programming model. IWOMP 2017 particularly solicits submissions in these areas as well as ones that discuss how to apply OpenMP to additional models of parallelism such as event loops. == Paper Submission and Registration Submitted papers for review should be limited to 12 pages and follow LNCS guidelines. Submission deadline is April 28, 2017. Submit your paper to: https://www.easychair.org/conferences/?conf=iwomp2017. Authors of accepted papers will be asked to prepare a final paper of up to 15 pages. As in previous years, IWOMP 2017 will publish formal proceedings of the accepted papers in Springer Verlag's LNCS series. == Important Dates Paper Submission [Extended]: May 5, 2017 (AOE) Notification of acceptance: May 25, 2017 Deadline for final version: June 8, 2017 == Organizers General Chair: - Abid Malik, Brookhaven National Laboratory Program Committee Co-chairs: - Bronis R. de Supinski, Lawrence Livermore National Laboratory - Stephen L. Olivier, Sandia National Laboratories |
| Juha Nieminen <nospam@thanks.invalid>: Apr 26 06:18AM > vector<double> hour {24, -7777}; > That would have been simpler, but unfortunately, we would have gotten a > vector of two elements (24 and -1). I can't even begin to imagine how -7777 is converted to -1 when cast to a double. |
| 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