EETimes: Microsoft calls for 16-core server SoCs

[Idontcare]

Microsoft calls for 16-core server SoCs

A Microsoft executive called for a new class of multicore system-on-chips to drive the lower power servers needed for tomorrow's data centers. But he poured cold water on ARM-based chip vendors, hoping to get design wins in such systems.

"I've been involved in instruction-set architecture transitions multiple times, and they are extremely painful," said Dileep Bhandarkar, a distinguished engineer in Microsoft's data center group, speaking at the Linley Data Center Conference here.

"The rule of thumb is to make that kind of change you have to have at least a sustainable 2x performance improvement per dollar or per watt—and ARM is not there," he said.

http://www.eetimes.com/electronics-news/4212631/Microsoft-calls-for-16-core-server-SoCs

Hmmm...Google and Apple may feel differently.

 

[JFAMD]

Hmmm.

Bobcat has 2 cores @ 9W TDP or 4.5W per core.

A Bulldozer HE has 16 cores @85W TDP or 5.3W per core.

And I am pretty sure you would get better performance out of a bulldozer core than a bobcat core.

I am betting a 16-core Bulldozer HE would give you better performance per watt than a 16-core bobcat would. And you can run 2 or 4P, vs. 1P for an SOC.

Oh, and I agree on the ARM statement. If you think about it, there will be a windows for ARM but you also have to port apps, so while it seems interesting, you have far fewer apps supported.

 

[cbn]

More info from the article IDC linked...

The breadth of server software used in today's data centers makes use of ARM unlikely in the foreseeable future, even through Microsoft announced it will support ARM in the next version of Windows, he added.

Instead, Bhandarkar called for 16-core SoCs based on Intel Atom or AMD Bobcat cores. Such chips should integrate all the core logic and I/O functions the companies now put in separate chips, he said. "There's a huge opportunity using these smaller cores to be more energy efficient, and we are talking to both AMD and Intel [about that]," he added.

 

[Arkadrel]

Bobcat has 2 cores @ 9W TDP or 4.5W per core.

A Bulldozer HE has 16 cores @85W TDP or 5.3W per core.

16-Core Bulldozer HE x 4P = 64-Cores for pretty little power usage.

My first thought after I hit the link in the first post to the artical.... isnt this exactly what bulldozer is?
MS looking to buy some bulldozers hehe

Hellva coincidence they mention wanting 16-core low watt/core cpus, when amd is doing that with their bulldozers.

 

[cbn]

"The rule of thumb is to make that kind of change you have to have at least a sustainable 2x performance improvement per dollar or per watt—and ARM is not there," he said.

I thought it was interesting that MS is mentioning both price and power efficiency as criteria to port server to another uarch.

16 Bulldozer ULV cores vs 16 atom cores vs 16 Bobcat cores (without GPU) vs 16 ARM cores. Assuming all have appropriately size caches, how much would die size factor into both manufacturing cost and retail cost?

 

[cbn]

Speaking of die sizes I wonder how ARM would strategize to undercut?

I've read that power consumption varies with the cube of voltage and linerarly with clockspeed.

To me that implies a balance needs to be struck with the die size.

If the core die size is too small voltage needs to be higher in order to make performance targets. (trading power efficiency for a lower possible price)

If the core die size is larger voltage can drop to meet performance targets (trading higher manufacturing cost for better power efficiency).

 

[podspi]

Hmmm.

Bobcat has 2 cores @ 9W TDP or 4.5W per core.

A Bulldozer HE has 16 cores @85W TDP or 5.3W per core.

And I am pretty sure you would get better performance out of a bulldozer core than a bobcat core.

How much of that 9W is the GPU, though? Still, it almost seems like Bulldozer was designed to kill the "tons of weak cores" market.

(Not implying BD cores are weak, but they do appear to be many).

 

[cbn]

Still, it almost seems ike Bulldozer was designed to kill the "tons of weak cores" market.

(Not implying BD cores are weak, but they do appear to be many).

I agree, the Bulldozer module approach (sharing resources between two cores) seems like a great way to increase the efficiency/die size ratio.

