4 Replies Latest reply: May 16, 2012 9:08 PM by Hayton RSS

How do multi-threaded programs perform when run on a single-thread processor?

Hayton Community Member
Currently Being Moderated

Here is a question to which I strongly suspect I already know the answer.

 

There is a long-running series of complaints by users of McAfee consumer AV products that mcshield, the on-access scanner and so central to the product, performs extremely badly on many older machines, especially those with Windows XP. Most, but not all, of those older machines seem to have Pentium P4 processors. Ignoring for now the inconvenient minority with multi-core processors and/or hyperthreading, that means that most of those with complaints about mcshield have a PC with a single-core single-thread processor.

 

The performance issues break down into two groups : memory usage, and extremely high CPU usage for extended periods. We can ignore the memory issues. It's the high CPU usage which is cause for concern. It doesn't show up, as a rule, on newer PCs with more than a single core; I can't say whether anyone with a single-core machine with hyperthreading is affected, but none of those who have mentioned their system specs seem to have hyperthreading so it's possible but unproven.

 

The program code for this product is written, as far as I can find out, in a variant of C - C, C#, or C++.  It is almost certain that the code is written for a multithreading architecture and/or has been compiled with the appropriate compiler switches set to optimise the code for multi-core machines and multi-threading. That's just a guess, but it's probably correct.

 

So program code written for a multithreaded application, intended for the latest multi-core processor machines, is being run on older machines with "legacy" architecture. It's easy to put two and two together and say that when such a program takes over a PC for five or ten minutes at 90% CPU usage it must be because it was never intended to run on an older architecture, but I don't know enough to say that this is definitely so.

 

So the question in the Subject Header is quite an important one, and I hope that someone here can give a (fairly) concise explanation. What exactly would happen when you run a multithreaded program on an old single-core, single-thread P4 machine (even one with a 3GHz processor and 3Gb of RAM)?

 

