With over 25 years of experience and more than 40,000 installations worldwide, Cimatron is a leading provider of integrated, CAD/CAM solutions for mold, tool and die makers as well as manufacturers of discrete parts. Cimatron is committed to providing comprehensive, cost-effective solutions that streamline manufacturing cycles, enable collaboration with outside vendors, and ultimately shorten product delivery time.
The Cimatron product line includes the CimatronE* and GibbsCAM* brands with solutions for mold design, die design, electrodes design, 2.5 to 5 axes milling, wire EDM, turn, Mill-turn, rotary milling, multi-task machining, and tombstone machining. Cimatron's subsidiaries and extensive distribution network serve and support customers in the automotive, aerospace, medical, consumer plastics, electronics, and other industries in over 40 countries worldwide.
Cimatron is publicly traded on the NASDAQ exchange under the symbol CIMT. For more information, please visit the company web site at: http://www.cimatron.com
About Cimatron NC Algorithms (Problem statement)
Inside the CIMATRON E Application, the NC package is responsible for creating Numeric Controlled tool paths for mechanical machining. These tool paths are eventually downloaded to an CNC machining center and are used to create the machined parts designed by our customers.
The algorithms used in NC machining are very calculation intensive and one of the ways we see to improve the performance of these algorithms is to enable the use of multiple cores (multithreading) wherever possible. However as these algorithms are used for mechanical manufacturing, stability and correctness of the code are of the highest priority.
The areas where we applied multithreading are complex involving a large number of C++ classes, with thousands of lines of code and are also evolving during the ongoing development of our product. We already knew that there might be a problem with the multi threading code as we had a few reports from our CQA department of serious problems which would occur intermittently and the new multi threaded areas were considered a "prime suspect".
The two main problems we faced with applying multithreading to our algorithms can be defined as follows:
- How do we ensure that the multithreaded code is working correctly in all cases and not just in the specific examples we test during development? We have to ensure that the multithreaded code is fully tested.
- How do we ensure that during future development, that the multithreading portions of the code remain stable? It is very easy to "break" multithreaded code or make it unstable.
Intel Thread Checker
Intel Thread Checker was used to check the correctness of the multithreaded code. (as opposed to it's performance). Running under the VTune environment, Intel Thread Checker enabled us to run our application and at the end of the application receive a report on any multi threading errors. In order to do this we created a special build of the product with full debugging information for the areas of the code involved in multithreading, as well as a set of very small test files to run. Also the source code of the areas where multi threading was used was modified slightly to increase the exposure of multithreading for the test purposes.
The Challenge: Problems faced (and overcome) during testing.
When running Intel thread checker, we first found that our application would not run at all, because of incompatibility between our software protection and the requirements of Thread Checker. Once these problems were solved, we found an initial problem with the size of our software. Cimatron E is a large product. However using Thread Checker's ability to fully instrument only specific areas of the code, we also managed to overcome this problem. Finally we were left with the problem of performance. The type of instrumentation that is involved with Thread Checker slows down the performance appreciably. A typical test file which would run for 4 seconds under normal operations, took several hours under Thread Checker. In one case where we tried a more "real" test file, with normal running time of about one minute – the calculations took over 8 days to complete under Thread Checker.
The Results – "Slow but steady wins the race"
After each test run with Thread Checker, we analyzed the results. In each case there were some results we discounted as incorrect reports of errors in areas where there was no real multithreading involved. However in several cases we found real problems inside our code (overuse of mutable class members) thanks to Thread Checker, and when these problems were fixed and the tests rerun, the problems were no longer reported. The problems were mainly problems of multiple writes to the same data from different threads. These problems would have been very difficult to find during normal analysis of the code as the areas of the code where they occurred were several layers deep inside the code which was multi threaded. Only once the problems were found by Thread Checker could we seriously analyze and solve the specific problems. As a result, the serious intermittent problems reported by our CQA department ceased to reoccur.
As a result of the success of Thread Checker in finding the problems, we have decided to wider the tests in order to ensure maximum exposure of multi threading when using Thread checker and to ensure that the product, when delivered to our customers, will be as fast and also as bug free as possible. Even when no changes are planned in the areas of the code which are multi threaded, we will be using Intel Thread Checker on a regular basis as part of our CQA process in order to ensure that the code remains stable and is not "broken" by accident.
The challenge to provide scalable application forces multi-threading development. In large systems this development is done on the basement of old single-threading-in-mind developed code. It is impossible to continuously validate correctness of such a system without reliable and robust tools such as Intel Thread Checker is.