   Cloak and Dagger
  Last night I created a hand-coded assembly language function to concatenate two 4 x 4 matrices.  I created the same function in C++ (Microsoft Visual Studio) to run for comparison.  Oddly, the Visual Studio code ran 67% faster than my hand-coded assembly language work.  Smelling a rat, I took the markedly inefficient C++ dissasembly, line by line, from the C++ function and pasted it into my application.  After adjusting it so that it would compile under ML.EXE, it ran 50% slower than my hand-coded assembly function.  This was the result I should have been getting all along.  The exact same instructions were executing on the CPU, in the exact same order, between the C++ function and my copy-and-paste program.  The only difference was that one test was running inside Visual Studio and the other outside.  I moved both tests - the C++ disassembly and my own hand-coded assembly - into a ring 0 device driver and tested them with all interrupts disabled for the duration of the test (which had the effect of basically disabling Windows' time slicing, and with that, all the attendant little tricks designed to slow down software not created by MS).  Voila, the same figures held - my code was 50% faster and fell just short of 6,000,000 matrix concatenations per second.  That is a significant speed.In the next few days I'll be posting a utility that allows users to disable and enable hardware interrupts from user mode so that you can test how badly your own project is being affected by these behind-the-scenes little manipulations being engaged in by Windows.  If your app takes a sudden, 2x or 3x jump in speed when interrupts are disabled, you have a good indication that Windows may be crippling you by design.  There are ways to shut that situation down and I'll be getting into more details on how to do it over the coming weeks.   
  I think its perhaps a bit early to be wearing so thick a tinfoil hat... Honestly, what would Microsoft gain by slowing down a user's programs for no good reason? Obviously the OS has some overhead, like all OSes. While it may not be optimal for your very specific case, I'm sure they are doing close to the bare minimum for the general case. Honestly, if disabling interrupts has the effect of preventing task switching as you say, then it also prevents background services from running, which is where the speedup is coming from. Many of the services are vital, those that aren't are usually safe to disable, and doing so should also result in some speed increase.There's also plenty of compiler flags, both easy and not-so-easy to set for optimum speed. Furthermore, we can't make any real judgement about the validity of your benchmark until you share the code.There plenty of legitimate reasons why some overhead exists, and insinuating that the Windows OS, itself, intentionally slows down 3rd party programs is ridiculous.   ;  Moved to Lounge. If you can convince a different moderator to move it again, great. But don't bother asking me, since the Lounge is the best place for conspiracy discussion.   ;Quote:Original post by SubStandardLast night I created a hand-coded assembly language function to concatenate two 4 x 4 matrices.  I created the same function in C++ (Microsoft Visual Studio) to run for comparison.  Oddly, the Visual Studio code ran 67% faster than my hand-coded assembly language work.  Smelling a rat, I took the markedly inefficient C++ dissasembly, line by line, from the C++ function and pasted it into my application.  After adjusting it so that it would compile under ML.EXE, it ran 50% slower than my hand-coded assembly function.  This was the result I should have been getting all along.  The exact same instructions were executing on the CPU, in the exact same order, between the C++ function and my copy-and-paste program.  The only difference was that one test was running inside Visual Studio and the other outside.  I moved both tests - the C++ disassembly and my own hand-coded assembly - into a ring 0 device driver and tested them with all interrupts disabled for the duration of the test (which had the effect of basically disabling Windows' time slicing, and with that, all the attendant little tricks designed to slow down software not created by MS).  Voila, the same figures held - my code was 50% faster and fell just short of 6,000,000 matrix concatenations per second.  That is a significant speed.In the next few days I'll be posting a utility that allows users to disable and enable hardware interrupts from user mode so that you can test how badly your own project is being affected by these behind-the-scenes little manipulations being engaged in by Windows.  If your app takes a sudden, 2x or 3x jump in speed when interrupts are disabled, you have a good indication that Windows may be crippling you by design.  There are ways to shut that situation down and I'll be getting into more details on how to do it over the coming weeks.Yes, but can it do MP3-beating compression?;  Facepalm.Obviously, you should have used a hard cat to compile your space pipe, because comparing what you made to a long dog is not as applicable as you might think.   ;Quote:Yes, but can it do MP3-beating compression?If I wanted it to, just as your code could, if you were inclined to devote the required time and effort to it.  My goal is an extreme FPS rate, to free up CPU time for AI and physics.  As you can see, with today's programming dogma, it isn't very challenging to reach that goal.  The code speaks for itself.  It does what it does and no amount of judgement or lashing out (especially without seeing it) will change that.  I have more than twenty major adjustments lined up to employ; this was just the first.  The end user doesn't care how a game was written.  They only care how it plays with no concern for what it took to get to that point.  I'm not writing my engine to impress other programmers; getting moved to the lounge and being called "stupid" is exactly what I expect -it's the behavior I rely on; it's this mentality that makes it so easy to do what I'm doing.  I would be asking questions, not making declarations before I ever saw the code or had any of the facts.  But people are what they are and they don't do that, so it makes my job very easy: bury anything else on the market performance-wise.  The door is wide open to doing that.As for the effect on Windows - yes, I know all that; this was a test and nothing more.  It was C++ generated code running in both cases.  The only thing that changed between the tests was the environment: the same C++ generated code ran 234% slower outside the VS environment with interrupts enabled, inside a standard app - with the only change being a non-VS application executing the same code.  That was the only point.You can move me to the lounge but you cannot prevent the end product from being released.  If you thought this was irritating, wait until you see the final result. And that cannot be moved anywhere.   ;  > EAT ROPE;  leap of logic is very leapy   ;Quote:leap of logic is very leapyI agree.  That's why the code will speak for itself.  It's difficult to lash out at real code running on a real computer.   ;Quote:Original post by SubStandard[...]You can move me to the lounge but you cannot prevent the end product from being released.  If you thought this was irritating, wait until you see the final result. And that cannot be moved anywhere.This being a forum, the main concern is not your work or your product but your communication. You've presented nothing interesting in that regard, as you have no helpful information, impressive facts or figures, entertaining stories, or otherwise useful content in your communication.All you've done is join a community that doesn't know you and make apparently-arbitrary accusations against a large, likable megacorp. If you want us to care, you'll have to do better than that.I could easily recreate your results if I were so inclined, and I don't have any doubt that you observed what you say, but I do doubt the conclusions you draw from it both because your method of analyzing the problem is very strange and your accusations are rather conspiratorial. My guess would be that the C++ code ran faster because the function was inlined, but that you ignored the 'main' code and only looked for your particular function, which in the non-inlined form is probably far slower. Alternately, I'd guess that your benchmark is invalid in any of a hundred ways.   