14 DAY TRIAL // AMD and Intel finally get some real competition in the Brazos/Atom arena. Qualcomm’s SnapDragon S4 is already inside notebooks that will launch later this year with Microsoft’s Windows RT.
We are very curious about what the performance level is.
It’s most unfortunate that Windows RT doesn’t support legacy x86 software, as we would have been able to quickly benchmark the ARM-based Krait against Intel’s low-performing Atom processor AMD’s new Brazos 2.0 platform.
On the other hand, there is an upside to Microsoft’s “no x86 legacy” decision.
If legacy software were supported, the Windows RT operating system would have been quite bulkier and the programing overhead would have brought ARM’s processors only disadvantages.
We complained many times in the past that programmers are stuck in legacy x86 thinking and that many new features of the new architectures available in the x86 market are not used.
In fact, most programmers don’t even bother with getting the best performance on as many platforms as possible. This is a strange thing as, up until now, AMD and Intel were the only two platforms available for usual Windows software.
If there were four or twelve different architectures running on Windows platforms and programmers had to optimize for each one in part, we would have understood some mishaps or decisions against investing in optimizing and concentrating on compatibility.
But there were only two architectures available, and the vast majority of software makers didn’t even bother to tweak Intel’s compiler to make sure it’s not sabotaging AMD’s performance on their own software.
As we discussed back here, Intel’s compiler is widely used and it’s a very good piece of software. Intel invests billions into this development and then offers it for free to programmers – and that’s wonderful.
The problem is that Intel also makes sure that AMD’s processors will perform as bad as possible on any software compiled with the Intel compiler.
The simple problem is that the compiler makes the program ask the processor for its identification string. If the answer is anything but “Intel Genuine,” the program will ignore any architecture improvements or functional units as SSE3 or SSE4 and will run in the most un-optimized mode possible.
This problem can be resolved quite simply by modifying your own software not to ask such a question and simply check for functional availability. Is SSE3 available on this processor? Then let’s use the SSE3 optimized run path.
Well, for the past two decades programmers never even bothered to make sure their software runs well on AMD computers, although the effort would have been minimal.
The most recent obvious problem was with Adobe’s Photoshop that refused to run on AMD AthlonXP processors, saying SSE2 was not available although those CPUs were SSE2-capable and compatible.
It took Adobe quite some time before issuing a patch.
Now, Microsoft practically tells programmers to work with a little bit more interest and program separately for ARM and x86. If they want to have software running on Windows 8 and Windows RT, then they should work just as much for ARM as they do for x86.
If this weren't done, ARM’s CPUs would have always been in a disadvantage, as most programmers wouldn’t have bothered to write code separately for ARM.
Don’t get us wrong, it’s not as much as programmers don’t want to work, are lazy or ignorant. We believe it’s a financial decision made by the software companies paying those programmers.
Let’s pay some more work hours to make sure our software runs well on AMD-based computers that our customers use. Let’s not!
We believe that Windows RT-based laptops powered by ARM processors have a real chance to achieve a 20-hour battery life and we can’t wait to see how they’ll compare with AMD’s Brazos 2 and Intel’s Clover Field.