It's improved, but I wouldn't go so far as to say it's "vastly improved". One of the things to keep in mind about 32-bit performance on Itanium (and Itanium 2) is that there are two different ways to measure it that end up with very different results. The Itanium has pretty fast 32-bit performance (relatively speaking) when you run a 32-bit application in a 64-bit OS. And it has substantially worse performance when it boots up a 32-bit OS and runs 32-bit applications. So if you were to boot up Windows 95 on it and run Quake you probably wouldn't be very impressed, but if you boot up Windows XP 64 and run Quake it's actually not that bad. This was a design choice - the thinking is that running 32-bit Windows 2000 on Itanium wouldn't happen (or at least would be very rare), so we minimized support for it in hardware.
32-bit performance was not our design target. We built the hardware on-chip to natively run 32-bit apps (and 16-bit apps), but we pretty much devoted the design to 64-bit performance. The 32-bit performance merely needed to be "good enough". The idea is that if you are working in a 64-bit OS (say, Linux, for example) and you, for example, discover that you don't have a 64-bit copy of Gimp and you can't find it anywhere, rather than recompiling, you can just grab the standard 32-bit version off of the web and run it.
32-bit performance was not our design target. We built the hardware on-chip to natively run 32-bit apps (and 16-bit apps), but we pretty much devoted the design to 64-bit performance. The 32-bit performance merely needed to be "good enough". The idea is that if you are working in a 64-bit OS (say, Linux, for example) and you, for example, discover that you don't have a 64-bit copy of Gimp and you can't find it anywhere, rather than recompiling, you can just grab the standard 32-bit version off of the web and run it.
Facebook
Twitter