ARM cranks up cache and memory designs for servers

ARM Holdings wants chip makers to bring more cores and cache to bear as they craft server chips based on its Cortex family of system-on-chip (SoC) designs, and to that end the company is boosting the on-chip caching and main memory controllers of its current ARMv7 and future ARMv8 designs to make them better able to compete …

[cbf123]

I think you've got your terminology wrong. big.LITTLE mixes A-15 and A-7 cores so you can idle on the low-power low-performance A-7 and then switch over to the faster A-15 when there's lots of work to do.

See http://www.arm.com/products/processors/technologies/bigLITTLEprocessing.php for more details.

[alain williams]

cbf123 is correct

There are 2 different processor cores, one powerful but energy hungry; the other slow but energy light. To the applications the processors look the same, the operating system can switch between them in 20 microseconds. The OS can also run both at the same time putting appropriate tasks on each one. You can also vary the frequency of the cores as needed.

See big.LITTLE Processing with the Cortex-A15 and Cortex-A7 Processors page 5 has a nice graph.

Brilliant!

[kb]

The problem with ARM..

Is it doesn't hold a candle to even first gen Core and Phenom based chips when it comes to IPC, which is instructions per clock for those that don't know. The IPC of the new Xeon and Opteron chips just curbstomps anything that ARM has and while you can try to make SOME of that up by adding more cores as we've seen with AMD that approach only goes so far.

To get an ARM chip to even Phenom I levels of IPC would basically blow the power budget all to hell thus killing the big selling point of ARM There has already been talk from ARM holdings about "dark silicon" in their latest mobile chips because using all the transistors at once would give you a battery life of squat so unless they can come up with a new design that can give Xeon performance at closer to ARM power envelopes i don't see this catching on except for maybe some niche applications. After all if the ARM systems sucks instead of sips power why not just use X86 which has a much larger software library?

[Robin]

Re: The problem with ARM..

Isn't the idea that you're doing more with each instruction? So the IPC is less relevant?

The engine capacity of a Ducatti motorbike "doesn't hold a candle" to that of a V8 muscle car, but I know which one I'd rather have going round a racetrack.

[pig]

Re: The problem with ARM..

Definitely the car. There is a reason doctors call motorcyclists "donors".

Sorry, not sure how relevant that is to the analogy.

[Anonymous Coward]

Re: The problem with ARM..

Instructions per clock is a benchmark much preferred by those whose core architecture is outdated and inadequate but whose cash-rich company can afford to spend fortunes on fabrication process enhancements. Didn't Intel actually abandon an x86 derivative architecture with good IPC a few years back in favour of a successor with worse IPC but better headline MHz?

Rather more relevant benchmarks might include the cost of core chippery to provide a given performance on a given workload. Or the power (watts) required to provide a given performance on a given workload.

Basically, instructions per clock is almost totally artificial and largely irrelevant.

[Anonymous Coward]

" X86 which has a much larger software library"

All x86 has is Windows.

When there is no need for Windows compatibility, designers do not generally choose x86.

Don't take my word for it, open your eyes and look around you. Find me a few active examples where designers have chosen x86 in circumstances where there was no need for Windows compatibility.

[Bronek Kozicki]

Re: " X86 which has a much larger software library"

Example: all these Linux servers in the nearby server plant?

But in principle, I actually agree - these are x86 so that vendor *could* sell same hardware for many platforms, including Windows.

[Michael B.]

Re: " X86 which has a much larger software library"

Errr Supercomputers where it seems that over 3/4 of the top 500 are x86 based with over 90% of the top 500 use Linux.

From here: http://i.top500.org/stats

[Anonymous Coward]

Re: " X86 which has a much larger software library"

Quote: "Don't take my word for it, open your eyes and look around you. Find me a few active examples where designers have chosen x86 in circumstances where there was no need for Windows compatibility."

erm, Apple!

[Anonymous Coward]

Re: " X86 which has a much larger software library"

Well yes, in the boxes where it is conceivable that lack of Windows capability (Boot Camp? I forget?) would count significantly against them, Apple do use x86. Cross-architecture virtualisation isn't impossible but if you need it a lot it's sometimes inconvenient.

In boxes where Windows is utterly irrelevant (which, in numbers shipped terms, is most of them), what do Apple (and the rest of the market) use? Not x86.

[Bronek Kozicki]

nice, but not exciting

I'd like to see the kind of cache coherency which supports transactional memory. As much as I'd like to see it on low-power chips, only Intel seem to be going in this direction (for the time being).

[yossarianuk]

2012 - Secure boot ?

Will Windows server 2012 also have secure boot ?

Because if it does you will not be able to install another OS on the hardware, and you will not be able to disable the feature.... (its mandatory that you CANNOT disable secure boot on ARM based hardware)

Could be fun times ahead if that is the case.

[Anonymous Coward]

Re: 2012 - Secure boot ?

"ts mandatory that you CANNOT disable secure boot on ARM based hardware)"

That's not the case at all - it's mandatory if you want to use Windows on it .

I don't !

[yossarianuk]

Re: 2012 - Secure boot ?

In which case you will not be running Windows 2012 on 'certified hardware' anyone who does has just brought a brick.

[philbo]

Does this count as

an ARMs race?

[Anonymous Coward]

"all these Linux servers in the nearby server plant"

The servers built by manufacturers who think Windows compatibility matters (Dell, some bits of HP, whitebox vendors like Supermicro) are based on x86, and historically it has been convenient to use them for Linux too.

The servers built by manufacturers whose business is not Windows dependent because they use some other OS (a genuine UNIX, a mainframe OS, VMS, NSK, whatever) - how many of them choose x86? Look around. Show me the answer is bigger than zero.

Actually, Michael B. already did and pointed out the Top 500 Supercomputers list.

Thanks Michael.

Historically, and presumably still currently, the presence or absence of a particular product in the Top 500 is quite likely to reflect the availability of vendor funding as much as it reflects other criteria generally more relevant in the outside world. Work out what that means. Then tell readers why it matters anywhere outside the supercomputer market.