MIPS Strikes Back: 64-bit Warrior I6400 Arrives | Hacker News Reader

MIPS Strikes Back: 64-bit Warrior I6400 Arrives

anandtech.com

70 pointsamardeep44 comments

Will Imagination actually publish specs so that Linux is able to implement anything without reverse engineering? The history of binary blobs on PowerVR is not encouraging.

I don't imagine* things would ever be as bad as "linux not being able to run", but Imagination are indeed going to have to seriously rethink their hacker-friendliness if they want to get anywhere in this market.

* pun acknowledged

The kernel has a lot of MIPS generic stuff, but of course, they may be slow to integrate somethings in the main kernel or not bother at all

This might eventually bite them back. Especially in supporting Android

MIPS hasn't gone anywhere. You can get PIC32 chips and boards based on them for various projects include the Open Source TenTec 506 Rebel radio.

While there's more tools and chips for ARM on small systems, I still prefer MIPS due to lower complexity/insanity of the tool chain.

It's hard to get any of the large system boards and multiprocessor chips without being an OEM.

I don't know if you saw this MIPS-based dev board being announced http://blog.imgtec.com/powervr-developers/new-mips-creator-c...

It's currently unobtainium, it can't be purchased.

Strange. He talked about that fact that MIPS has been lacking compatibility for Java apps on Android...but completely disregarded the fact that Android L will compile apps natively on MIPS, just like on ARM.

He's talking about something different. While dalvik's going away and apps will soon be compiled with native code, Android apps can already bundle native code in with the app through Java's Native Interface API. Such code is architecture specific, and usually only available for devices running under ARM, with occasional support for x86 processors. Additionally, some native code would only be available for specific architectures; Firefox mobile won't run on older phones because it requires an FPU, which wasn't guaranteed until ARMv7.

"it requires an FPU, which wasn't guaranteed until ARMv7"

That was true until ARM went and broke this rule with the Cortex A5 (which can optionally have the FPU removed)

For legacy, native non-MIPS code, we rely on binary translation.

Given I'd expect most JNI code on Android devices are supporting games, I doubt emulation is going to be a big winner.

From the second page of the article:

Android applications are either written in Java, then compiled on the device to the specific required ISA before running (a processes called JIT compilation), or written in the Android Native Development Kit (NDK) to target a specific ISA. Apps written in Java can therefore run on any ISA that Android itself supports, including MIPS.

I think it was explained pretty well, actually.

It's the native apps (mostly games) that aren't compatible with non-ARM CPUs, not the Java ones.

I think it is an interesting strategy, creating what is essentially an alternative to ARM/Mali as a single license SKU. There are rumors floating around that this chip is in a soon to be unveiled Chromebook. I take those with a large grain of salt since every hardware vendor seems to say "This is in the next gen (Google/Apple) device!"

Would love to see additional competition here, but Imagination has not been very forthcoming in the past on specs, so maybe Surface material rather than Android/Linux material.

Amusing headline considering MIPS chips (R4000 etc) were the first 64-bit CPUs outside supercomputers in the early 90s.

That was the first 64-bit RISC CPU, indeed. I think we can also claim first 64-bit CPU - but not 100% sure.

I thought it was the DEC Alpha which was the first commercial 64-bit CPU?

There were 64-bit CPUs long before there were 64-bit microprocessors. I don't know what the first was, but the IBM 7030 was a 64-bit machine in 1961. (My first computing job, as a co-op, involved testing a UNIX emulation environment for the 64-bit Control Data 180 series, in 1985.)

Well, Alpha and MIPS (and some supers before them) had 64 bit addressing to handle more than 4 GB of address space. The 7030 had just a handful of memory and no vm, through it did have a 64 bit word size. ARM and x86 have been able to handle 64 bit numbers without anyone claiming they're 64 bit.

Okay. The Cyber 180 for instance had 48-bit addressing.

The CDC 180 sounds pretty interesting from the WP article, and, I agree, 64-bit. So not just supers then.

Nope. MIPS was 91, Alpha 92. See https://en.m.wikipedia.org/wiki/64_bit#64-bit_processor_time...

    Imagination’s executives have also stated they are prepared to offer aggressive IP bundling discounts

My mind boggles at attempting to enumerate the number of issues implicit in that simple statement.

From the article: "Keep in mind that these processors use different instruction sets (ISAs) so DMIPS are not directly comparable."

But DMIPS doesn't refer to million instructions per second, but to the relative performance for a standard benchmark relative to a VAX 11/780 (which is considered to run at 1 MIPS). So any differences in instruction sets are already accounted for.

http://en.wikipedia.org/wiki/Dhrystone

You're assuming that that benchmark reflects real-world performance, but that assumption is not necessarily correct, especially given the age of the benchmark - I would be very surprised if the most commonly used instructions / etc have not shifted since 1988.

Also, the page you linked has a number of other concerns about said benchmark.

We are in violent agreement here. My point was just to note that the author apparently did not understand the difference between Dhrystone MIPS and "real" MIPS. He probably also did not understand that Dhrystone is an ancient benchmark that should not be used anymore.

But that's what you get when don't do your own benchmarks but copy/paste numbers from marketing material...

Yes, I think that he might not be familiar with how DMIPS works (or what it is).

> When Imagination Technologies acquired MIPS Technologies in 2012 for $100 million

Pretty depressing that a pioneering company like MIPS was sold for such a relatively small sum.

SGI sold for $25 million. http://bits.blogs.nytimes.com/2009/04/01/once-mighty-sgi-sol...

The engineers at MIPS were probably happy, since it meant that management might potentially commit to innovation again.

The original offer was $40M, which only went up because CEVA big up the price.

What's kind of neat is that you can put a downright silly amount of MIPS cores on something. Octeon, for example, with like 48 cores:

http://www.cavium.com/OCTEON_MIPS64.html

Xeon Phi currently ship with 57–61 cores (roughly P54C + AVX-512, IIRC). (Disclaimer: I once worked for Intel.) CPU cores are not a very big part of the die on most contemporary devices.

Question (since you seem to know about the Phi) is the Phi x86_64 (and its extensions), or is it as black boxed every other GPU like device?

It's basically a large number of in-order P5- (or Atom-) derived cores with 4-way SMT and beefed up SIMD capabilities (two 512-bit units per core).

RISC chips have done this for a while. Oracle's T5 Niagara was something like 256 execution threads per socket. Power8 (also a RISC chip) supports 96 execution threads per socket.

Most of a modern x86_64 chip is cache, and other System On Chip components (memory controller, PCIe controller, built in GPU), not necessarily what in the 80's and 90's we'd call the CPU.

I was looking for something like this recently, it's surprisingly hard to find with the internet flooded with SEO about ARM chips, it skews results and makes the other architectures harder to search for.

I found more MIPS arch chips reading the open cores site than I ever did googling. Shame too, when there's fantastic hardware like this out there.

The also have an ARM version:

http://www.cavium.com/ThunderX_ARM_Processors.html

Why isn't anyone making servers with them?

Thunder isn't released yet. Cavium may also have trouble building a server ecosystem given their culture of total secrecy.

eg the quoted IO performance requiring a proprietary IP stack...

Cavium's products have traditionally been geared more towards high end routers. Their chips have traditionally had massive amounts of networking bandwidth, but very little I/O for things like storage, or even RAM. Their ARM stuff looks like they may be about to change that, but details there are still rather scant.

The new coherency manager that we've designed allows us to build up to 64 clusters of 6 cores each.

That's not specific to MIPS, though.

Reply on news.ycombinator.com