Tag Archives: amd

microsoft, professional, windows

NVIDIA’s first CPU, Project Denver, aims to bring ARM to desktops and servers

At CES in Las Vegas today NVIDIA’s CEO Jen-Hsun Huang announced the company’s first CPU: Project Denver. This is a partnership with ARM, to create “a full custom processor” targeting “high performance computing – servers, PCs, super-computers, cloud computing.” NVIDIA will still licence ARM processors for mobile computing.

Since ARM has in the past focused on the mobile and embedded market, and NVIDIA on GPUs, it is a departure for both companies.

Why? Huang says it is because ARM is “the new standard microprocessor architecture.” Judging by this chart, shown at the press briefing, it is hard to disagree:

image

In a few years, said Huang, “There will be more ARM processors shipped than all the x86 chips ever shipped.”

image

NVIDIA’s press release explains that the purpose of Project Denver is to extend the range of ARM systems upwards:

For several years, makers of high-end computing platforms have had no choice about instruction-set architecture.  The only option was the x86 instruction set with variable-length instructions, a small register set, and other features that interfered with modern compiler optimizations, required a larger area for instruction decoding, and substantially reduced energy efficiency.

Denver provides a choice.   System builders can now choose a high-performance processor based on a RISC instruction set with modern features such as fixed-width instructions, predication, and a large general register file.   These features enable advanced compiler techniques and simplify implementation, ultimately leading to higher performance and a more energy-efficient processor.

The other interesting aspect of Project Denver is its integration with the GPU – as you would expect from NVIDIA:

An ARM processor coupled with an NVIDIA GPU represents the computing platform of the future.  A high-performance CPU with a standard instruction set will run the serial parts of applications and provide compatibility while a highly-parallel, highly-efficient GPU will run the parallel portions of programs.

While we tend to focus most on power efficiency for mobile devices, because we notice how long our batteries last, it is equally important for larger systems. Power consumption and dealing with heat is a key issue for datacentres, while in everyday desktop computing power consumption is a significant proportion of the running cost of an IT system.

Project Denver puts a different spin on Microsoft’s Windows-on-ARM announcement today. The assumption is that Microsoft has in mind a mobile future for Windows; but if Denver takes off it could be important on desktops and servers as well.

Before getting too excited, it is worth recalling how Intel’s Itanium, cruelly dubbed the Itanic, mostly failed in the market. That was partly thanks to design problems, and partly because the industry was too deeply hooked into x86 applications. I also recall Motorola’s doomed attempts to sell Windows NT on PowerPC in the mid Nineties.

Denver could fare better, thanks to the ubiquity of ARM in the mobile world. That said, much will depend on whether a Denver-based system really does offer significant benefits over whatever Intel and/or AMD will have come up with by the time it ships. If it is less than spectacular, Denver will be a hard sell.

intel, software, software development

Intel’s compiler is best for AMD too says software director

2 Comments

I attended Intel’s software conference in Barcelona earlier this week, and took the opportunity to talk to Director of Software Products James Reinders. I asked him about the complaint from the FTC, which I reported on here, that Intel deliberately underperforms on non-Intel CPUs, specifically those made by AMD. Was it a valid complaint?

He was surprisingly (to me) forthright.

It’s not valid. It’s misguided. Intel’s compilers are very high performance. If you use our compiler, you’ll get better performance on Intel or AMD processors than if you used anyone else’s compiler. That’s always been our goal. We believe – I’ll use the words “in general” and that’s a legal disclaimer – in general we’re better. Why don’t I say always? Always is an absolute. Nobody is “always” anything. We are as close to always as we can figure out to be. We have many customers that use our compiler, ship code, because they believe it gets the best performance on Intel and AMD. We will back that. If you find that our compiler is getting less performance on AMD than someone else’s compiler, we consider it a bug. That includes AMD processors.

We settled the suit with AMD, we agreed that we wouldn’t do things we were accused of in future – well, we didn’t do them before. There’s a lot of proof points. AMD used our compiler for benchmarking for a long time. They didn’t do that because we were lower performance.

There are a lot of technical nuances, details of what we do in our compiler that are confusing. One of the challenges is how do we produce a binary that runs best on Nehalem, and on an older Intel processor, or on a processor that supports SSE 2.0 but not 3.0? We have technology in our compiler to try to adapt to that. We mix into that blend AMD, because AMD processors have different capabilities, in the same way that our processors have different capabilities from each other. Yes, people will say, “hey, your compiler’s checking for an AMD processor”. Yes, absolutely, we also check to see if we’re on a Intel processor that only supports SSE 2.0. We have to. AMD processors don’t support the same instructions we do. Our processors have a lot of variety too.

The short answer is that we didn’t do what we’re accused of, we’re very serious about being an excellent compiler for AMD as well as Intel, and this extends to our libraries too.

So that’s telling them. Is he correct and it was a misguided complaint? Well, as I mentioned previously, there are issues of disclosure as well as performance if you are publishing benchmarks; and it is hard to believe that Intel devotes equal effort to optimisation on AMD processors as for its own. Nevertheless I respect Reinders and don’t dismiss his statement. Perhaps Intel’s compiler is OK for AMD after all.