(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Friday, August 31, 2007
Off Topic: Blaming the Victims
Why no, we weren’t ready. We were “ready” for a rock-solid, innovative operating system with 50% or more managed code, the transactional WinFS file system, and other compelling features. And we were ready for it sometime around when you told us to expect it, not two years later. What were we thinking?
The lukewarm, apathetic response to the Vista you actually shipped is clearly our fault. We were not ready. Thanks for reminding us.
Frankly, the world wasn’t 100 percent ready for Windows Vista.
Microsoft Corporate Vice President Mike Sievert, quoted by C|Net
Why no, we weren’t ready. We were “ready” for a rock-solid, innovative operating system with 50% or more managed code, the transactional WinFS file system, and other compelling features. And we were ready for it sometime around when you told us to expect it, not two years later. What were we thinking?
The lukewarm, apathetic response to the Vista you actually shipped is clearly our fault. We were not ready. Thanks for reminding us.
Comments on “Off Topic: Blaming the Victims”:
<< Home
Hey, whatever.. I'm happy running linux with vmware of winxp for my development environment.
..and if I want a 3D desktop, I can run Compiz or Beryl; not vista.
..and if I want a 3D desktop, I can run Compiz or Beryl; not vista.
As an aside, WinFS wasn't ever "transactional": it is/was essentially a metadata layer *on top* of NTFS, not a replacement for NTFS. The transactional FS features are implemented as an enhancement to NTFS ("TxF"), and were delivered as part of Vista.
# posted by 
: 2:25 AM
: 2:25 AM
Sounds like you're confusing Vista with the brochure Microsoft released 4 years ago. The world will never be ready for actual Vista. Microsoft better go back to the drawing board.
Sounds like you're confusing Vista with the brochure Microsoft released 4 years ago. The world will never be ready for actual Vista. Microsoft better go back to the drawing board.
I am definitely (and defiantly) confused. It is my fault that I am not ready for Vista.
I am definitely (and defiantly) confused. It is my fault that I am not ready for Vista.
I'm ready for Mac OS X Leopard which will come next month. Until then, I'm happily working with Tiger.
I am definitely not ready for that much managed code -- at least not the way MS implements .net's CLR.
I'll start with some performance results for a problem domain of significant meaning to me -- floating point computation (heavily used in graphics). Managed Fp intensive code runs between 2 to 3 times slower than good native code. (and by "good" I don't mean the smelly turds squeezed out of the back end of the MS compiler -- I mean what comes out of a recent version of the Intel compiler.)
Don't get me wrong -- I think C# is a good language -- I even think that, despite their tendency to have a ridiculous number of classes, MS has done a decent job with the .net class libraries -- no, the problem I have is with jitted code in general (I can already hear the cries of "HERETIC" echoing down the tubes of the internet).
A jit compiler has to be fast -- really fast. And in the short time it has, it can't do a very sophisticated job of generating code. And even if it is blindingly fast, for large apps, (think millions of lines of code -- apps that take many hours to compile conventionally) the startup overhead is fatal (It's already bad enough to wait half a minute for photoshop to start up -- imagine it as 10 minutes)
So for an app like this, you need to pre-compile anyways.
"But Wait!", I hear you say -- "what about the potential for dynamically recognizing hot spots and re-optimizing them -- wouldn't that give the potential of making the code even faster than statically compiled code?"
"You said 'potential' twice" I reply.
In fact, the MS CLR does not fulfill this potential and do this. It happens to be an area of active research (that's a polite way of saying that no one really understands how to make it work in the real world yet).
Firstly, on the small scale, a good OOO processor (like the Core 2) already plucks the low hanging fruit in this area -- and does it dynamically in hardware to boot. So to make a difference, you need to do it on a larger scale. And many algorithms for this sort of optimization have n-squared or worse performance characteristics -- so things get slow to compile very soon.
The problem is that every cycle you spend re-optimizing is a cycle that's not doing real work. If you optimize too early, it might not have been as hot as you thought. If you wait too long, and you're sure the spot is really hot, most of the work at that spot might already be finished -- and again, the reoptimization was just so much masturbation.
What about doing this on spare processor cores, you ask... That can reduce the impact, but not eliminate it, as that work on the other core will pollute the shared cache, steal memory cycles etc. And if the spot is that hot, there may not be any spare cores -- you might have hired someone like me to parallelize that code.
(Lets not even talk about eating power and shortening battery life on laptops -- Vista does enough of that already)
Another problem I have with the MS CLR is the inability to temporarily suspend garbage collection -- that makes it useless for hard real-time.
No, .net CLR is great for UI code where heavy computational performance does not matter -- and there's lots of code that falls under this category -- but it's no good for system level stuff or performance critical things. So I'm just as happy that Vista does not have 50% managed code.
But I'm even happier to be working on OSX :-)
-- Ian Ameline.
I'll start with some performance results for a problem domain of significant meaning to me -- floating point computation (heavily used in graphics). Managed Fp intensive code runs between 2 to 3 times slower than good native code. (and by "good" I don't mean the smelly turds squeezed out of the back end of the MS compiler -- I mean what comes out of a recent version of the Intel compiler.)
Don't get me wrong -- I think C# is a good language -- I even think that, despite their tendency to have a ridiculous number of classes, MS has done a decent job with the .net class libraries -- no, the problem I have is with jitted code in general (I can already hear the cries of "HERETIC" echoing down the tubes of the internet).
A jit compiler has to be fast -- really fast. And in the short time it has, it can't do a very sophisticated job of generating code. And even if it is blindingly fast, for large apps, (think millions of lines of code -- apps that take many hours to compile conventionally) the startup overhead is fatal (It's already bad enough to wait half a minute for photoshop to start up -- imagine it as 10 minutes)
So for an app like this, you need to pre-compile anyways.
"But Wait!", I hear you say -- "what about the potential for dynamically recognizing hot spots and re-optimizing them -- wouldn't that give the potential of making the code even faster than statically compiled code?"
"You said 'potential' twice" I reply.
In fact, the MS CLR does not fulfill this potential and do this. It happens to be an area of active research (that's a polite way of saying that no one really understands how to make it work in the real world yet).
Firstly, on the small scale, a good OOO processor (like the Core 2) already plucks the low hanging fruit in this area -- and does it dynamically in hardware to boot. So to make a difference, you need to do it on a larger scale. And many algorithms for this sort of optimization have n-squared or worse performance characteristics -- so things get slow to compile very soon.
The problem is that every cycle you spend re-optimizing is a cycle that's not doing real work. If you optimize too early, it might not have been as hot as you thought. If you wait too long, and you're sure the spot is really hot, most of the work at that spot might already be finished -- and again, the reoptimization was just so much masturbation.
What about doing this on spare processor cores, you ask... That can reduce the impact, but not eliminate it, as that work on the other core will pollute the shared cache, steal memory cycles etc. And if the spot is that hot, there may not be any spare cores -- you might have hired someone like me to parallelize that code.
(Lets not even talk about eating power and shortening battery life on laptops -- Vista does enough of that already)
Another problem I have with the MS CLR is the inability to temporarily suspend garbage collection -- that makes it useless for hard real-time.
No, .net CLR is great for UI code where heavy computational performance does not matter -- and there's lots of code that falls under this category -- but it's no good for system level stuff or performance critical things. So I'm just as happy that Vista does not have 50% managed code.
But I'm even happier to be working on OSX :-)
-- Ian Ameline.
# posted by : 1:39 AM
: 1:39 AM<< Home
