in reply to Re: Fork vs pThreads
in thread Fork vs pThreads

Thank you so much for your explanation :) It means a lot to me. So just to see if I understood.

By launching 50 it means that each core is going to have a queue of approx 12 streams to be processed by each core. Only 4 simultaneously.

Because the queue is long, and gets longer because I'm always adding more in each while cycle,the available throughput,cpu and memory gets smaller, causing a bottleneck.

Did I get it? :)

So the fact that one stream is bigger than the other does not impact?

Replies are listed 'Best First'.
Re^3: Fork vs pThreads
by Anonymous Monk on Oct 21, 2013 at 15:46 UTC

    To abuse the fast food analogy where employees are threads, starting a new thread also involves going through HR paperwork before the new thread can do their task. (You really want the task to be more than making a single burger for customer #42 before retiring too)

    Your quad-core restaurant requires a bit of time for one employee to save all their tools away before someone else can change context and use one of the four stations.

    And once you run out of physical ram/floor space for threads to stand in, then you've got to use a bus to swap employees in and out which is horrifyingly slow.

      Thank You :)
Re^3: Fork vs pThreads
by locked_user sundialsvc4 (Abbot) on Oct 23, 2013 at 01:54 UTC

    Actually ... no!   :-)

    As you undoubtedly know, a “process” (or thread ...) has absolutely nothing to do with “a core.”   It is (so much for your, ahem, too-thin attempt at humor at my expense ...) just “an employee.”   This employee (no matter what core(s) (s)he happens to get dispatched upon) “finds work to do, and does it, and in so doing remains just as busy as (s)he possibly can be.”   As do all the other employees in the grease-shack.

    Thanks to the existence of a queue, of a “to-do list,” our intrepid employee will never become overwhelmed, no matter how many tour-buses full of hungry folks show up in the drive-thru.   And this is the aforementioned “key.”   There are only so-many square feet of floor-space in the kitchen, therefore only so many burgers that can be cooked at a time.   This will never change, no matter how many burgers are ordered.   “The optimal burger-throughput,” for this particular restaurant, therefore, is always constant ... and the same thing is true of your computing facility.   So, to serve (however many customers there may be) in the least amount of time, you should pay attention only to the conditions in the kitchen ... not the lobby.   Do not over-commit the kitchen.   Instead, parcel out the workload (whatever it is ...) in such a way as to maintain full-utilization of the physical resources but nothing more.   Yes, customers will have to wait, but they are accustomed to that, if they feel that the wait-time is predictable.   (Furthermore, it is necessary(!) for them to wait, if they are to be served in the least amount of time.)   Do not allow the employees to compete with each other.   Do not over-commit the deep-fat fryer.   Do not permit the order-completion time to become, “due to resource contention,” less than it would be if the restaurant were completely empty.   If it should come to that, keep the hungry-folks outside.   Do not permit them to enter the doorway unless you know that you can serve them consistently.