Bobcat in Servers?

[JF-AMD]

Because the question has been asked here:

http://bit.ly/hHwL8t

[Pietro sk]

i saw more than 5 news about ARM / atom servers recently
bobcat makes sense in servers too.. (if atom , arm does - why not ?)

[BaronMatrix]

Because the question has been asked here:

http://bit.ly/hHwL8t

At first I thought you guys had lost your minds, but you clearly delineated the advantages of Opteron ONLY for server. Not that I would consider Bobcat for a sever.

[JF-AMD]

i saw more than 5 news about ARM / atom servers recently
bobcat makes sense in servers too.. (if atom , arm does - why not ?)

It all you have is a hammer, all your problems look like nails. Who is pushing ARM on servers? ARM. The reality is that the market is big enough yet to merit the work.

There are also people developing Itanium servers. Just because it is in the news does not mean that a.) there is enough of a market yet and b.) they will be successful.

[abinstein]

i saw more than 5 news about ARM / atom servers recently
bobcat makes sense in servers too.. (if atom , arm does - why not ?)

It all you have is a hammer, all your problems look like nails. Who is pushing ARM on servers? ARM.

Right on!

Those tiny power-efficient cores do not scale out and their aggregated memory and I/O bandwidth are usually too low. In contrast, a 2-socket Opteron 6000 server has 8 channels of memory and two 16-bit HT3 links for I/O; the 16 or 24 (or 32 next year) cores work in single system image sharing the system resources, bringing the benefits of consolidation. To get the same number of cores one needs 8 to 16 dual-core ARM (or Bobcat) systems working independently. My guess is the tiny core solution will end up consuming more power and deliver less performance.

[MU_Engineer]

Right on!

Those tiny power-efficient cores do not scale out and their aggregated memory and I/O bandwidth are usually too low. In contrast, a 2-socket Opteron 6000 server has 8 channels of memory and two 16-bit HT3 links for I/O; the 16 or 24 (or 32 next year) cores work in single system image sharing the system resources, bringing the benefits of consolidation. To get the same number of cores one needs 8 to 16 dual-core ARM (or Bobcat) systems working independently. My guess is the tiny core solution will end up consuming more power and deliver less performance.

There are some uses where very low-powered CPUs that don't scale up or out very well can succeed. Think of a home or small business file server or NAS, print server, or gateway. You're probably only going to have one of those machines, it does not need to be all that powerful, and it likely won't need to scale out to need multiple many-cored CPUs. Those would be decent candidates for low-power, not-very-expandable CPUs. There is apparently a market for them as quite a few vendors have debuted products using said chips, such as HP's Micro Server, which uses a 1.3 GHz Athlon II X2 and some ECC RAM.

[Pietro sk]

funny or not, in server shops atom things are present several months ago.. its question of time, if arm will be visible in such shops

on the other note, specs of those "servers" are quite funny, now everybody can call "chinese scientifical calc" a server too...
------
note how many atom boards are on sites...
example http://www.supermicro.com/products/motherboard/Atom/ (new atoms too)
----------
edit
google has published report about their ram errors, stability..
after reading that article, im happy that i use ECC

[Athlotron]

Because the question has been asked here:

http://bit.ly/hHwL8t

I found it interesting, your hinting at AMD making some SOC's, and seeing which of their core products would be suitable for it. This is exciting, and all of this for Cloud Computing.

AMD has it's head in the clouds now?

[JF-AMD]

AMD has sold over 2M Opterons into the cloud so far, I'd say we are there.

[BaronMatrix]

funny or not, in server shops atom things are present several months ago.. its question of time, if arm will be visible in such shops

on the other note, specs of those "servers" are quite funny, now everybody can call "chinese scientifical calc" a server too...
------
note how many atom boards are on sites...
example http://www.supermicro.com/products/motherboard/Atom/ (new atoms too)
----------
edit
google has published report about their ram errors, stability..
after reading that article, im happy that i use ECC

There is no doubt that simple file serving can use less beefy chip with better IO but that's a very small amount. The best use for those would be as "late night" replacements. But due to the fact that it's called the world wide web, the Internet would eat them up. SMB could mabye use them but Adelaide will cover the low power arena nicely.

