Ampere smacks the ball over the net, back at Marvell: Our Altra Max cloud processor will have 128 Arm cores

Ampere said today it hopes to bring a 128-core data-center-grade microprocessor to the market next year. The 128-core 64-bit Armv8-compatible Altra Max is, we're told, a continuation of the Altra, which was announced in March and sports 80 Arm-designed Neoverse N1 cores. Both microchips are, or will be, fabricated by TSMC …

[Pete 2]

Toasty!

> a maximum TDP of 250W

Those of us who remember 1990's science fiction series will be aware of the Video Toaster.

With each of these chips generating up to 250 Watts of heat, there could be a resurgent secondary function. Just imagine: camping out in the datacentre late at night, sitting in a circle around the server. Recounting tall tales while chomping on warm marshmallows fresh off the heatsink!

[Oh Matron!]

Apple Arm....

8 core i7 in my Mac uses 45w. A 10 core version of the above chip uses 31w (if there's linearity with watts per core)

You can see why Apple made the change. And when there's talk of 5nm.... Intel are nowhere near

Bootnote: Yes, I'm completely aware of chalk / cheese / lumps of coal and elephants are not the same thing, but....

[Anonymous Coward]

Re: Apple Arm....

"You can see why Apple made the change. And when there's talk of 5nm.... Intel are nowhere near"

I'm not sure I agree with your line of reasoning.

Apple made the choice to move to ARM because of cost - they had the scale of demand from their own devices and saw it as a potential competative advantage in the mobile space which is where the majority of their market is and it likely has an impact on development costs if x86 disappears in the future.

For performance, it is a case of Apple hoping they can keep pace with performance on the desktop side. ARM performance is sufficient at the moment but it will depend how quickly desktop workloads shift to multiple cores as there is still some way to go there. For single thread performance, ARM still has to embrace the designs and processes (they use the low density, low power process nodes) necessary to sustain high instruction counts at >3GHz frequencies so there is likely to be a gap on the performance side. And while I've seen benchmarks that show ARM is capable, they have to be taken with a grain of salt - good results in SPECxx only matters if that matches your workload.

[alain williams]

Quoting speed in GHz ...

does not really allow a good comparison. Especially when different machine architectures are being compared.

SPEC was used a while back - is that still good ?

[Tom 7]

Re: Quoting speed in GHz ...

I think one of the problems is nowadays a single figure is pretty useless. You really have to be able to define your uses before you can even think which tests you might be interested in getting figures for.

[DS999]

Re: Quoting speed in GHz ...

SPECrate 2017 is about as good as you'll do for cloud computing benchmarks. Obviously if you can benchmark using your actual load that's the best, but unless you are doing something pretty weird (or doing a lot of I/O, which SPEC deliberately doesn't try to measure) it will match up pretty well with the SPECrate results.

[Anonymous Coward]

Re: Quoting speed in GHz ...

"SPEC was used a while back - is that still good ?"

If you are just looking at integer/FP math then maybe - but remember high instruction counts per clock are easier when your clock frequencies are low. As is power usage.

If you need performance, maintaining those high instruction rates becomes harder with caching to alleviate IO bottlenecks or "lumpiness" to keep a CPU fed becoming more critical.

The benchmarks I have seen for ARM where Intel is clocked down favour ARM. When comparisions are made that take advantage of each architectures advantages (i.e. measuring work and time required to execute a given quantity of work), x86 is faster and the power usage becomes similar as the x86 is either working at maximum efficiency or idle.

Horses for courses.

[Anonymous Coward]

Portability?

Is there any real portability across these various ARM based systems? Or are you rebuilding at a minimum, re-architecting at worst for these different system designs (even if the instruction set is compatible)? I know that some of the HPC stuff we work with is *very* iffy about extremely high thread counts, because nobody knows what bottlenecks might lurk in those unexplored regions.