Trial Run for the CFinder Concurrency Analysis Tool
by Kevin Farnham
to check if an application is threaded and if the threads are running concurrently. This tool is aiming at providing developers a quick way to test their applications for parallelism.
Testing CFinder on a Threading Building Blocks app
I tried out the CFinder application on a program I had adapted for investigating of the task stealing mechanism in Threading Building Blocks (TBB), the open source project for which I'm currently "community manager." For my experiments, I had adapted the StringFinder example in the TBB "Getting Started" guide. You can see the results of my experiment in my post "TBB Task Stealing on a Quad-Core Windows System".
I tried out CFinder using my adapted StringFinder application. As you can see from my "Task Stealing" post, I had already proven that the program utilizes all four cores in my processor, with 222 seconds of work being completed in 63 seconds. This implies that an average of 3.52 processor cores were active each second.
So, knowing all of this in advance, I was curious to see what CFinder would tell me. I'm not exactly sure how to read the results that CFinder displays, but here is what the "Concurrent Level" pull-down showed me after my StringFinder application had completed its run:
Clearly, concurrency level 3 dominated the run. Why wasn't more time spent at concurrency level 4, since I have a quad-core system? I'm not sure at the moment. In a sense, I'm comparing apples and oranges (the timing analysis applied in the TBB software and the CFinder analysis). In addition, CFinder itself is running my StringFinder application, so I have an extra process running when CFinder is analyzing StringFinder's performance. Surely Windows will allocate resources differently under differing circumstances. So -- I'm really not all that troubled by the numbers. Everyone agrees that my app is utilizing my quad-core processor in a highly effective manner.
CFinder is a nice little free tool for quickly analyzing the degree to which a Windows program executes concurrently in a specific run (or set of runs). It's a clear step up from the simple timing of execution instances that I applied for years to test the effect of edits to my multithreaded applications. I think I'll keep it!