I look forward to reading the contributions from anyone who can give an explanation.

  • 1. Re: How do multi-threaded programs perform when run on a single-thread processor?
    JFFulcrum Community Member
    Currently Being Moderated

    With multi-threading app in single-core system Windows CPU scheduler work is no differ with running multiple applications in same time. It is split CPU time into time slices (130 ms) and within slices to quantums (10 ms). The forefront app (which window is active & have user input focus) will receive 75% of timeslice, other apps will share remaining 25%, by 10 ms parts (we claim that all apps have same priority). In case of multithreaded apps every process created by app is threated as another app. So, if one app created many processes, they all will fight for CPU time with other apps with equal opportunities. Furthermore, scheduler itself consume some CPU time for processes/apps switching, not much, but notable when amount of processes growth. So running multi-threaded apps in system with single CPU/core will result in a performance hit. Usually this should not greatly affect the forefront app - it still receive about 75% of CPU time, but if this app is also multi-threaded, their secondary processes will be in trouble with CPU time underfunding.

     

    If there are a high-priority processes in system, than things will become much worse - high-priority processes always receive a >90% of all whole timeslices, and only when they go to sleep other processes/apps have hope to get the CPU time.

     

    All above is about Windows XP, in Vista & 7 things changed, at least quantums became 1 ms long and just from this scheduler have way better flexibility to offer CPU time to apps.

  • 2. Re: How do multi-threaded programs perform when run on a single-thread processor?
    Hayton Community Member
    Currently Being Moderated

    Thank you for the reply, JFFulcrum.  Someone seems to have jumped the gun and declared this question answered, but it wasn't me ... there are one or two things I still need to know.

     

    You say that your answer applies to XP, and in fact most of the problems are on machines with P4 processors running XP - although there are some users with the very-high-CPU problem whose machines have a different processor and/or OS; I'll make a note of all those non-XP/non-P4 exceptions, because they might help identify the underlying problem.

     

    The forefront app (which window is active & have user input focus) will receive 75% of timeslice

     

    How does this apply to a situation where the forefront app might be a browser window, a Word document, or whatever it might be, and mcshield is constantly running at a system level? Whenever any file creation or modification takes place mcshield is there monitoring it. Sometimes, with XP/P4, mcshield will take over the machine completely for minutes at a time, so it is getting most or all of the timeslice, and lots of timeslices as well. So far no-one has found the underlying cause, which is why I'm looking at the processor/multi-threading angle.

     

    If there are a high-priority processes in system, than things will become much worse - high-priority processes always receive a >90% of all whole timeslices, and only when they go to sleep other processes/apps have hope to get the CPU time.

     

    According to Process Explorer the threads in mcshield run with a Base and Dynamic priority of between 8 (Normal) and 15. The higher figure is below Realtime (24) but above High (13). In the Threads list for mcshield there are 22 entries for CreateThread, and that number is fairly constant in normal (low-CPU) operation. Some of the threads appear to be more active than others, but those with the highest priority do not necessarily have the highest amount of CPU time. There is also the question of context switching : how important is it? One of the threads in this screenshot has over a million context switches, other threads have only a few hundred or a few thousand.

     

    mcshield threads in procexp.JPG

  • 3. Re: How do multi-threaded programs perform when run on a single-thread processor?
    JFFulcrum Community Member
    Currently Being Moderated

    I`m sorry for my English, have not much time so make use of translator.

     

    To understand Windows XP CPU scheduler work, think of a multi-lane highway which at some point turns into single lane. In this place there is a traffic cop, who in a certain period of time decided which of the lanes to pass the car, every time to time. It checks lanes for the presence cars sequentially from left to right. The key is that until the lane have waiting cars, he will pass they and not moving to the next lane. He also passes red cars at first among all the cars waiting, but only within the same lane. The priority of the application / process determines the lane into which he falls, ana a sign of an active user application - color.

     

    Then, there are different ways for antivirus app to do it job when application file system activity occurs. First, it may have scanner process with high priority, but in sleep state when no activity present. So every timeslice scheduler will check the high priority lane, but there are will be always a one car, so it will pass it (one quantum) and immediately go to the next lanes. When the user app make an activity, AV process comes out of sleep state, so scheduler pass it to CPU until he done the work and fall to sleep state again, other lanes in that time play Angry Birds.

     

    Second, it may have scanner process with normal priority, when no activity present. Every timeslice scheduler will pass it equally with user app, but with no work to do AV process quickly release its time back to scheduler (and other apps). When the user app make an activity, AV process make itself to higher priority (or make secondary process with priority needed), so scheduler again pass it to CPU until he done the work and fall back to normal priority (or just killed child process), other lanes in that time still play Angry Birds.  

     

    Really good AV software will just make a hook to disk operations, suspending it, and do it work in background (in normal or lower priority). Unfortunately, very little number of apps correctly support async filesystem operations, so most apps will just hung in waiting of disk operation completion, wasting their given CPU time instead of masquerading disk activity and letting user do something other.

     

    Context switching in context of task scheduler app is different thing^ there are two 'spaces' in Windows (and most other OSes): user and kernel/system. User space is where applications run, they have no direct access to hardware resources and in access of the memory addresses are limited to registred as their private space during the start of the app. But they of course have needs for some other memory spaces and hardware resources, they make it via calls to a userspace parts of system kernel and device drivers. Context switches, in a rough approximation, mirror this activity of apps.

     

    Definitly, if we continued here, i will describe the 'Microsoft Windows Internals by Mark E. Russinovich and David A. Solomon' book like 'FOR DUMMERS' series, so may be for you will be better to get to this book directly.

  • 4. Re: How do multi-threaded programs perform when run on a single-thread processor?
    Hayton Community Member
    Currently Being Moderated

    Once again, thank you for taking the time to reply to this question. I like your analogy of the way the XP CPU scheduler works :-)

     

    I shall try to get hold of a copy of "Windows Internals Part 1" in the next week or two - it was the subject of a Technet blog a few weeks ago

    (Book of the Fortnight – Windows Internals Part 1, 6th Edition - TechNet UK - Site Home - TechNet Blogs)

     

    This whole area of multi-threaded programs is very complex, but you've done a great job explaining some of the complexity.

More Like This

  • Retrieving data ...

Legend

  • Correct Answers - 4 points
  • Helpful Answers - 2 points