4 ms·

Any word on what real general purpose computing capability those things have? 100 cores at 1.5Ghz is pretty useless as a performance indicator, especially given

by gcp 15y ago

Any word on what real general purpose computing capability those things have? 100 cores at 1.5Ghz is pretty useless as a performance indicator, especially given that it's not a known micro-architecture. I inquired at Tilera a while ago about this and I got zero response back. Not exactly a good sign.

yvdriess 15y ago
How would you compare its performance? It would do really bad on the SPEC benchmarks for example. Some parallel algorithms would do well on Tilera. If not in absolute speed, at least in FLOPS/Watt
- gcp 15y ago
  It would do really bad on the SPEC benchmarks for example. That's what I'd expect. But "bad" * 100 might still be good. Or more realistically, "bad" * scaling * 100 might be acceptable. But without data, it's anybodies guess.
  - yvdriess 15y ago
    I meant bad for the entire Tilera processor. I haven't found any SPEC results for a Tilera processor, but we've been experimenting with a TilePro64 in out research lab for a while: http://soft.vub.ac.be/~smarr/2010/11/roarvm-the-manycore-squeakvm/ http://soft.vub.ac.be/~smarr/2010/11/roarvm-the-manycore-squ...
dkersten 15y ago
I also inquired at Tilera and they were very quick to respond and very helpful, answering questions over email and over the phone (I had multiple phone conversations with one of the guys on this page: http://www.tilera.com/about_tilera/management http://www.tilera.com/about_tilera/management I won't say who though). It may have helped that I was inquiring on behalf of the telecoms company I worked for at the time. I was inquiring about their 64 core PCIe cards (this was a few years ago, before they had 100 core ones). From what I understood, they run (or at least, can run) Linux and most things will run just fine with a recompile (though obviously not making the best use of the available cores). They also said that their team would help port our software (which was a mixture of highly multi-threaded Java and C++) as part of the development kit cost. I think the devkit cost ten to twenty K US$ (I don't remember the exact number) and the individual cards cost between about 2K and 10K depending on the specs and quantity ordered. Unfortunately, I don't really remember the technical details any more. I do remember that they would have been a great fit for what we were doing (processing SMS messages, each one can be easily processed in parallel with only a small bit of shared state), but my boss pulled the plug because we managed to reach our performance goals with commodity hardware while I was still talking to Tilera.
- justincormack 15y ago
  They seem to be betting big on cache coherency and shared memory , compared to say Calxeda with clusters of CPUs with message passing. Not sure how much of the market needs this, eg your example application above does not.
  - dkersten 15y ago
    Indeed, my application did not require cache coherency or shared memory. In fact, what we ended up doing was basically a message passing system between the commodity machines in the cluster, so each node processed messages independently. Each node maintained its own shared (between messages processed on that node, but not between nodes) state and if a message which needed this state was on a different node, it was transferred to the correct node (using a distributed hash table to know which node to transfer to). Since we could tell very early during the messages processing if it requires access to the shared state or not (we knew more or less by message type), this was very efficient. There was a little more to it for redundancy and fault tolerance, but that's the basic strategy we followed and it does not require shared memory or cache coherency at all, like you correctly identified, which is why we didn't need Tilera and were able to meet our goals on a commodity hardware cluster. When I said my application was a good fit, I really meant that it was embarrassingly parallel enough to make good use of a lot of cores - not that it required or benefited from anything else that the Tilera hardware would have given us.

by gcp 15y ago

yvdriess 15y ago

How would you compare its performance? It would do really bad on the SPEC benchmarks for example. Some parallel algorithms would do well on Tilera. If not in absolute speed, at least in FLOPS/Watt

gcp 15y ago
It would do really bad on the SPEC benchmarks for example. That's what I'd expect. But "bad" * 100 might still be good. Or more realistically, "bad" * scaling * 100 might be acceptable. But without data, it's anybodies guess.
- yvdriess 15y ago
  I meant bad for the entire Tilera processor. I haven't found any SPEC results for a Tilera processor, but we've been experimenting with a TilePro64 in out research lab for a while: http://soft.vub.ac.be/~smarr/2010/11/roarvm-the-manycore-squeakvm/ http://soft.vub.ac.be/~smarr/2010/11/roarvm-the-manycore-squ...

dkersten 15y ago

I also inquired at Tilera and they were very quick to respond and very helpful, answering questions over email and over the phone (I had multiple phone conversations with one of the guys on this page: http://www.tilera.com/about_tilera/management http://www.tilera.com/about_tilera/management I won't say who though). It may have helped that I was inquiring on behalf of the telecoms company I worked for at the time. I was inquiring about their 64 core PCIe cards (this was a few years ago, before they had 100 core ones). From what I understood, they run (or at least, can run) Linux and most things will run just fine with a recompile (though obviously not making the best use of the available cores). They also said that their team would help port our software (which was a mixture of highly multi-threaded Java and C++) as part of the development kit cost. I think the devkit cost ten to twenty K US$ (I don't remember the exact number) and the individual cards cost between about 2K and 10K depending on the specs and quantity ordered. Unfortunately, I don't really remember the technical details any more. I do remember that they would have been a great fit for what we were doing (processing SMS messages, each one can be easily processed in parallel with only a small bit of shared state), but my boss pulled the plug because we managed to reach our performance goals with commodity hardware while I was still talking to Tilera.

justincormack 15y ago
They seem to be betting big on cache coherency and shared memory , compared to say Calxeda with clusters of CPUs with message passing. Not sure how much of the market needs this, eg your example application above does not.
- dkersten 15y ago
  Indeed, my application did not require cache coherency or shared memory. In fact, what we ended up doing was basically a message passing system between the commodity machines in the cluster, so each node processed messages independently. Each node maintained its own shared (between messages processed on that node, but not between nodes) state and if a message which needed this state was on a different node, it was transferred to the correct node (using a distributed hash table to know which node to transfer to). Since we could tell very early during the messages processing if it requires access to the shared state or not (we knew more or less by message type), this was very efficient. There was a little more to it for redundancy and fault tolerance, but that's the basic strategy we followed and it does not require shared memory or cache coherency at all, like you correctly identified, which is why we didn't need Tilera and were able to meet our goals on a commodity hardware cluster. When I said my application was a good fit, I really meant that it was embarrassingly parallel enough to make good use of a lot of cores - not that it required or benefited from anything else that the Tilera hardware would have given us.