[dm7000s]

Reviving this older thread a little, because although AMD might or might not have a bobcat style server CPU in the works, Intel has:

Intel, Facebook Talk Up New “Micro” Servers:

"Intel expects most makers of micro servers will prefer new energy-efficient members of its Xeon line of server chips, including two new models now in production and a new version expected in the second half of the year based on a design called Sandy Bridge. Intel next year also plans to offer a server-style version of its Atom design used in portable computers that is expected to draw less than 10 watts–compared with a range of 15 watts to 65 watts for comparable Xeons."

So in case of "AMD might not have": "AMD", please read the above bold sentence, and don't be late to the party

Edit: More on this -> Intel Plans on Bringing Atom to Servers in 2012, 20W SNB Xeons in 2011

[AussieFX]

I think it's time for intel and AMD to put their fighting to bed - particularly intel.

ARM is a threat and if intel/AMD get together to fight this they might have some chance. I would prefer to see that happen than have AMD take an ARM license which a lot of people are suggesting AMD should do.
Sitting back and saying we have the right solution when the market appears to be asking for more will only end in trouble.

You have to cover the oppositions moves, and in this case intel aren't the opposition.

[maduroutmb]

Extremely low power server chips are in direct opposition to the current trends toward hardware utilization, consolidation, and efficiency. You take a small number of high-performance chips which are close to dense and efficient power and cooling systems and you queue up workloads in such a way that they have very high utilization rates (e.g. with virtualization). The ARM/Atom/Bobcat "server" chips are meant to shine in isolated hardware where low power usage is most valuable because the utilization will never be very high. Print and low-utilization file servers: in other words, the sort of systems that are supposed to be eliminated by consolidation.In most commercial cases, ARM servers are the equivalent of trying to drive in a screw with a hammer (as JF pointed out).

