Comments for Preshing on Programming http://preshing.com Thu, 17 May 2012 10:56:11 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Finding Bottlenecks by Random Breaking by Jeff Preshing http://preshing.com/20110723/finding-bottlenecks-by-random-breaking#comment-11293 Jeff Preshing Thu, 17 May 2012 10:56:11 +0000 http://preshing.com/?p=1156#comment-11293 xperf rocks, and random breaking is by no means a substitute. However, it can be a forehead-slap moment when you realize it’s possible to identify certain (obvious) bottlenecks this way <em>at all</em>. At least, for me it was. One thing I didn’t mention in the article is that when breaking, there’s no guarantee you’ll end up looking at the guilty thread, for some reason. A couple times, I’ve had to check the busiest thread IDs using <a href="http://technet.microsoft.com/en-us/sysinternals/bb896653" rel="nofollow">Process Explorer</a>, then switch to those threads to view their stacks after breaking. xperf rocks, and random breaking is by no means a substitute. However, it can be a forehead-slap moment when you realize it’s possible to identify certain (obvious) bottlenecks this way at all. At least, for me it was.

One thing I didn’t mention in the article is that when breaking, there’s no guarantee you’ll end up looking at the guilty thread, for some reason. A couple times, I’ve had to check the busiest thread IDs using Process Explorer, then switch to those threads to view their stacks after breaking.

]]> Comment on Finding Bottlenecks by Random Breaking by Bruce Dawson http://preshing.com/20110723/finding-bottlenecks-by-random-breaking#comment-11281 Bruce Dawson Thu, 17 May 2012 06:20:53 +0000 http://preshing.com/?p=1156#comment-11281 I've used this technique before, and it certainly can work, but I'm not sure it's a great idea these days, except for the most highly focused of performance problems. Given that you can get a high-frequency high-quality CPU sampling profiler for free, what is the advantage to random breaking? Xperf: up to 8 KHz sampling rate Random breaking: up to 0.5 Hz sampling rate Granted, the learning curve for xperf is significantly higher, but for any non-trivial work it is well worth it. http://randomascii.wordpress.com/2011/09/03/xperf-for-excess-cpu-consumption/ I’ve used this technique before, and it certainly can work, but I’m not sure it’s a great idea these days, except for the most highly focused of performance problems. Given that you can get a high-frequency high-quality CPU sampling profiler for free, what is the advantage to random breaking?

Xperf: up to 8 KHz sampling rate
Random breaking: up to 0.5 Hz sampling rate

Granted, the learning curve for xperf is significantly higher, but for any non-trivial work it is well worth it.

http://randomascii.wordpress.com/2011/09/03/xperf-for-excess-cpu-consumption/

]]> Comment on Roll Your Own Lightweight Mutex by Bruce Dawson http://preshing.com/20120226/roll-your-own-lightweight-mutex#comment-11280 Bruce Dawson Thu, 17 May 2012 06:16:01 +0000 http://preshing.com/?p=2749#comment-11280 Another reason to not roll your own is that the OS locks are likely to have additional features that your lock won't have. On Windows I can think of several: 1) When you create a critical section you can specify a spin count, which can give a nice balance between spinning and doing a kernel transition to wait on a semaphore. 2) Windows 7 has a flag you can set (RTL_CRITICAL_SECTION_FLAG_DYNAMIC_SPIN) which automates the process of choosing the correct spin count. 3) Critical sections in Windows are ETW instrumented so that you can follow wait chains -- to allow sophisticated profiling. As I said in a recent post: "The ability to profile your code trumps any small performance improvement." http://randomascii.wordpress.com/2012/05/05/xperf-wait-analysisfinding-idle-time/ Another reason to not roll your own is that the OS locks are likely to have additional features that your lock won’t have. On Windows I can think of several:

1) When you create a critical section you can specify a spin count, which can give a nice balance between spinning and doing a kernel transition to wait on a semaphore.
2) Windows 7 has a flag you can set (RTL_CRITICAL_SECTION_FLAG_DYNAMIC_SPIN) which automates the process of choosing the correct spin count.
3) Critical sections in Windows are ETW instrumented so that you can follow wait chains — to allow sophisticated profiling.

As I said in a recent post:
“The ability to profile your code trumps any small performance improvement.”
http://randomascii.wordpress.com/2012/05/05/xperf-wait-analysisfinding-idle-time/

]]> Comment on xkcd Password Generator by Graham http://preshing.com/20110811/xkcd-password-generator#comment-11201 Graham Wed, 16 May 2012 06:26:29 +0000 http://preshing.com/?p=1404#comment-11201 I've found that the small American English dictionary (sudo apt-get install wamerican-small) makes a good source of words. It has 51175 entries, but after stripping plurals and limiting to 3-8 character words, there are only 25077 entries. Then all you take a random selection of 25077 common words: grep -v \'s /usr/share/dict/american-english-small | egrep '^.{3,8}$' | shuf -n 100 | fmt I’ve found that the small American English dictionary (sudo apt-get install wamerican-small) makes a good source of words. It has 51175 entries, but after stripping plurals and limiting to 3-8 character words, there are only 25077 entries.

