Quote:
If you increase the number of threads, overhead also increases (see some versions ago where the CPU load was very high when I switched on multi-threading in the Intel library). So I'm not too sure that 4 will be better than 2.
From what I've been reading, multithreading can either help or harm cache utilization. I think that given the cache dependency of your code, the configuration needs to be optional, much like multi-core. What Bojcha posted about the user having control of the number of threads is a good idea.
As for the Intel libraries, I remember seeing documentation at Intel or some other web site that when I was trying to investigate SSE levels, but didn't pay attention to it as it didn't specifically pertain to SSE. Something about static vs. dynamic linking, I think.
(Note: If feeling tl;dr at this point, skip to tl;dr section).
Also, in addition to my routine reminder of the benefit of exception handling for finding sources of crashes more quickly, I'd also like to provide a gentle reminder about investigating the performance degradation issue when upgrading to Composer XE vs. Intel C++ Compiler 10.1. As I said some time ago, it's best not to let it go for 5-10 more versions. The more you code, the more you may have to change. I know that coding more features means the potential for more market share and more money, but I would caution you on placing too high of an importance upon new features / more revenue. Yes, it is important, but it should not blind all other things.
At my prior job at a publicly traded company, this was known as focusing on "capital" projects. New development got classified as a capital expenditure, which meant it could be classified differently from an accounting perspective, and making the balance sheet items that drove stock prices appear "better", and thus keeping stock prices elevated. The unfortunate side-effect is that bug-fixing and other maintenance tasks were "expense" projects, and got put on hold, over, and over, and over again, despite the end-users complaining very loudly about the extra expense that they were incurring on a daily basis because of having to accomodate the software's fragile nature when dealing with a customer face-to-face. Eventually someone understood that the aggregate amount of expense across thousands of locations was far greater than the expense needed to address the bugs and other maintenance items, so expense projects started getting attention again. That did, however, take a few years to happen, and all that while the company was bleeding expense at the thousands of locations because they were too focused on keeping the IT budget looking lean, mean, and capital-oriented.
tl;dr:
- Configurable amount of multi-threading = good
- Threading in Intel libraries might be related to linking.
- Putting off administrative tasks because they don't generate revenue = very likely bad
Register
Login
FAQ
Search
Kidding..
