5 ms·
Smacks of poor engineering to me; switching to another platform instead of finding the cause of the problem. "I was hitting some issues with either the schedul
by phugoid 17y ago
Smacks of poor engineering to me; switching to another platform instead of finding the cause of the problem.
"I was hitting some issues with either the scheduler or the memory subsystem, as my code didn’t have any I/O in it."
- RiderOfGiraffes 17y agoWhether there's an underlying fault or not, it's an interesting datum that it ran 5 to 10 times faster under Linux. If nothing else, compiling and running under both platforms gives clues to places problems are happening. We target three different platforms and seeing the performance change from one to the other is really useful.
- blub 17y agoI was under the impression that he used OpenMP on Linux while using low-level threading on Windows.
- flogic 17y agoThat could be the cause but if he couldn't use OpenMP under windows then it's still a legitimate complaint.
- blub 17y agoHe could have, but he couldn't get it to compile. Either way, he should have just used QtConcurrent (since he's using Qt). The performance issue looks like more of an excuse to me; I can think of at least five things to try before changing the OS would even enter my mind.
- billswift 17y agoSome people have small minds without much room for new ideas to enter.
- ajross 17y agoDevelopers are responsible for debugging their platform then? He states that he had a significant speedup in Vista too, which is pretty good evidence that he'd isolated the problem to something in XP. So he needs to decide on what to do, and fixing XP retroactively doesn't seem to be an option. And in any case, the thread scalability of the allocator some of MS's older C runtimes is a known performance issue. I'm not surprised by this at all.
- blub 17y agoWhat happened to: first check your code, then your compiler and as a last resort your OS? The problem was most likely in his hand-crafted threading code.
- rbanffy 17y agoAll facts indicate the problem _was_ the platform. The program ran much faster on Vista, even with the original manual threading. When ported to Linux with OpenMP the problem went away, suggesting it never really existed inside the program.
- joe_the_user 17y agoUh, When you start to hit issues that you have good reason to believe have nothing to do with you, finding the root cause of the issues is not always the best choice.
- rbanffy 17y agoIt's nice to find the root cause, but, sometimes, it can't be done unless you have access to the underlying source code. Too bad Windows doesn't come with it.
- Periodic 17y agoHe stated that one of the biggest reasons he did the switch was because Linux allowed him more freedom in terms of platform, libraries, and tools, while his windows options were limited by his company to Visual Studio 2005 on Windows XP x64. He wanted to just start working on the newer operating systems, but was not allowed to due to corporate budgets or the like.
- jacquesm 17y agoFinding the cause of the problem is something that Microsoft might be able to do if they choose to do so. This is closed source, remember.
- agazso 17y agofree() under Windows XP can be incredibly slow. I once created a big hash table with more than 10000 allocated hash buckets, and freeing it took around 3 seconds (!) on a 3GHz P4. The same code on Linux and OSX took around 3 milliseconds.