5 ms·

Tilera Taunts Intel With a 100-Core Chip

18 points by jaydub 17y ago

joss82 17y ago
This article is not informative (or technical) enough, IMHO. It lacks : - The instruction set used is a MIPS-derived VLIW instruction set according to http://en.wikipedia.org/wiki/TILE64 http://en.wikipedia.org/wiki/TILE64 - It needs to say that 99% of developers don't really care about instruction set as they use higher-level languages. EDIT: A new cpu architecture is always an exciting sight, though.
- rbanffy 17y ago
  "EDIT: A new cpu architecture is always an exciting sight, though." Don't tell me. I would _love_ to have a workstation based on one of these. While the hypervisor is a very interesting element, I would be delighted to see a kernel taking advantage of the bare-metal partitioning scheme for managing core-affinity on processes sharing a single memory space. It's fun to imagine a thread-migration mechanism based on memory-access-hop-counting for dynamic optimization of process/thread/tile allocation.
codedivine 17y ago
Interesting architecture but the amount of information available publically is limited? For example, I was trying to find out if it will be suitable for parallel floating point workloads but I don't see any mention of floating point performance on the company webpage. Would also be nice to see some benchmark numbers done by a 3rd party. Never believe what the vendors say about their own products.
- oconnor0 17y ago
  The Register's article on this chip (http://www.theregister.co.uk/2009/10/26/tilera_third_gen_mesh_chips/print.html http://www.theregister.co.uk/2009/10/26/tilera_third_gen_mes...) makes it sound like there is no FP support.
- wmf 17y ago
  SemiAccurate says 50 GFLOPS per chip; that's pretty weak at only 500 MFLOPS per core. Sandy Bridge will probably beat it for floating point. I saw a presentation somewhere of Erlang scaling up to 64 cores on Tilera, but besides that it's very short on benchmarks.
  - codedivine 17y ago
    Given the comment below linking to the register article mentioning no floating point units on chip, maybe they are emulating FP in software giving the lowly number.
yread 17y ago
There is much more technical information on charlie's page http://www.semiaccurate.com/2009/10/29/look-100-core-tilera-gx http://www.semiaccurate.com/2009/10/29/look-100-core-tilera-... Although generally the posts there are just rants this one is quite good
protomyth 17y ago
This chip looks cool, but "FP code is still frowned upon" is a shame. I would actually be more interested in a 100 core chip, if its cores were tuned to accelerate OpenCL.
- wmf 17y ago
  There are already three companies building OpenCL GPGPUs.
  - protomyth 17y ago
    With 100 cores?
    - sketerpot 17y ago
      More, usually. Since they aren't as general-purpose as CPUs, they can be pretty small.
    - azim 17y ago
      I believe Nvidia's Fermi will enter the market this year with 512 cores.
    - wmf 17y ago
      Cores don't matter; performance matters.
DarkShikari 17y ago
Here's a (somewhat overly cynical) marketing->reality translation I performed on their whitepapers for one of my bosses. Obviously, given that I only looked at the whitepaper, some of my interpretation might be slightly inaccurate, but I think it's close enough. (He was interested in running x264 on it.) The TilePRO64 Processor is programmed in ANSI standard C You'll need to use our custom proprietary (and bad) compiler, and we probably won't give you an assembler. 32-bit VLIW processors You'll have to spend thousands of man-hours rewriting all of your assembly code. H.264 HD encode for 10 streams of 1080p (baseline profile) Even when we make every last possible marketing cheat that we can possibly make with custom CPU-specific code, we can only get 10 streams going realtime, barely more than what one can do on a standard dual-Nehalem system with x264 (with similarly marketing-cheat level settings). 700mhz, 866mhz operating frequency Unless every part of your application is embarassingly parallel (read: not x264), there's no way you'll get it to run at any reasonable speed on this thing. iLib APIs for efficient inter-tile communication You'll have to rewrite your code yet again to use a new library. 5.6 Mbytes of on-chip cache Our CPU has an embarassingly small amount of cache per-core, which is why we can get so many onto the die at such lower power usage. Your program will be overwhelmed by cache misses. 19-23W @ 700mhz for typical applications We're selling a big fancy DSP, not a real general-purpose processor. If you want to get good performance out of it, you'll probably have to rewrite a lot of code.
- listic 17y ago
  So, do you think their take on manycore architecture is doomed?

