5 ms·

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 a

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.

pedrocr 12y ago
I assume these kinds of chips are ideal for naturally parallel workloads like web servers. I wonder what the mWh/request looks like between one of these and a normal x86 server.
bitL 12y ago
At SUN I was working with 256-thread SPARCs regularly and it was fairly simple to program using Java, except for some oddities in Solaris regarding networking stack. So if you need fast web servers, app servers or ETL, these chips can be pretty awesome. SPARC's threads were slower than ARM processors in mainstream phones nowadays, yet they were pretty good in handling web load. 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).
- 4ad 12y ago
  > Parallela's 64-core ARM 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.
  - bitL 12y ago
    Thanks for correcting me, you are right! It has 64 RISC cores alongside dual-core ARM.
  - jdboyd 12y ago
    To further clarify, the Parallella is a complete computer consisting of a 2 core ARM chip and a separate 16 or 64 core Epiphany processor.
Nursie 12y ago
Errr, some of us have been in the business of writing parallelised code for quite some time now. 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)
- TillE 12y ago
  I've written a fairly wide variety of multithreaded code in the past ten years or so, and I think the only real trouble I've had is with algorithms that work step by step, each step dependent on the previous results. That's effectively impossible to parallelize without fundamentally changing the algorithm. Otherwise, even if you have large chunks of shared memory, it's usually possible to work around that without locks.
mnw21cam 12y ago
> The biggest road bump for 48+ core SoC will be parallel programming. 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.
4ad 12y ago
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 12y ago
  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?)
  - windexh8er 12y ago
    They are not just designed for networking, but the bulk of their customers are: A10, F5, Sonicwall, Cisco, Juniper, Palo Alto Networks (http://www.cavium.com/winning_products.html http://www.cavium.com/winning_products.html) "...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.
    - kjs3 12y ago
      If you narrow the statement down to "the highest performance network gear don't use Xeons", I suppose you get to be right. Almost all of my data-center security and packet inspection devices have a Xeon or two in them. The Cisco ASAs, Fireeye APT probes, Imperva WAFs, F5 load balancers, Sourcefire IDS. A couple of them also have packet processing support hardware (Endace cards, mostly), but that's mostly for taking the packet processing off the Xeons and letting them do just the inspection. But hey, we're only doing a couple of gig sustained, so we aren't the cool kids.
rbanffy 12y ago
Niagara was too much ahead of its time. And a crypto accelerator would have been helpful (even if shared by a group of cores). I imagine memory bandwidth will become a problem as soon as we start designing our software to branch out enough threads to feed all the 48 mouths of this chip, but, still, this is how things will be in the future so it'd be wise to start designing for it right now.
- hapless 12y ago
  Niagara included a crypto accelerator. Its successor chips had fancier ones. https://blogs.oracle.com/ningsun/entry/cryptography_acceleration_on_ultrasparc_t2 https://blogs.oracle.com/ningsun/entry/cryptography_accelera...
  - rbanffy 12y ago
    Then I must imagine valarauca1's SSH key generation was not using it. I remember the first Niagara had a shared FPU and that was mentioned more than once as a pain point.
    - kjs3 12y ago
      This was also a flaw with AMD Bulldozer, no?

pedrocr 12y ago

I assume these kinds of chips are ideal for naturally parallel workloads like web servers. I wonder what the mWh/request looks like between one of these and a normal x86 server.

bitL 12y ago

At SUN I was working with 256-thread SPARCs regularly and it was fairly simple to program using Java, except for some oddities in Solaris regarding networking stack. So if you need fast web servers, app servers or ETL, these chips can be pretty awesome. SPARC's threads were slower than ARM processors in mainstream phones nowadays, yet they were pretty good in handling web load. 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).

4ad 12y ago
> Parallela's 64-core ARM 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.
- bitL 12y ago
  Thanks for correcting me, you are right! It has 64 RISC cores alongside dual-core ARM.
- jdboyd 12y ago
  To further clarify, the Parallella is a complete computer consisting of a 2 core ARM chip and a separate 16 or 64 core Epiphany processor.

Nursie 12y ago

Errr, some of us have been in the business of writing parallelised code for quite some time now. 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)

TillE 12y ago
I've written a fairly wide variety of multithreaded code in the past ten years or so, and I think the only real trouble I've had is with algorithms that work step by step, each step dependent on the previous results. That's effectively impossible to parallelize without fundamentally changing the algorithm. Otherwise, even if you have large chunks of shared memory, it's usually possible to work around that without locks.

mnw21cam 12y ago

> The biggest road bump for 48+ core SoC will be parallel programming. 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.

4ad 12y ago

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 12y ago
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?)
- windexh8er 12y ago
  They are not just designed for networking, but the bulk of their customers are: A10, F5, Sonicwall, Cisco, Juniper, Palo Alto Networks (http://www.cavium.com/winning_products.html http://www.cavium.com/winning_products.html) "...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.
  - kjs3 12y ago
    If you narrow the statement down to "the highest performance network gear don't use Xeons", I suppose you get to be right. Almost all of my data-center security and packet inspection devices have a Xeon or two in them. The Cisco ASAs, Fireeye APT probes, Imperva WAFs, F5 load balancers, Sourcefire IDS. A couple of them also have packet processing support hardware (Endace cards, mostly), but that's mostly for taking the packet processing off the Xeons and letting them do just the inspection. But hey, we're only doing a couple of gig sustained, so we aren't the cool kids.

rbanffy 12y ago

Niagara was too much ahead of its time. And a crypto accelerator would have been helpful (even if shared by a group of cores). I imagine memory bandwidth will become a problem as soon as we start designing our software to branch out enough threads to feed all the 48 mouths of this chip, but, still, this is how things will be in the future so it'd be wise to start designing for it right now.

hapless 12y ago
Niagara included a crypto accelerator. Its successor chips had fancier ones. https://blogs.oracle.com/ningsun/entry/cryptography_acceleration_on_ultrasparc_t2 https://blogs.oracle.com/ningsun/entry/cryptography_accelera...
- rbanffy 12y ago
  Then I must imagine valarauca1's SSH key generation was not using it. I remember the first Niagara had a shared FPU and that was mentioned more than once as a pain point.
  - kjs3 12y ago
    This was also a flaw with AMD Bulldozer, no?