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

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.