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.
I would buy these chips in an instant, similarly to Parallela's 64-core ARM.
The competition would be Xeon Phi - I assume that is much more expensive and the memory is too limited (8GB).
Parallela is not a 64-core ARM, it's a 2-core ARM with a bunch of co-processors which have to be programmed specially. The co-processors have little local memory and the memory model is very weak, there are no memory barriers precluding the use of general-purpose code.
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...
(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?)
"...haven't really made a lot of sense..." - You are completely wrong here. Most data center grade networking equipment does not run Xeon and the products that do are generally significantly less performant. Especially when it comes to security or packet inspection.
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?
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.
So no, these are not just designed for networking equipment, they are planned to target 4 different areas.
https://blogs.oracle.com/ningsun/entry/cryptography_accelera...
A lot of enterprise* server stuff is written to take advantage of multiple cores/hardware threads and has been for a while.
(*yeah, I hate that word)
Otherwise, even if you have large chunks of shared memory, it's usually possible to work around that without locks.
And if you're okay with parallel programming (which, let's face it, is the only way to do high performance computing), then you'll possibly be hit by memory bandwidth or cache size. Because if you have 48 cores on a single lump of silicon, they won't have very large dedicated caches each. However, if you have an appropriate job that will scale out to all the cores with a small working set then the performance of this thing could be rather interesting.