VW 7.5 Release
Notes p.11 says how to avoid severe performance degradation by setting
processor affinity for multi-core CPUs. Web searches show that VW isn't the only
application affected this way (nor is it exclusive to Windows). A couple posts
said it is only a problem with CPUs that have Intel Hyper Threading.
You can see from
this chart (http://images.tomshardware.com/2007/07/16/cpu_charts_2007/cpu_table_intel_big.png)
which Intel processors have "HT" instruction sets. I'd appreciate knowing if
someone can confirm there is performance degradation with VW 7.5 on
a non-HT multi-core CPU. HT is not a feature of newer Intel CPUs but it is
expected to be a feature of some future processors.
Does this problem
also affect non-Hyper Threaded multi-core CPUs? Does it affect AMD multi-core
CPUs? Is the problem new to VW 7.5?
I know that setting
processor affinity didn't make any difference when I'd profiled an earlier VW
release on a non-HT multi-core CPU. I'm wondering if this is a new VW 7.5
feature, or if it is just Intel HT specific.
Paul
Baumann IntercontinentalExchange | ICE This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
I don't know about performance, but re affinity we had a problem
running on windows 3002 on XEN on Linux RedHat
with the microsecond clocks shifting around a few hundred microseconds and we HAD to use affinity to tie the VM to one processor. I know thats not what you were asking about, but "affinity" triggered my mind dump :) Paul Baumann wrote:
-- Dennis Smith +1 416.798.7948 Cherniak Software Development Corporation Fax: +1 416.798.0948 509-2001 Sheppard Avenue East [hidden email] Toronto, ON M2J 4Z8 <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@... Canada http://www.CherniakSoftware.com Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP |
There is a way to control an Affinity and priority from inside the
running application... I published the code to do just that in Windows. Look at the package "Win32 PS API" in public Store. I use it regularly. Dennis Smith wrote: > I don't know about performance, but re affinity we had a problem > running on windows 3002 on XEN on Linux RedHat > with the microsecond clocks shifting around a few hundred microseconds > and we HAD to use affinity to tie the VM > to one processor. I know thats not what you were asking about, but > "affinity" triggered my mind dump :) > > Paul Baumann wrote: >> VW 7.5 Release Notes p.11 says how to avoid severe performance >> degradation by setting processor affinity for multi-core CPUs. Web >> searches show that VW isn't the only application affected this way >> (nor is it exclusive to Windows). A couple posts said it is only a >> problem with CPUs that have Intel Hyper Threading. >> >> You can see from this chart ( >> http://images.tomshardware.com/2007/07/16/cpu_charts_2007/cpu_table_intel_big.png) >> which Intel processors have "HT" instruction sets. I'd appreciate >> knowing if someone can confirm there is performance degradation with >> VW 7.5 on a non-HT multi-core CPU. HT is not a feature of newer Intel >> CPUs but it is expected to be a feature of some future processors. >> >> Does this problem also affect non-Hyper Threaded multi-core CPUs? Does >> it affect AMD multi-core CPUs? Is the problem new to VW 7.5? >> >> I know that setting processor affinity didn't make any difference when >> I'd profiled an earlier VW release on a non-HT multi-core CPU. I'm >> wondering if this is a new VW 7.5 feature, or if it is just Intel HT >> specific. >> >> * Paul Baumann * >> IntercontinentalExchange | ICE >> >> >> This message may contain confidential information and is intended for >> specific recipients unless explicitly noted otherwise. If you have >> reason to believe you are not an intended recipient of this message, >> please delete it and notify the sender. This message may not represent >> the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries >> or affiliates, and does not constitute a contract or guarantee. >> Unencrypted electronic mail is not secure and the recipient of this >> message is expected to provide safeguards from viruses and pursue >> alternate means of communication where privacy or a binding message is >> desired. >> > > -- > Dennis Smith +1 416.798.7948 > Cherniak Software Development Corporation Fax: +1 416.798.0948 > 509-2001 Sheppard Avenue East [hidden email] <mailto:[hidden email]> > Toronto, ON M2J 4Z8 sip:[hidden email] > Canada http://www.CherniakSoftware.com > Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP > |
In reply to this post by Paul Baumann
Paul,
When I found this issue, I originally noticed the performance instability on two different Windows Core Duo laptops (1.66ghz and 1.83ghz). After a quick assessment our best working theory is that, while any process scheduler may have to swap the core/cpu under the process due to the usual time sharing of the core/cpu between processes, the Windows one does not seem to prevent the excessive occurrence of this, which in turn leads to CPU cache thrashing. A variety of other apps showed the same performance issues as the VisualWorks VM, and thus we deem this general problem to be non-VM specific. Our testing did not show this to be a problem for Unix based operating systems such as Linux. Some customers also noted that the issue could not be reproduced on desktop computers running Windows. Although it is not confirmed, I suspect the actual problem may be sensitive to the amount of CPU cache available and to how cache sharing among cores is performed in the CPU itself. While dual core CPUs may share the cache memory and thus mask the issue with Windows' process management qualities, swapping a physical CPU under a running process way too much should have a measurable performance penalty because code and data would have to be cached and kept synchronized on every physical cache memory. Thus, if this assessment is correct, Windows computers with multiple physical CPUs (or n-core CPUs with core subgroups that do not share the physical cache of the chip they are on) in which process management is performed naively should run into the same problem regardless of how much cache memory the CPUs have. Of course all this may (or may not) sound great on paper, but nothing beats a measurement of the actual production box running the real production load. Andres. Paul Baumann wrote: > VW 7.5 Release Notes p.11 says how to avoid severe performance > degradation by setting processor affinity for multi-core CPUs. Web > searches show that VW isn't the only application affected this way (nor > is it exclusive to Windows). A couple posts said it is only a problem > with CPUs that have Intel Hyper Threading. > > You can see from this chart > (http://images.tomshardware.com/2007/07/16/cpu_charts_2007/cpu_table_int > el_big.png) which Intel processors have "HT" instruction sets. I'd > appreciate knowing if someone can confirm there is performance > degradation with VW 7.5 on a non-HT multi-core CPU. HT is not a feature > of newer Intel CPUs but it is expected to be a feature of some future > processors. > > Does this problem also affect non-Hyper Threaded multi-core CPUs? Does > it affect AMD multi-core CPUs? Is the problem new to VW 7.5? > > I know that setting processor affinity didn't make any difference when > I'd profiled an earlier VW release on a non-HT multi-core CPU. I'm > wondering if this is a new VW 7.5 feature, or if it is just Intel HT > specific. > > Paul Baumann > IntercontinentalExchange | ICE > > -------------------------------------------------------- > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > > |
Thanks to all for the responses.
It looks like more information and tests are needed to identify a definitive cause. Development hardware doesn't match production hardware. I'm reluctant to set affinity to one core by default just-in-case, but at this point it is looking like a reasonable short-term solution. Paul Baumann -----Original Message----- From: Andres Valloud [mailto:[hidden email]] Sent: Thursday, February 14, 2008 8:32 PM To: [hidden email] Subject: Re: [vw 7.5] visual.exe processor affinity Paul, When I found this issue, I originally noticed the performance instability on two different Windows Core Duo laptops (1.66ghz and 1.83ghz). After a quick assessment our best working theory is that, while any process scheduler may have to swap the core/cpu under the process due to the usual time sharing of the core/cpu between processes, the Windows one does not seem to prevent the excessive occurrence of this, which in turn leads to CPU cache thrashing. A variety of other apps showed the same performance issues as the VisualWorks VM, and thus we deem this general problem to be non-VM specific. Our testing did not show this to be a problem for Unix based operating systems such as Linux. Some customers also noted that the issue could not be reproduced on desktop computers running Windows. Although it is not confirmed, I suspect the actual problem may be sensitive to the amount of CPU cache available and to how cache sharing among cores is performed in the CPU itself. While dual core CPUs may share the cache memory and thus mask the issue with Windows' process management qualities, swapping a physical CPU under a running process way too much should have a measurable performance penalty because code and data would have to be cached and kept synchronized on every physical cache memory. Thus, if this assessment is correct, Windows computers with multiple physical CPUs (or n-core CPUs with core subgroups that do not share the physical cache of the chip they are on) in which process management is performed naively should run into the same problem regardless of how much cache memory the CPUs have. Of course all this may (or may not) sound great on paper, but nothing beats a measurement of the actual production box running the real production load. Andres. Paul Baumann wrote: > VW 7.5 Release Notes p.11 says how to avoid severe performance > degradation by setting processor affinity for multi-core CPUs. Web > searches show that VW isn't the only application affected this way > (nor is it exclusive to Windows). A couple posts said it is only a > problem with CPUs that have Intel Hyper Threading. > > You can see from this chart > (http://images.tomshardware.com/2007/07/16/cpu_charts_2007/cpu_table_i > nt > el_big.png) which Intel processors have "HT" instruction sets. I'd > appreciate knowing if someone can confirm there is performance > degradation with VW 7.5 on a non-HT multi-core CPU. HT is not a > feature of newer Intel CPUs but it is expected to be a feature of some > future processors. > > Does this problem also affect non-Hyper Threaded multi-core CPUs? Does > it affect AMD multi-core CPUs? Is the problem new to VW 7.5? > > I know that setting processor affinity didn't make any difference when > I'd profiled an earlier VW release on a non-HT multi-core CPU. I'm > wondering if this is a new VW 7.5 feature, or if it is just Intel HT > specific. > > Paul Baumann > IntercontinentalExchange | ICE > > -------------------------------------------------------- > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > > -------------------------------------------------------- This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. |
Here is additional data point for the discussion:
I did some unrelated testing over the weekend and what I found is quite interesting. The hardware I was using: Dual Xeon 2.8 MHz with multi threading enabled. So windows server 2003 thinks and shows that I do have 4 processors. I was trying to profile one of the VW methods which was taking a bit more time and decided to play with the affinity a little. Depending on the process affinity for the VW process (1,2,3 or 4) the execution (Time millisecondsToRun:)of the code was either 9500 Ms or 12000 ms - almost 25% difference. One of the CPUs was a real one and another was emulated via multi threading. It looks to me that the performance and affinity is influenced greatly depending on the presence of multi threading trickery on the CPU as well. I wonder if anybody tested this on the AMD processors. For the lack of time did not test with multi threading disabled. Paul Baumann wrote: > Thanks to all for the responses. > > It looks like more information and tests are needed to identify a > definitive cause. Development hardware doesn't match production > hardware. I'm reluctant to set affinity to one core by default > just-in-case, but at this point it is looking like a reasonable > short-term solution. > > Paul Baumann > > > -----Original Message----- > From: Andres Valloud [mailto:[hidden email]] > Sent: Thursday, February 14, 2008 8:32 PM > To: [hidden email] > Subject: Re: [vw 7.5] visual.exe processor affinity > > Paul, > > When I found this issue, I originally noticed the performance > instability on two different Windows Core Duo laptops (1.66ghz and > 1.83ghz). After a quick assessment our best working theory is that, > while any process scheduler may have to swap the core/cpu under the > process due to the usual time sharing of the core/cpu between processes, > the Windows one does not seem to prevent the excessive occurrence of > this, which in turn leads to CPU cache thrashing. > > A variety of other apps showed the same performance issues as the > VisualWorks VM, and thus we deem this general problem to be non-VM > specific. > > Our testing did not show this to be a problem for Unix based operating > systems such as Linux. Some customers also noted that the issue could > not be reproduced on desktop computers running Windows. Although it is > not confirmed, I suspect the actual problem may be sensitive to the > amount of CPU cache available and to how cache sharing among cores is > performed in the CPU itself. > > While dual core CPUs may share the cache memory and thus mask the issue > with Windows' process management qualities, swapping a physical CPU > under a running process way too much should have a measurable > performance penalty because code and data would have to be cached and > kept synchronized on every physical cache memory. Thus, if this > assessment is correct, Windows computers with multiple physical CPUs (or > n-core CPUs with core subgroups that do not share the physical cache of > the chip they are on) in which process management is performed naively > should run into the same problem regardless of how much cache memory the > CPUs have. > > Of course all this may (or may not) sound great on paper, but nothing > beats a measurement of the actual production box running the real > production load. > > Andres. > > > Paul Baumann wrote: >> VW 7.5 Release Notes p.11 says how to avoid severe performance >> degradation by setting processor affinity for multi-core CPUs. Web >> searches show that VW isn't the only application affected this way >> (nor is it exclusive to Windows). A couple posts said it is only a >> problem with CPUs that have Intel Hyper Threading. >> >> You can see from this chart >> (http://images.tomshardware.com/2007/07/16/cpu_charts_2007/cpu_table_i >> nt >> el_big.png) which Intel processors have "HT" instruction sets. I'd >> appreciate knowing if someone can confirm there is performance >> degradation with VW 7.5 on a non-HT multi-core CPU. HT is not a >> feature of newer Intel CPUs but it is expected to be a feature of some > >> future processors. >> >> Does this problem also affect non-Hyper Threaded multi-core CPUs? Does > >> it affect AMD multi-core CPUs? Is the problem new to VW 7.5? >> >> I know that setting processor affinity didn't make any difference when > >> I'd profiled an earlier VW release on a non-HT multi-core CPU. I'm >> wondering if this is a new VW 7.5 feature, or if it is just Intel HT >> specific. >> >> Paul Baumann >> IntercontinentalExchange | ICE >> >> -------------------------------------------------------- >> This message may contain confidential information and is intended for > specific recipients unless explicitly noted otherwise. If you have > reason to believe you are not an intended recipient of this message, > please delete it and notify the sender. This message may not represent > the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or > affiliates, and does not constitute a contract or guarantee. Unencrypted > electronic mail is not secure and the recipient of this message is > expected to provide safeguards from viruses and pursue alternate means > of communication where privacy or a binding message is desired. >> > > -------------------------------------------------------- > This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired. > > > |
Free forum by Nabble | Edit this page |