
48 Core ARM-64 processors from Cavium to challenge Xeons? - jhowe
http://www.eetimes.com/document.asp?doc_id=1322565
======
joosters
When you have tens of CPU cores, you really do start to run up against
Amdahl's Law and soon don't get the speedup that you might expect.

e.g. let's say 90% of your task can be perfectly parallelised. The remaining
10% of the time will not be improved. So you won't ever get more than a 10x
speedup no matter how many tens or hundreds of extra CPU cores you have...

~~~
xienze
Well, you're thinking in terms of parallelising a single task. For a server,
you're talking about a large number of concurrent tasks (users), so more cores
are better in that case.

~~~
joosters
That's basically a truism. If you have parallelisable tasks, then they will
parallelise. No surprise there.

I was trying to make the point that as we step up the number of cores, the
actual gain is less and less.

~~~
higherpurpose
You're missing the point. I think everyone knows what you're saying is true
for a mobile phone or even a desktop PC. Where it's NOT true is on servers,
where tasks _are_ "parallelized" since you have _millions_ of concurrent
users, so whether you have 1 million 8-core servers, or 125,000 64-core
servers it doesn't matter much, because it's pretty much the same thing.

But from a whole datacenter perspective, I believe having servers with more
cores is more efficient than having more servers with fewer cores, since data
travels faster between more of the cores.

~~~
jallmann
This whole thread is talking past each other.

Servers absolutely can have sequential dependencies, especially if there is a
shared resource (eg, databases, IO, etc). If your application can make full
use of all your cores without any inter-dependencies, great -- but that is not
always the case.

------
valarauca1
The biggest road bump for 48+ core SoC will be parallel programming. Because
in truth nobody is (or at least doesn't want too). If you happened to be an
early adopter of the SPARC T5 Niagra you likely noticed most of your utils ran
very slowly.

I just remember generating SSL keys at a speed that my pentium would laugh at,
because SSL didn't supporting threading itself out to all 512 cores.

~~~
4ad
These chips are designed for networking equipment, not general purpose code. I
don't understand how come the article fails to make this explicitly clear.

Networking code has no problem with this high core count mostly because it was
already written to work on already high-core count MIPS systems. For example,
the previous MIPS64 offerings from Cavium pack 48 cores on a chip...

~~~
jsnell
Why do you claim that these chips are designed for networking? The article
isn't just omitting the target market like you imply, but is very clear about
Cavium targeting servers rather than just networking appliances.

(I'm a lot pessimistic than most of the people in this thread. Network
processors haven't really made a lot of sense compared to Xeons even for
networking applications for a few years. Why would they do any better in the
general purpose market?)

~~~
4ad
> Why do you claim that these chips are designed for networking?

Because this is Cavium's niche and biggest asset, and all their customers are
doing networking. Of course they might want to expand their business, but they
have always done that, really, and they only had success in networking. The
special features of this chip (things that are Cavium-specific and not ARM64
specific) are features that make a lot of sense for networking equipment, and
are not very important for general purpose servers. These special features are
also present in their existing MIPS64 line.

> Network processors haven't really made a lot of sense compared to Xeons even
> for networking applications for a few years.

Really? Where's that 100GbE Xeon switch?

~~~
jsnell
> Because this is Cavium's niche and biggest asset, and all their customers
> are doing networking.

That's their current niche. They're trying to get out of that niche, as the
article clearly shows. (Let's be clear here -- the article might be a PR fluff
piece, but it hasn't been written in an ignorance of the position of Cavium in
networking). If they try to market this stuff for general purpose servers,
they need to have an answer to the problem of parallelizing general purpose
workloads. I don't see why this is such an offensive thing to point out.

I work at a company making networking equipment (mainly for telecoms),
targeting the 20Gbps range at the top end, with Xeons. We could scale much
higher for trivial workloads like switching, but the bottleneck is in actual
processing where the wimpy MIPS cores aren't particularly tempting. The
offerings of companies like Cavium have really not looked compelling compared
to standard Xeons during the last 4 years or so.

Maybe if we'd started before that, we'd have started with a network processor
and would naturally stick to it. But many of the more established telecom
suppliers we've interacted with are likewise doing significant amounts of
stuff with Xeons (standard hardware, or ATCA blades at the most exotic end).
The only Cavium card I remember anyone using was doing 10Gbps of traffic that
was so trivial, that even the low-spec 1U Xeon server the card was installed
in could have handled it with the proper userspace NIC drivers.

------
rektide
Cavium announced a 48 x 64-bit chip running 2.5GHz almost two and a half years
ago: the Octeon III.

[http://www.cavium.com/newsevents_Cavium_Unveils_48-core_OCTE...](http://www.cavium.com/newsevents_Cavium_Unveils_48-core_OCTEON-
III_MIPS64_Processor.html)

------
windexh8er
Having been looking for some ARMHF images for Ubuntu I stubled across this.
Looks like Ubuntu is all over this (as well as RHEL including Fedora, and
Monta Vista:

[http://www.ubuntu.com/download/server/arm](http://www.ubuntu.com/download/server/arm)

Links to "Project Thunder SDK":

[http://www.cavium.com/thundersdk_access_application.html](http://www.cavium.com/thundersdk_access_application.html)

------
hapless
The chip is vaporware. They've been talking about it for two years, but to
quote the article, "Cavium has yet to share performance figures for the chip,
which is not yet in first silicon."

I will be very excited to see some hard numbers when (if) this thing is ever
released.

------
personZ
Worth noting that Intel already has a many weaker core design -- the Xeon Phi.
While it exists as an add-in "co-processor" right now, in 2015 it will become
a stand-alone platform via Knights Landing.

~~~
bitL
Xeon Phi seems to be targeting two markets at once - many-core (x64) server
computing and GPGPU with their 512-bit SIMD. For general server the memory
limitation to 8GB is too low, which is however very competitive in GPGPU
market.

~~~
personZ
Their new models are 16GB, but you are exactly right that the model is very
similar to the GPGPU (less memory, but what it does have is incredibly fast),
albeit fewer but higher performance cores than something like a Tesla.

Knights Landing is when the model becomes a server unto itself, with 384GB of
addressable memory, albeit still maintaining the ultra-fast 16GB of local
memory per CPU.

~~~
bitL
Exciting times ahead ;-)

Also, there is a difference in required memory architecture when it comes to
optimizing CPU thread performance vs SIMD - CPU is more sensitive to latency,
SIMD to bandwidth. You usually have to pick the memory type (e.g. DDR3 vs
GDDR5) that optimizes one of those and that would tell you what market you
target.

I am not sure how AMD handles their HSA - they seem to have discontinued plans
for GDDR5 so their Fusion GPU is going to be bandwidth-starved.

------
kjs3
Wonder why Cavium jumped from MIPS to ARM for this? At least, all the Cavium
kit I have is MIPS based.