Still It will be interesting to see how the following two variables factor into the strategies.

1. Physical IP: EDIT: What I originally wrote here was technically wrong.

2. Hyperthreading: This is present on atom. ARM also claims this (along with 64 bit) is coming for later versions of their CPUs.

EDIT: Just wondering if Hyperthreading and Bulldozer Module are mutually exclusive? I just did some Internet searching and noticed a quote by JF-AMD saying that SMT was a "band aid to a long pipeline and poor latency". (Sorry if this is dumb question. I am primarily interested in the small CPUs, so I don't read the threads on SB and BD that much)

 

[extra]

16 bobcat cores in a server though...you'd also need more than 1 channel of ram, etc, etc--that might take some of the power savings out of the equation. I would think that for little home servers that just use one or two cores and are mostly idling, bobcat would be perfect, but for things where your server would be using 16 cores and a ton of ram, you'd be better off with something designed for that, like sandy bridge or bulldozer or w/e.

 

[cbn]

AMD or Intel?

Who would be the most likely to build one of these small x86 CPU core (atom, bobcat) server SOCs?

In what other ways besides SOC purchase price could AMD or Intel lower equipment costs?

The way I see things (which isn't saying much at all) MS is trying to play some type of balancing act between equipment costs and electricity costs. However, with this mention of wanting to run chips without air conditioning it sounds like equipment costs are starting to become a larger priority (someone correct me if I am wrong here. I know next to nothing about servers.)

To further simplify its design, it is moving to using outside air for cooling with minimal use of air conditioning and moving the temperature of its data centers toward 85 degrees Fahrenheit.

 

[JFAMD]

Keep in mind that the exercise that I just did on a Bulldozer HE was based on current TDPs. There would be nothing stopping us from creating, for instance, an EE version with even lower TDP.

There are several very prominent cases of people I cannot name that are getting custom versions of parts. When you say you want to buy a 100K, you have the ability to specify some things.

 

[Voo]

EDIT: Just wondering if Hyperthreading and Bulldozer Module are mutually exclusive? I just did some Internet searching and noticed a quote by JF-AMD saying that SMT was a "band aid to a long pipeline and poor latency". (Sorry if this is dumb question. I am primarily interested in the small CPUs, so I don't read the threads on SB and BD that much)

Well since every module still has its own execution units HT should work. Though HT obviously puts more strain on the frontend, which I assume would be a problem for BD since they're already sharing it.

However, with this mention of wanting to run chips without air conditioning it sounds like equipment costs are starting to become a larger priority

I'd take every bet it's more about electricity and the whole infrastructure - cooling a large datacenter is a pretty big challenge

 

[JFAMD]

Well since every module still has its own execution units HT should work. Though HT obviously puts more strain on the frontend, which I assume would be a problem for BD since they're already sharing it.

I disagree on the bottleneck issue. bottlenecks occur when you have mismatched resources. If your execution pipelines can only handle, let's just say, 50 executions per cycle, but your front end can issue 100 executions, then you can have a bottleneck.

If your pipeline can handle 100 executions but you can only schedule 50 per cycle, then you have the opposite problem, which is poor efficiency and under utilized pipelines. Assuming that you can add HT to either scenario to fix it is a mistake.

To make HT work effectively you need to match the scheduler and pipeline resources, regardless.

 

[Voo]

I disagree on the bottleneck issue. bottlenecks occur when you have mismatched resources. If your execution pipelines can only handle, let's just say, 50 executions per cycle, but your front end can issue 100 executions, then you can have a bottleneck.

If your pipeline can handle 100 executions but you can only schedule 50 per cycle, then you have the opposite problem, which is poor efficiency and under utilized pipelines. Assuming that you can add HT to either scenario to fix it is a mistake.

To make HT work effectively you need to match the scheduler and pipeline resources, regardless.

Ok I should've elaborated that more (was in a hurry). My assumption was that the BD isn't designed to be able to utilize 100% of both modules, because if it were you wouldn't have much of an advantage of "sharing" it. So if the frontend can handle 10 instructions, but both modules could in theory handle 6, HT wouldn't be of much use. But sure you can have the same problem without the module approach as well.

But then there has been lots of new information about BD which I haven't totally kept up, but that's how I understand it.

 

[JFAMD]

Each core has its own integer scheduler, so the pipelines stay fed.

 

[JFAMD]

And this should be of assistance:

http://blogs.amd.com/work/2010/11/29/really-little-cores/

 

[bryanW1995]

Nice link, I think that highlights AMD's (and probably intel's) thought process nicely.

 

[JFAMD]

I have had a customer say to me "I absolutely have to have an ARM core." Oh, and it needs to be faster. Oh, and it needs to be fully x86 compliant. Oh, and it needs to be able to support multiple sockets so I can consolidate servers.

Congratulations, you just realized you need an Opteron.

 

[sonoran]

I have had a customer say to me "I absolutely have to have an ARM core." Oh, and it needs to be faster. Oh, and it needs to be fully x86 compliant. Oh, and it needs to be able to support multiple sockets so I can consolidate servers.

Congratulations, you just realized you need an Opteron.

An ARM core that's x86 compliant. I'd have had to ask "Do you actually know anything about computers?" But I guess there's a reason I'm not in sales.

 

[JFAMD]

They do know. That is the problem. If ARM could run any x86 code natively, that would be a killer product. But it can't.

When all of the ARM news came out this month how many people though "ARM with windows? game over." Until they realized that ARM windows won't run x86 windows apps.

Everyone wants a $200 netbook; they just expect the performance of a $500 notebook. And they get frustrated when they cant't get it. Which is why they had high returns.

 

[cbn]

When all of the ARM news came out this month how many people though "ARM with windows? game over." Until they realized that ARM windows won't run x86 windows apps.

There are a few rumors floating around websites that Windows 8 will be some type of Cloud based OS.

Engadget also has this to report: http://www.engadget.com/2010/12/13/microsoft-to-demo-new-slate-pcs-windows-8-tablet-functionality/

Microsoft's is also reportedly eschewing a central app store for native tablet apps and instead encouraging software companies to build HTML5 -based web apps. That certainly sounds a lot Google's Chrome strategy (and a strategy that could backfire since HTML5 apps will work on Chrome OS devices and iPad equally well)

 

[Dark Shroud]

There are a few rumors floating around websites that Windows 8 will be some type of Cloud based OS.

Engadget also has this to report: http://www.engadget.com/2010/12/13/microsoft-to-demo-new-slate-pcs-windows-8-tablet-functionality/

That just isn't going to happen. There will be some web based functions but Win8 will be a full OS.

And there is a big difference between IE9's full hardware accelerating everything and Chrome that only accelerates Java Script.

 

[JFAMD]

There are a few rumors floating around websites that Windows 8 will be some type of Cloud based OS.

Engadget also has this to report: http://www.engadget.com/2010/12/13/microsoft-to-demo-new-slate-pcs-windows-8-tablet-functionality/

Yeah, wednesday morning I woke up to find out that my cable company had a fiber cut on their network.

Totally Cloud-based OS will not happen until ISP service is on par with the waterworks. I have had 1 day without water in the 15 years I have been in this house. Can't say the same for internet service.

 

[zebrax2]

There are a few rumors floating around websites that Windows 8 will be some type of Cloud based OS.

Engadget also has this to report: http://www.engadget.com/2010/12/13/microsoft-to-demo-new-slate-pcs-windows-8-tablet-functionality/

As JFAMD said i doubt Microsoft would go cloud with Windows 8 considering the Internet infrastructure not only of the united states but also the majority of the 2nd and 3rd world countries.

 

[Ajay]

Totally Cloud-based OS will not happen until ISP service is on par with the waterworks. I have had 1 day without water in the 15 years I have been in this house. Can't say the same for internet service.

Bingo! Though, within a corporate campus, working within a cloud should fair better. The problem is that the large companies that would be ideal target for cloud computing are multi-state and multi-national - though they do have the leverage to get high quality SLAs.