18 points by jaydub 17y ago

This article is not informative (or technical) enough, IMHO. It lacks : - The instruction set used is a MIPS-derived VLIW instruction set according to http://en.wikipedia.org/wiki/TILE64 http://en.wikipedia.org/wiki/TILE64 - It needs to say that 99% of developers don't really care about instruction set as they use higher-level languages. EDIT: A new cpu architecture is always an exciting sight, though.

rbanffy 17y ago
"EDIT: A new cpu architecture is always an exciting sight, though." Don't tell me. I would _love_ to have a workstation based on one of these. While the hypervisor is a very interesting element, I would be delighted to see a kernel taking advantage of the bare-metal partitioning scheme for managing core-affinity on processes sharing a single memory space. It's fun to imagine a thread-migration mechanism based on memory-access-hop-counting for dynamic optimization of process/thread/tile allocation.

codedivine 17y ago

Interesting architecture but the amount of information available publically is limited? For example, I was trying to find out if it will be suitable for parallel floating point workloads but I don't see any mention of floating point performance on the company webpage. Would also be nice to see some benchmark numbers done by a 3rd party. Never believe what the vendors say about their own products.

oconnor0 17y ago
The Register's article on this chip (http://www.theregister.co.uk/2009/10/26/tilera_third_gen_mesh_chips/print.html http://www.theregister.co.uk/2009/10/26/tilera_third_gen_mes...) makes it sound like there is no FP support.
wmf 17y ago
SemiAccurate says 50 GFLOPS per chip; that's pretty weak at only 500 MFLOPS per core. Sandy Bridge will probably beat it for floating point. I saw a presentation somewhere of Erlang scaling up to 64 cores on Tilera, but besides that it's very short on benchmarks.
- codedivine 17y ago
  Given the comment below linking to the register article mentioning no floating point units on chip, maybe they are emulating FP in software giving the lowly number.

yread 17y ago

There is much more technical information on charlie's page http://www.semiaccurate.com/2009/10/29/look-100-core-tilera-gx http://www.semiaccurate.com/2009/10/29/look-100-core-tilera-... Although generally the posts there are just rants this one is quite good

protomyth 17y ago

This chip looks cool, but "FP code is still frowned upon" is a shame. I would actually be more interested in a 100 core chip, if its cores were tuned to accelerate OpenCL.

wmf 17y ago
There are already three companies building OpenCL GPGPUs.
- protomyth 17y ago
  With 100 cores?
  - sketerpot 17y ago
    More, usually. Since they aren't as general-purpose as CPUs, they can be pretty small.
  - azim 17y ago
    I believe Nvidia's Fermi will enter the market this year with 512 cores.
  - wmf 17y ago
    Cores don't matter; performance matters.

DarkShikari 17y ago

Here's a (somewhat overly cynical) marketing->reality translation I performed on their whitepapers for one of my bosses. Obviously, given that I only looked at the whitepaper, some of my interpretation might be slightly inaccurate, but I think it's close enough. (He was interested in running x264 on it.) The TilePRO64 Processor is programmed in ANSI standard C You'll need to use our custom proprietary (and bad) compiler, and we probably won't give you an assembler. 32-bit VLIW processors You'll have to spend thousands of man-hours rewriting all of your assembly code. H.264 HD encode for 10 streams of 1080p (baseline profile) Even when we make every last possible marketing cheat that we can possibly make with custom CPU-specific code, we can only get 10 streams going realtime, barely more than what one can do on a standard dual-Nehalem system with x264 (with similarly marketing-cheat level settings). 700mhz, 866mhz operating frequency Unless every part of your application is embarassingly parallel (read: not x264), there's no way you'll get it to run at any reasonable speed on this thing. iLib APIs for efficient inter-tile communication You'll have to rewrite your code yet again to use a new library. 5.6 Mbytes of on-chip cache Our CPU has an embarassingly small amount of cache per-core, which is why we can get so many onto the die at such lower power usage. Your program will be overwhelmed by cache misses. 19-23W @ 700mhz for typical applications We're selling a big fancy DSP, not a real general-purpose processor. If you want to get good performance out of it, you'll probably have to rewrite a lot of code.

listic 17y ago
So, do you think their take on manycore architecture is doomed?