Then all you take a random selection of 25077 common words:

grep -v \’s /usr/share/dict/american-english-small | egrep ‘^.{3,8}$’ | shuf -n 100 | fmt

]]> Comment on Memory Reordering Caught in the Act by Jeff Preshing http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11190 Jeff Preshing Wed, 16 May 2012 02:22:04 +0000 http://preshing.com/?p=3026#comment-11190 The main reason reordering is detected so rarely in this sample is because the semaphore timing is unpredictable and I introduced randomness to compensate. You could probably detect reordering much more frequently if you use a different synchronization method in the worker threads; for example, busy-waiting on a flag. I chose not to do this in the sample because then, I'd need to ensure correct memory ordering around the flag, and that would draw attention away from the place where I really wanted to demonstrate reordering. Also, as Bruce Dawson points out below, memory reordering is not necessarily an artifact of CPU instructions being switched. Memory reordering tends to be more the result of the way CPU caches work: If you are really interested in those details, I'd recommend Appendix C of <a href="http://kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2011.01.02a.pdf" rel="nofollow">Is Parallel Programming Hard</a>. The main reason reordering is detected so rarely in this sample is because the semaphore timing is unpredictable and I introduced randomness to compensate. You could probably detect reordering much more frequently if you use a different synchronization method in the worker threads; for example, busy-waiting on a flag. I chose not to do this in the sample because then, I’d need to ensure correct memory ordering around the flag, and that would draw attention away from the place where I really wanted to demonstrate reordering.

Also, as Bruce Dawson points out below, memory reordering is not necessarily an artifact of CPU instructions being switched. Memory reordering tends to be more the result of the way CPU caches work: If you are really interested in those details, I’d recommend Appendix C of Is Parallel Programming Hard.

]]> Comment on Memory Reordering Caught in the Act by Jeff Preshing http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11189 Jeff Preshing Wed, 16 May 2012 01:42:47 +0000 http://preshing.com/?p=3026#comment-11189 Ha. Windows guy alert! Fixed now. Ha. Windows guy alert! Fixed now.

]]> Comment on Memory Reordering Caught in the Act by Jeff Preshing http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11187 Jeff Preshing Wed, 16 May 2012 00:54:18 +0000 http://preshing.com/?p=3026#comment-11187 Hi Bruce. Indeed, my original wording made it sound like instruction reordering was the sole reason for memory reordering. I've since revised that paragraph. In this post, I don't really want to say too much about the causes of memory reordering -- just the effects. Hi Bruce. Indeed, my original wording made it sound like instruction reordering was the sole reason for memory reordering. I’ve since revised that paragraph. In this post, I don’t really want to say too much about the causes of memory reordering — just the effects.

]]> Comment on Memory Reordering Caught in the Act by Roy http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11183 Roy Wed, 16 May 2012 00:24:44 +0000 http://preshing.com/?p=3026#comment-11183 On my Dual Dual-Core Xeon 5150, I get a significantly higher rate of reordering... 163090 reorders detected after 3000077 iterations - 5.4% of the time. That's not rare. On my Dual Dual-Core Xeon 5150, I get a significantly higher rate of reordering…

163090 reorders detected after 3000077 iterations – 5.4% of the time. That’s not rare.

]]> Comment on Memory Reordering Caught in the Act by Adam White http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11182 Adam White Wed, 16 May 2012 00:19:08 +0000 http://preshing.com/?p=3026#comment-11182 I have little to say about the article. I just want to compliment you on your awesome Jumpman avatar. It really brings back thoughts of my childhood spent on a C64. I have little to say about the article. I just want to compliment you on your awesome Jumpman avatar. It really brings back thoughts of my childhood spent on a C64.

]]> Comment on Memory Reordering Caught in the Act by Jeff Preshing http://preshing.com/20120515/memory-reordering-caught-in-the-act#comment-11174 Jeff Preshing Tue, 15 May 2012 22:11:36 +0000 http://preshing.com/?p=3026#comment-11174 I tried it on a Core 2 Duo E6300 in Win32. The rate of occurrence indeed increased from 1 out of 7500 to 1 out of 4700 or so. I tried it on a Core 2 Duo E6300 in Win32. The rate of occurrence indeed increased from 1 out of 7500 to 1 out of 4700 or so.

]]>