Announcement

Collapse
No announcement yet.

Effect of Multiple Threads

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Paul,
    The formula is from here. The acceleration is based on the number of cores not threads. If you have 1 core you can only get an acceleration of 1. If you have 2 cores you can only get an acceleration of <= 2. If you have 4 cores you can only get an acceleration of <= 4. If you have 8 cores you can only get an acceleration of <= 8.

    Which means if you have a 2 core system you can use as many threads as possible to achieve the acceleration of near 2. This is an exaggeration: Use 1,000,000 threads if you want to get that acceleration.

    1.898 is the acceleration I get with 25 threads:
    Code:
    'Measured for 2 core system doing 2000 files... Verified
    'Threads    Process Time    Files         Speed (times faster)
    'Used       in seconds      per Thread    for 2 cores
    ' 01        10.17           100           1 (all serialized no speed increase)
    ' 02         5.725           50           1.776
    ' 04         5.542           25           1.835
    ' 05         5.437           20           1.870
    ' 10         5.401           10           1.882
    ' 20         5.363            5           1.896
    ' 25         5.357            4           1.898
    In my case 100 threads would be the max acceleration which would still be <= 2 on my Dual core system. The app selections for threads was to allow the User to try them out to see the time difference between 2 threads and 25 threads and also so I could easily document the differences. I routinely use 25 threads. If the app had 100 threads then I would use 100.

    As you increase the number of threads the speed differences become very small. 25 threads work just fine and not nearly as demanding on the programmer as 100 threads.

    Running the app on your 4 core system should show a definite improvement over mine for 25 thread Process Time. In other words a much greater acceleration.
    Code:
    'Projected for 4 core system doing 2000 files... Unverified
    'Threads    Process Time    Files         Speed (times faster)
    'Used       in seconds      per Thread    for 4 cores
    ' 01         5.085          100           1 (all serialized no speed increase) Process Time based on 5.085 = 10.17/(4 cores/2 cores)
    ' 02                         50
    ' 04                         25
    ' 05                         20
    ' 10                         10
    ' 20                          5
    ' 25         1.3395           4           3.796  if (1.898/2 = X/4) then X = 3.796 projected acceleration.
    '                                         1.3395 = (5.085/3.796) projected Process Time for 25 threads and 4 cores.

    Comment


    • Paul,
      your program is now over 6000 lines long.
      That is because I adhere to the THREAD DOs AND DON'Ts. I'm not going for speed or app size. Mine is a demonstration for using multi-threads to perform a task. As you may have noticed the only process that is overlapped is Process Time. Everything else is serialized.

      Gee,
      And I never learned to type with more than 4 fingers and 2 thumbs. In essence that could be considered 6 thumbs.

      Comment


      • So, it "is a demonstration for using multi-threads to perform a task" but not necessarily be used in practice because as it has no regard for "speed or app size". I am afraid that I read that as probably useless and not a good demonstration.

        Comment


        • Jim,
          That is because I adhere to the THREAD DOs AND DON'Ts.
          Why do that?
          Where did this list come from?
          It's not an immutable list as you've edited the list since the start of this thread, so why not continue to edit the list based on what you now know?

          You do realise that if you run the same code in multiple threads it doesn't result in any interaction between the threads?
          Each thread will be given its own workspace.
          It's one of the advantages you get from using threads correctly, but it's an advantage you've thrown away because you misunderstood how threads work.
          Now you understand them better do you not think it's worth editing the list again?

          Comment


          • Paul,
            I haven't edited the list. I have just added to the list and tried to explain it. My threads do not share arrays between threads other than Command Arrays. Threads work only on their assigned variable and do not call routines that could possibly be shared. As in no shared routines between threads. This promotes separation and no need for semaphores to slow down the processing. They are fire and forget threads. Known as "Perfectly Parallel"

            The list was formulated by me to describe the methods I use. The methods have served me well. Is it a lot of extra code? Yes, says the man with 6 thumbs.

            When you talk about the speed of the app you must consider the app is serialized except for the Parallel Computing (Multi-threaded) part that does its job quite well. Not sure why the threading part is a problem for folks here. Perhaps they understand the processes but lack the 6 thumbs to implement the safeguards I use. Likely it is just too much work for them. Parallel processing done well is a tedious undertaking. Not for the faint of heart.

            Note:
            "My demo is very simple to me." says the guy who routinely works with hundreds of thousands of lines of code. Is that code multi-threaded? Yes, quite definitely. And by the way I am not afraid to explore untraveled vistas. That should be clear from my Source Code posts.

            If it hasn't been clear before, my demo is just a way I can share my methods. Are my methods provocative? Apparently or else we wouldn't still be talking about them.
            Last edited by Jim Fritts; 13 Sep 2020, 11:02 PM.

            Comment


            • Paul,
              Yours still lags quite a bit when processing 2000 files, when data comes from the cache, taking about 50% longer.
              How many times did you run the app with Do 2000 Files selected? Did Prefetch Time match Verify Cache Time? If the 2 times were not close to the same value then the files were not in the cache. I suspect you only ran Do 2000 Files once.

              Note:
              "Perfectly Parallel" threads are designed to run in parallel. If you return them to a serialized configuration as in extracting their guts and putting their guts back into one thread then you will pay for that by adding time to the Overall Time.

              Code:
              'Measured for 2 core system doing 2000 files... Verified
              'Threads    Process Time    Files         Speed (times faster)
              'Used       in seconds      per Thread    for 2 cores
              ' 01        10.17           100           1 (all serialized no speed increase)
              ' 02         5.725           50           1.776
              ' 04         5.542           25           1.835
              ' 05         5.437           20           1.870
              ' 10         5.401           10           1.882
              ' 20         5.363            5           1.896
              ' 25         5.357            4           1.898
              Process Time will go from 5.357 seconds to 10.17 seconds on my machine. That would add 4.813 seconds to Overall Time for each 2000 files processed thereby adding 2 minutes to a run of 50,000 files. So now you should see how important "Perfectly Parallel" threads are. They save you time. And that is why I use 25 threads.

              Gee,
              I guess I could make one version that has only 100 threads. Do you think that would help anyone understand how to do it? It would be a first for me.

              "Processing 2000 files with 100 Threads"

              AKA One File One Thread.

              Comment


              • Code:
                What I have covered in this thread:
                1) My methods and why I use them.
                2) How to build a fairly stable platform which promotes taking measurements.
                3) What is "Perfectly Parallel" and how it can help you perform tasks quicker.
                4) The relationship between cores and acceleration. Acceleration limits.
                5) What is drive saturation and how it affects your results.
                   Both reading and writing are affected.
                6) How CPU usage drops when drive saturation increases.
                7) Drive saturation mitigation.
                8) Provided a demo app that exhibits the concepts that I have discussed.
                9) Offered projections for how the processes would perform on different computer architectures (4 and 8 core systems).

                Comment


                • This thread has more than run its course. It strayed off the original subject somewhat before page 5.

                  Please do what you can to stay on topic, or create a new topic. There is plenty of storage space for us to do so. I believe this will keep the discussion a bit more calm, cool, and collected.
                  Adam Drake
                  Drake Software

                  Comment

                  Working...
                  X