Final Words

When it comes to processors, enthusiasts and laymen alike can identify the three largest players: Intel, AMD and ARM. Those names are also not mutually exclusive: AMD utilizes ARM designs for consumer security coprocessors and in its Opteron A1100 server processor. There are other processors out there (e.g. IBM's POWER CPUs), but they're generally not as well known. That's also the case with MIPS.

Not everyone knows the name MIPS, but Imagination hopes to change that by offering a viable alternative to the embedded market dominated by ARM. MIPS already has a large presence in networking and embedded devices. Introducing the I6400 keeps MIPS relevant and places additional pressure on ARM. According to the provided numbers (admittedly from MIPS) and feature descriptions, the I6400 appears to compete with and even surpass the highly anticipated ARM Cortex-A53. Imagination projects general availability of the I6400 to SoC designers by December 2014. We can estimate end-user availability at least 6 to 9 months after that.

Consumers will most likely directly experience the MIPS I6400 CPU in low cost Android tablets and handsets. Due to Android's Java heritage, some applications will work out-of-the-box. Other applications using the Android Native Development Kit (NDK) targeting Intel or ARM ISAs will unfortunately be incompatible. Until MIPS achieves enough volume to convince application developers to code to the MIPS3264 ISA or stick with Java, MIPS Android devices will be second class citizens. This is something to keep in mind if you're purchasing a phone for yourself or a tech savvy friend. Of course, basic operating system features like email, phone, text, web browsing, and chatting should all work fine.

Intel has enjoyed dominance of its performance leading processors in non-handset settings for the better part of a decade. ARMs embedded low power heritage has emerged as Intel’s biggest threat as mobile devices have exploded and now dominate the computing landscape. As Intel and ARM continue to battle for the high end embedded market, Imagination and MIPS hope to erode away ARM’s mid-range and low-end core competency. As a consumer, we can lean back and enjoy the competition that will force each company to work harder each and every year.

The I6400’s revised MIPS3264 Release 6 ISA, instruction bonding, and SMT execution pipeline bring a refreshing set of new innovations to the small-core market. In our A53 coverage we noted ARM was pushing in-order CPU performance about as far as it could possibly go. I’m always happy to see we might have been wrong.

The MIPS I6400 CPU
POST A COMMENT

84 Comments

View All Comments

  • Flunk - Tuesday, September 02, 2014 - link

    Competition is always good, it will be interesting to see how these perform in real devices. The performance/power consumption offered by modern ARM processors is difficult to compete with. Reply
  • alexvoica - Tuesday, September 02, 2014 - link

    I6400 offers better performance at lower power and reduced area vs. the competition. I have included some benchmarks in my article http://blog.imgtec.com/mips-processors/meet-mips-i... Reply
  • name99 - Tuesday, September 02, 2014 - link

    I'm sorry but that article appears to be marketing crap.

    You state "Preliminary results for I6400 show that adding a second thread leads to performance increases of 40-50% on SPECint or CoreMark". So adding a second thread speeds up the SINGLE-THREADED version of SPEC? That's a neat trick.

    Likewise you happily claim that multi-threading make a "big difference" to web browsing, something that will come as news to the many engineers on the WebKit, Blink and IE teams who have sweated blood over this without much to show for their efforts.

    On your blog you can post whatever marketing fluff you like, but how about on AnandTech you limit yourself to actual numbers of real benchmarks?

    (Sorry to be cruel but, christ, throwing raw ads into the comment stream and pretending they're informed comment pisses me off no end.)
    Reply
  • alexvoica - Tuesday, September 02, 2014 - link

    I might not be as versed as you are and excused me if I'm wrong (someone correct me if I am) but, as far as I know, SPEC supports multi-threading. Multi-threading really does improve performance - but don't take it from me, take it from our customers who are already using it in both 32- and 64-bit MIPS-based designs: Broadcom, Cavium, Lantiq - I could go on.

    I don't really understand how you can claim that my article is marketing fluff. It is marketing, yes. But doesn't every company have an official release? And doesn't part of that release include competitive positioning?

    Let's not be behind-the-screen aggressive for behind-the-screen aggressiveness's sake. We have already offered a lot more information than our competitors, including benchmark data in CoreMark, DMIPS and SPECint.
    Reply
  • name99 - Tuesday, September 02, 2014 - link

    "We have already offered a lot more information than our competitors, including benchmark data in CoreMark, DMIPS and SPECint."
    Then why is the post full of claims, and basically numberless graphs, but not actual tables of numbers? Ooh, we're 1.3x faster than "competing CPU" --- that's helpful.
    There's more information available in any AnandTech phone review.

    Say what you like about nVidia, at least their HotChips Denver marketing slide gave numbers of a sort for Denver, compared to Baytrail, Krait-400, iPhone 5S and Haswell, all for a range of benchmarks (DMIPS, SPECInt2K and SPECFP2K, AnTuTu, Geekbench, Google Octane and some memory benchmarks). I think they were wrong to omit (definitely) SunSpider and (I care less) Kraken because SunSpider in particular gives a good feel for single-threaded performance on a large real-world code base. (SPECInt2K is a reasonable proxy, but stresses the uncore more than is probably usual for mobile devices.) Octane (and Kraken) are less interesting IMHO because they synthesize a workload that is vastly more parallelized than most actual websites.

    (Of course I'd expect you to do better than nVidia, especially since you're the new kid on the block.
    That means, for example, real numbers not scaled percentages;
    it means running the benchmarks honestly --- using the optimal compiler plus flags for each device;
    it means telling the public what those flags were so they can reproduce if necessary;
    it means not playing games with cooling systems that aren't going to be used on a real device, or an OS power driver that does not match what will ship in real devices;
    and it means using appropriate best of breed devices --- eg it's a bit slimy to use an iPhone 5S [1.3GHz] rather than iPad Air [1.4GHz] unless you have some damn good reason (like you're comparing against the phone version of your chip, not the tablet version.)

    The code to be compiled to perform the SPECInt bechmark runs is not threaded. Sure, if your compiler is smart enough to auto-parallelize that code, it can go right ahead. Since no-one else's compiler has managed to achieve much by doing that, I kinda doubt MIPS has made a breakthrough here...

    Multi-threading improves performance IF YOUR CODEBASE IS THREADED. My point is that the market that's being implied here (phones, tablets) is NOT substantially threaded.
    There absolutely are markets (in many of which MIPS already does well, things like networking or cellular) where threading is important and of benefit. That doesn't change the fact that phones and tablets are not such a market, and pretending otherwise is not helpful to anyone.
    Reply
  • alexvoica - Tuesday, September 02, 2014 - link

    This is where you are wrong, no matter how much your finger gets stuck on caps lock. Programming for multithreading is not radically different than programming for multicore. In fact, Linux-SMP operating systems (e.g. Android) will see a dual-threaded CPU as two physical cores.

    Regarding your comments about benchmarks, I invite you to show me real, concrete numbers from our CPU IP competitor. We have said 5.6 CoreMark and 3.0 DMIPS per MHz. Now show me the data - and I am not interested in semiconductor manufacturers who are not our competitors but IP vendors.

    The comparisons were made based on similar core configurations to ensure accuracy; how would you be able to reproduce them - are you an ARM licensee?
    Reply
  • Wilco1 - Tuesday, September 02, 2014 - link

    You've showed some numbers but not explained how they were made. As I said in my other post, MIPS uses a trick to get its CoreMark score, so any competitor result without the same trick will obviously look bad.

    And this is the issue with benchmarketing, unless it is possible to reproduce the score yourself, it is hard to believe any vendor-supplied scores.
    Reply
  • name99 - Tuesday, September 02, 2014 - link

    (a) Thanks for explaining SMT to stupid old me who's been in a coma for the past fifteen years and has never heard of the concept. Not sure WTF it has to do with my actual point about the dearth of threaded APPLICATIONS...

    (b) I'm not the guy trying to sell a CPU to the rest of the world, so I'm not sure why it's my job to provide numbers, but OK, here we go.

    iPhone 5S at 1.3GHz gets a geekbench-singlecore rating of about 1300, and a sunspider rating (with iOS7) of 416. What do you have as closest equivalent numbers?
    DMIPS --- give me a break. No-one cares about that because it tells you precisely nothing about anything hard that the CPU does. Coremark's slightly more interesting, but why don't you give some comparable CoreMark/MHz values so we can see what you consider to be your competitors.
    I see, for example, that Exynos quad A9 claims a value of 15.89 and a dual-core A15 claims 9.36. Would you consider those competitors?
    (As comparison, a single core A53 (at least the QC Snapdragon 410 variant) gets 3.7 according to AnandTech --- but 3.0 according to other sources so??? A57 is supposed to get 3.9, but who knows how trustworthy that number is.)

    Assuming your 5.6 number is for multi-threaded operation, I'm going to do the naive thing and say that that tells me the single-threaded value is 2.8, which is apparently worse than an A53. If you don't like that arithmetic, then give us the single-threaded benchmark numbers, rather than trying to persuade us that phones are a great example of user-level multi-threaded software.
    Reply
  • alexvoica - Wednesday, September 03, 2014 - link

    Please understand that CoreMark does not work like that for multi-threading vs multicore.

    If you look at their website https://www.eembc.org/coremark/

    PThreads refer to performance for both cores and/or threads - they do not specifically say which is which.

    ARM scores are for multicore versions - this is why the CoreMark per MHz per core number is obtained by dividing that number by the number of PThreads. For example, for one Cortex-A15 you have 9.36 / 2 = 4.68 CoreMark/MHz. A single core proAptiv - which is a single-threaded design too - offers 5.1 CoreMark/MHz.

    The number we've quoted for I6400 is 5.6 CoreMark/MHz. For multithreading however, you do not divide by number of threads since these are not individual CPUs but threads part of a single core. The score for a single core, single threaded I6400 is not half of 5.6. We specify very clearly in the press release/blog article that adding another thread improves performance by 40-50%, so your numbers are incorrect.

    I still don't understand why you are pushing your agenda so aggressively and jump to conclusions since the data is clear. The author of the article chose to quote DMIPS, but I believe we have presented a valid combination of benchmarks and scenarios. Again, we are not competing with silicon manufacturers - some of them are licensees - but with other IP vendors.
    Reply
  • Wilco1 - Wednesday, September 03, 2014 - link

    I don't agree Dhrystone and CoreMark are valid benchmarks for CPU comparisons - both are easily cheated. You claim some great results but you know very well these are not indicative of actual CPU performance. Both benchmarks use special compiler tricks (like I mentioned in other posts) that only speedup these benchmarks, but nothing else. I bet SPEC scores are not nearly as good.

    Once again eg. NVidia actually posted real scores for lots of benchmarks of their SoCs, including SPEC. Do the same rather than playing these benchmarketing games and you'll gain a lot more credibility.
    Reply

Log in

Don't have an account? Sign up now