Home NAS is one area where such systems could do well, except that I believe that consolidation will replace them even here. The idea of a home server, which at once acts as a file server, media and gaming center (with the ability to stream content to thin clients around the house), and a traditional desktop. The power to perform several jobs at once (i.e. sending files to dad on a business trip via Tonido, streaming a movie to the kitchen for mom, streaming audio to one child's room while the other kids to play a video game in the den) means that the total power consumption number aren't terribly different. PCI-E wired router cards(you can functionally do this with a master-mode wireless card)and the return of PCI cable/DSL/fiber modems would allow a user to literally have one box for their home with thin clients (a good opportunity for Bobcat or Atom/ION devices but likely not ARM) located by other displays in the kitchen or bedrooms.

[scorpiDragon]

I see where Bobcat and for that mater Trinity could come in real handy, is in the workstation market turn the G34 socket into an FM3 socket (with 1974+ pins = 3x PCI-e 2.0 links; 1x HT3 link to bridge; 1x HT link to HTX socket or second socket).

[JF-AMD]

ARM is a threat and if intel/AMD get together to fight this they might have some chance. I would prefer to see that happen than have AMD take an ARM license which a lot of people are suggesting AMD should do.

ARM has really low power. But, once you add:

ECC
64-bit memory addressing
Coherent links to allow for more than 1 socket
More than 2 cores
Higher performance to match current low power processor choices.

...you have something that is actually now drawing the same power as an x86 processor. Except that it can't run x86 code natively. There just isn't viable today.

[hyc]

ARM is a threat and if intel/AMD get together to fight this they might have some chance. I would prefer to see that happen than have AMD take an ARM license which a lot of people are suggesting AMD should do.

ARM has really low power. But, once you add:

ECC
64-bit memory addressing
Coherent links to allow for more than 1 socket
More than 2 cores
Higher performance to match current low power processor choices.

...you have something that is actually now drawing the same power as an x86 processor. Except that it can't run x86 code natively. There just isn't viable today.

Mmm. I'd say you have something drawing 10-15% less power than x86 worst case, because you don't have the godawful instruction decoder.

[maduroutmb]

the godawful instruction decoder.

It's interesting though that the special case that CISC originally meant to solve, limited RAM, is now alive and well in the form of limited L3. That's not a justification for the massive silicon overhead that the decoder requires, but it is food for thought when dismissing CISC architectures out of hand.

[abinstein]

the godawful instruction decoder.

It's interesting though that the special case that CISC originally meant to solve, limited RAM, is now alive and well in the form of limited L3. That's not a justification for the massive silicon overhead that the decoder requires, but it is food for thought when dismissing CISC architectures out of hand.

The more interesting thing is what gives the "CISC" x86-64 "performance" today is terrible memory inefficient.

Take a look at assembled of any SSE program segments. Not only the average instruction size is 6~8 bytes, but also lots of time the compiler purposely align instructions to 16-byte or 32-byte boundaries. Wasting memory space is what x86-64 compiler does for getting good performance.

So what's the benefit of CISC, or in particular x86?

[Pietro sk]

how ironic, apple went from POWER to x86

[Am486DX100]

the godawful instruction decoder.

It's interesting though that the special case that CISC originally meant to solve, limited RAM, is now alive and well in the form of limited L3. That's not a justification for the massive silicon overhead that the decoder requires, but it is food for thought when dismissing CISC architectures out of hand.

The more interesting thing is what gives the "CISC" x86-64 "performance" today is terrible memory inefficient.

Take a look at assembled of any SSE program segments. Not only the average instruction size is 6~8 bytes, but also lots of time the compiler purposely align instructions to 16-byte or 32-byte boundaries. Wasting memory space is what x86-64 compiler does for getting good performance.

So what's the benefit of CISC, or in particular x86?

The only way to get beyond a boundary is to be inefficient by design. If the said "design" can be rid of/or can get rid of the earlier baggage, then it can survive. If the said "design" is needed, then it has to be worked out in a less efficient manner. Trade-offs are trade-offs.

...

[maduroutmb]

Take a look at assembled of any SSE program segments. Not only the average instruction size is 6~8 bytes, but also lots of time the compiler purposely align instructions to 16-byte or 32-byte boundaries. Wasting memory space is what x86-64 compiler does for getting good performance.

Very interesting. But I think that the argument has been made that x86 is so bloated that, at this point, it's a terrible representative for the idea of CISC in general. I can enable AMDLive! on my Phenom 9950 if I want. I would assume that the amount of memory needed to designated an operation is proportional to the total number of operations that must be distinguished. Would you say that a major overhaul of x86 (or a completely new CISC ISA) could avoid a significant portion of the waste that you brought up?

[abinstein]

Take a look at assembled of any SSE program segments. Not only the average instruction size is 6~8 bytes, but also lots of time the compiler purposely align instructions to 16-byte or 32-byte boundaries. Wasting memory space is what x86-64 compiler does for getting good performance.

Very interesting. But I think that the argument has been made that x86 is so bloated that, at this point, it's a terrible representative for the idea of CISC in general. I can enable AMDLive! on my Phenom 9950 if I want. I would assume that the amount of memory needed to designated an operation is proportional to the total number of operations that must be distinguished. Would you say that a major overhaul of x86 (or a completely new CISC ISA) could avoid a significant portion of the waste that you brought up?

The point you raised here is really not CISC vs RISC, but x86 vs non-x86. So we should look at them separately.

On x86 vs non-x86, the PC market definitely favors the former. It is for the same reason that the OS market favors Windows (or to some degree Linux) and the handheld market favors ARM. These market-favored specs all have baggage because they wouldn't have survived without supporting those baggage. So it's natural that x86 or Win32 won't be optimal for any next generation workload. IMHO, there is not much we can do either.

On CISC vs RISC, the two use completely different philosophy, and RISC is the way to get better performance or performance per watt. (There is not a single popular CPU with good performance per watt that does not actually implement RISC.)

Does that mean we can make a major overhaul of x86? It depends on the struggle between the two forces above. A danger of relying too much on baggage, however, is that it makes it more difficult for the lines of products venture into new territory. Both x86 and Windows are facing such problem. I don't expect x86/Windows to compete as-is with ARM/whatever in the handheld or ultra-low power markets. A major overhaul OTOH will break backward compatibility and make x86/Windows irrelevant.