Hacker News Reader

Comment by simcop2387 | Hacker News Reader

I would honestly like to see what happens if AMD makes a heterogenous CPU. one with say 4 arm cores and 4 x86 cores. where you could shut off the x86 cores if you didn't need them.

View on HN

While this would be cool, I'm not exactly sure under what circumstances this would be useful.

This could be usefull for High-Availability / Fault-Tolerant applications.

I think 10 years ago, Ericsson had a highly available server machine for Telecom application, named Jambala. It had 2 SPARC and 2 x86 CPUs. Having two different ISAs in the same system can protect you from subtle software/hardware errors. So you compile you code to both targets, if for some reason one of x86 CPUs fail, the second x86 takeover, if both x86 fail, then SPARC CPU takeover, etc.

Off-course this system run Erlang/OTP ;)

One possible use case for heterogeneous CPUs that comes to mind is in laptops the same way AMD Switchable Graphics is used now: to save power when you don't need the performance. However, I'm not sure if any energy efficiency benefits of this solution wouldn't be offset by the increased software and hardware complexity (which costs both money and battery power). If anything, it might be easier and cheaper for AMD to pair up its high-performance ("Steamroller") x86 cores with low-power ("Jaguar") ones instead.

A tablet that could run x86 applications as needed but wasn't optimized for them.

Why not just run a VM, and use the saved die area for more cache?

Everyone's always had this idea, and it has very rarely proven to be terribly practical in reality. The few times that VMs of different hardware tend to be practical are when there is an enormous gap in performance between the emulated hardware and the host hardware (such as with old game consoles and arcade hardware).

I don't think it has been tried too many times in practice, because software binary translation is so proven (eg. like in android x86, or rosetta on mac, or fx!32 on nt, etc etc). Itanium is the only one that comes to mind. Any others?

Then there are several that have lower level "programmable microcode" kind of level in the hardware, ranging from the Transmeta stuff to mainframe-era writable control store...

Yeah, you're right. It would not match this use case.

'cause cross-platform VM means emulation, and emulation is as a rule 10x slowdown at best?

JIT at installation time?

That's not emulation that's decompilation / recompilation. Which is a very challenging task. TransMeta worked on this under the name of "code morphing". It's a promising technique but I don't think it has the maturity to be able to run cross-architecture code at close to hardware speeds (say, 50% or higher) without introducing new defects, especially x86 on ARM.

What you are discussing about, is a runtime issue.

I was discussing about installation time, which only prevents situations were you make use of code rewriting tricks, which are anyway frowned upon in the day and age of read-only code sections and no-execute data sections.

(Worth mentioning that the fancy new Mill processor takes this approach. It is technically viable, as Transmeta have already proved.)

Thanks for the heads up.

Putting a link here for those that want to follow up.

http://staff.science.uva.nl/~poss/posts/2013/08/01/mill-cpu/

Would that be platform independent ?

Of course not, the translation engine needs to know how to properly map the op-codes between architectures.

Emulating a processor of another architecture will not be as quick as having the hardware, will it?

Indeed, I guess it depends whether your x86 application is going to be MS Word or some new game.

It would be cool if both the ARM and the x86 cores could use the same GPU.

exactly. this is actually where it could end up really useful for windows 8 even. run unmodified rt versions of software or the original x86. enabling it could be very interesting for the surface tablet. it would also be in theory doable for osx and ios that way.

why not just a x86 tablet?

Reply on news.ycombinator.com