bit-tech.net

Russian company promises x86-on-ARM emulation

Russian company promises x86-on-ARM emulation

The 'PC Emulator' found on the Acorn Archimedes could be coming back home, thanks to work by Elbrus Technologies.

A Russian software company is working on a stop-gap measure that should give Intel cause for concern: high-performance x86 emulation code for ARM architecture processors.

Designed to aid companies looking to move from high-power Intel chips to energy-efficient ARM microservers, the software allows native x86 code to execute on the ARM architecture. While doing so loses a great deal of performance - as is always the case with emulation - it provides companies with a way of migrating to the ARM platform while they wait for the software to be ported to native ARM code.

According to EETimes, the software from Elbrus Technologies is already fully operational but at a somewhat unusable 60 per cent performance penalty compared to native ARM code. By the end of 2014, when the software is expected to be ready to launch, the company hopes to get that down to around 20 per cent.

Even at 20 per cent, the move will leave companies on the performance back-foot: modern ARM processors are significantly simpler than their x86 counterparts, which is one of the reasons for their energy efficiency. A high-end server-centric ARM chip may run as many as four processing cores at a speed up to 2GHz, which compares poorly with the likes of AMD's Opteron and Intel's Xeon families reaching speeds above 4GHz and with up to 16 cores per chip.

Where ARM has an advantage, however, is in its power efficiency: beating both Intel and AMD in performance-per-watt, it's possible to fit significantly more ARM cores into the same power and thermal envelopes than x86 processors. A 20 per cent performance drop per processor, then, isn't quite so critical when you have two, three or four times as many processors to play with.

This is far from the first time an x86 emulation engine has been developed for the ARM architecture. Back when Acorn, the microcomputing company that gave birth to ARM, was still a going concern, a popular add-on for its ARM-based Archimedes and RiscPC products was a software 'PC Emulator' which allowed the systems to run MS-DOS 3.3 on emulated x86 hardware.

Should Elbrus be able to boost its performance as high as it hopes, and provide an application-level translation engine - rather than the full-system virtualisation offered by previous x86-on-ARM packages - ARM's chances of taking on Intel in its core markets will get a significant shot in the proverbial.

15 Comments

Discuss in the forums Reply
Guinevere 4th October 2012, 12:43 Quote
A 20% hit to efficiency isn't bad, but if they're taking a 60% dive at the moment then they have a LOT to do to get that far.

So what's the final aim for this? To run an x86 OS as a VM on ARM hardware? Is there really much demand for it? Maybe in a few years. I can't see enterprise making the shift to ARM servers while still wanting to run their legacy OSs on them, not when there are so many options with hosting x86 software on x86 hardware.

A few years time (if it happens) when there's a greater reason to have ARM servers I can see being able to host legacy OS versions a plus.

The other thing you could do with this (I guess) is host a full x86 OS on an ARM tablet (A rooted android, win8 RT... even an iOS device). Slow performance and terrible battery life but it could work...

If this software layer does what they claim.
Gareth Halfacree 4th October 2012, 12:53 Quote
Quote:
Originally Posted by Guinevere
So what's the final aim for this? To run an x86 OS as a VM on ARM hardware?
No, it's to run native x86 applications on ARM. They're targeting the datacentre. Let's say, for example, that a few years ago you paid to have SuperFinancialTransactionServerPro written for you. It runs fine on your x86 servers, but now you want to move to ARM. Uh-oh: SuperFinancialTransactionServerPro doesn't run on ARM. Solution: buy the ARM servers anyway, run SuperFinancialTransactionServerPro under emulation, and eventually port the software across to ARM native.

Look at Rosetta on Mac: when Apple moved from PowerPC to x86, it was able to write a new OS no problem. Trouble is, none of the client software everyone had would run. Companies like Adobe promised to port the software to x86, but it wasn't ready - so Apple hired a company to write an emulation layer that allowed PowerPC applications to run on x86 hardware under an x86 OS. When there had been Intel-native versions of all the apps out for a few generations, and the old PowerPC Macs had fallen well out of extended support contracts, Rosetta - which was only ever a stop-gap measure - was killed off. This company is doing exactly that, but swapping 'x86' for 'ARM' and 'PowerPC' for 'x86.'
Guinevere 4th October 2012, 13:43 Quote
Quote:
Originally Posted by Gareth Halfacree
No, it's to run native x86 applications on ARM. They're targeting the datacentre. Let's say, for example, that a few years ago you paid to have SuperFinancialTransactionServerPro written for you. It runs fine on your x86 servers

Yes I get that. But what OS does "SuperFinancialTransactionServerPro" run on? The EE article refers to "server software" which could be something like "BlackBerry Enterprise Server" that runs above windows or "VMware ESX" that runs bare metal.

If it's bare metal hardware, then yes maybe it'll run onto of his x86 hardware virtualisation layer, but very little is written to work like that and isn't that just hosting an OS in a VM anyway? So much server needs need a full windows OS and about half a dozen windows API flavours or a full linux behind the scenes, which is why I was wondering if the aim was to go with full machine virtualisation.

It's possible with russian devs are hoping their code is adopted to be adopted by an OS vendor and used like rosetta to run pre-compiled code but it isn't clear from this BT article or the source if this is the case.

Which is why I asked.
dyzophoria 4th October 2012, 14:17 Quote
do we really need to run x86 stuffs on ARM? I kinda like running native software in ARM :D only..
azazel1024 4th October 2012, 15:25 Quote
What kind of server response times are you likely to be looking at though in scenarios where you have high density, low performance per core servers? I certainly think that has its place, but I'd imagine that isn't going to fill the needs of a lot of people/companies and a 20% performance penalty on top of that...

Performance per watt is pretty useful, but it can also be a pretty poor goal in mind when other things like server response time, total FLOPS, memory bandwidth, memory density, overall build power budget, etc need to be considered as well.

Great for low performance micro servers and clusters. Not so good for medium/high end applications. Also with a 20% performance hit goal...that might not stack up so well against upcoming Atom designs which aren't going to have that performance hit, and radically better processing capabilities and efficiency compared to current atom designs from everything coming out of Intel.
Gareth Halfacree 4th October 2012, 15:27 Quote
Quote:
Originally Posted by Guinevere
Yes I get that. But what OS does "SuperFinancialTransactionServerPro" run on? The EE article refers to "server software" which could be something like "BlackBerry Enterprise Server" that runs above windows or "VMware ESX" that runs bare metal.
Whatever OS it ran on before, or a compatible OS. Remember, the overwhelming majority of server applications - especially in the many-core highly-parallel market - run Linux or another Unix-alike. In the case of Debian, for example, you can get the latest version in ARM, MIPS, PowerPC, x86, x86-64, and a dozen other flavours. Buy an ARM server, install the ARM build of Debian, install the Russian x86-to-ARM compatibility layer, install your x86 build of SuperFinancialTransactionServerPro. Job's a good 'un.

If you were looking at Windows apps - which are a minority in the datacentre world - then you could just use wine to provide the Windows compatibility needed to have it work under Linux. Bosh.

EDIT: That's unlikely to be the case, though. Remember that the target audience for this product is people already thinking about moving to an ARM platform. With no current generation Windows server product on ARM, it's highly unlikely that anyone relying on a Windows Server environment is even considering moving to ARM.

The OS isn't the problem; the application is the problem.
dicobalt 4th October 2012, 15:28 Quote
A 20% penalty while emulating x86 on ARM is totally believable and I have a bridge for sale.

It'll never ever happen unless they modify the ARM instruction set, but then it wouldn't be ARM anymore.
Gareth Halfacree 4th October 2012, 15:36 Quote
Quote:
Originally Posted by dicobalt
A 20% penalty while emulating x86 on ARM is totally believable and I have a bridge for sale.
I have no trouble believing it, if they're talking about ARMv8 - the hardware virtualisation extensions are going to help immeasurably.
Anakha 4th October 2012, 15:42 Quote
Wow. They discovered Bochs. Or perhaps qemu
faugusztin 4th October 2012, 15:46 Quote
I think this whole project is a result of the Elbrus 2000 "fiasco", they took the only usable part of that project :
mceI07NeIt0
Gareth Halfacree 4th October 2012, 15:55 Quote
Quote:
Originally Posted by Anakha
Wow. They discovered Bochs. Or perhaps qemu
Not exactly: neither Bochs nor qemu - correct me if I'm wrong - will allow you to execute x86 applications within a non-x86 OS. Instead, they allow you to run an x86 OS on top of your non-x86 OS, then run the application on that - something that will have far higher overheads than the claimed 1MB of memory needed for Elbrus' system.
AmEv 4th October 2012, 16:50 Quote
Perhaps they found https://play.google.com/store/apps/details?id=org.hystudio.android.dosbox&feature=search_result#?t=W251bGwsMSwyLDEsIm9yZy5oeXN0dWRpby5hbmRyb2lkLmRvc2JveCJd :D


Honestly, it seems more like a reverse WINE. Instead of translating kernels, it translates architecture byte code.
mdshann 4th October 2012, 19:41 Quote
Sounds like the Transmetta Crusoe... maybe not though. It didn't work well for them either, the performance hit was too much.

http://en.wikipedia.org/wiki/Transmeta#Crusoe
Bakes 4th October 2012, 19:59 Quote
To people who seem skeptical, I believe mainframe emulators were used for this sort of thing for quite a while (many are probably still in use) to allow old COBOL software to be run on newer, non-broken/bespoke hardware.
trevj 5th October 2012, 08:05 Quote
Quote:
Back when Acorn, the microcomputing company that gave birth to ARM, was still a going concern, a popular add-on for its ARM-based Archimedes and RiscPC products was a software 'PC Emulator' which allowed the systems to run MS-DOS 3.3 on emulated x86 hardware.
Minor correction: The RiscPC was designed around accepting a separate physical x86 processor card. Software is also needed to integrate it with the host ARM processor and OS.

The fully software solution was a forerunner to this on earlier machines.
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums