6 ms·
Competition is great, but this also seems like a rather big setback to the goal of having multi-cloud applications, in instances where the app can only run on x
by zbjornson 10y ago
Competition is great, but this also seems like a rather big setback to the goal of having multi-cloud applications, in instances where the app can only run on x86-64.
- Zekio 10y agoisn't it microsoft who are making x86 emulation for ARM
- frozenport 10y agoI would think any cost per performance advantage would be lost.
- delinka 10y agoI don't think you'd run an entire OS like this. But some processes might not have been ported to ARM and those need an emulation layer. Think Apple's Rosetta for running PowerPC binaries on Intel processors to make the switch less painful.
- my123 10y agoARM and ARM64 Windows are 100% native code out of the box. On ARM64, the translation engine might be disabled if you really want to.
- infogulch 10y agoFor the emulated apps, sure. But apps compiled directly to the new architecture will gain a lot and benefit from the new architecture. Microsoft is big on backwards compatibility, so adopting a new architecture would be a complete non-starter if it weren't for an emulator.
- kerhackernews 10y agoI think the point is that Microsoft can how ship Surface devices with ARM chips that can occasionally run x86 applications when needed. And it also allows Microsoft to ditch Intel if they really wanted to.
- douche 10y agoHopefully they get it right this time. The last ARM Surfaces (Surface RTs) were hot garbage, barely functional enough to do email and a little web browsing on.
- scholia 10y agoActually they were better than that. Users loved them (check out the star ratings on user reviews) and some are still in use. The design was fundamentally flawed for other reasons, but they performed reasonably well compared to rival tablets, while also offering multiple log-ons, multi-tasking and full Microsoft Office, which those other tablets lacked. They also supported Active Directory, ditto.
- douche 10y agoMaybe I got a bad one then, but I was not real impressed with mine. 1.) Keyboard constantly flakes out and stops working - or the keyboard and touchpad works, but the touch screen stops working. 2.) Extremely limited software choices. You're stuck with whatever small subset of the garbage in the Windows Store was cross-compiled for Windows RT. Stuck with IE, no options to get Chrome or Firefox or something that works a little better. 3.) Extremely anemic performance. Mine chokes and dies trying to read email (in the godawful Metro Mail app) and browse the ticketing webapp that my company uses. 4.) Suffers the brunt of the awful Windows 8 Metro UI design changes. 5.) The operating system is effectively dead in the water, and won't be getting updates. 6.) Microsoft took a $900 million write-down on the product[1]. [1] https://arstechnica.com/business/2013/07/microsoft-takes-900-million-hit-for-unsold-surface-rts-in-4q13-earnings/ https://arstechnica.com/business/2013/07/microsoft-takes-900...
- scholia 10y agoI haven't seen the keyboard problem. The main one I saw was a disappearing mouse pointer, which was fixed by removing and re-attaching the keyboard. Weird. You could try a software reset for the performance problems, bearing in mind that the updates will drive you mad. Unfortunately you can't fix the slow CPU or the too-small RAM. However, the current performance should still compare reasonably with another 2012 tablet. > The operating system is effectively dead in the water, and won't be getting updates. Look out for Windows 10 on the Snapdragon 835 later this year ;-) > Microsoft took a $900 million write-down on the product Yes, I bet that hurt, even when you have the odd $100 billion in spare cash.
- my123 10y agoIt's Microsoft indeed.
- deleted 10y ago[deleted]
- mikeash 10y agoWriting architecture-specific code is what would be a setback to that goal. Either write portable code, or be prepared to translate non-portable parts to new CPUs from time to time.
- my123 10y agoAMD designs are used as a part of the design, and AMD has shown x86 and ARM chips which fit in the same sockets
- mrweasel 10y agoOn the same motherboards? That's rather impressive, if the same motherboard can support two different chip architectures. Having an ARM chip that just happens to use an AM3/AM4 socket is less impressive.
- microcolonel 10y agoAnd it means that presumably you could put a RISC-V or a Power8 in there too. ;- )
- my123 10y agoAM4 chips are SoCs which do not need a chipset to work technically
- morganvachon 10y agoI'm purely a layman in this space, but I don't see why it would be impossible. Pretty much all modern CPUs are actually SoCs. Modern peripheral connections like PCIe and USB 3 have direct access to the CPU rather than going through custom bridge chips, simplifying board design and making it possible to use the same board for two architectures. Audio and network chipsets don't care what architecture the CPU uses. Again, I'm far from an expert but it seems like a simple enough solution.
- sounds 10y agoAs someone with a lot of experience in board bring-up, trust me, the hard part isn't grabbing AMD's reference board, sticking on an audio chip and a wifi chip and sending it over to a board manufacturing shop. The hard part is wrangling the software: BIOS, drivers, testing and more testing, patches, microcode updates. Finding out that your wifi chip vendor has moved the chip to end-of-life just before you were ready to ship would be a non-issue if the software part were faster.
- rb808 10y agoThere are fewer binary apps these days though. Java/Scala, C#/F#, JS, Python, Erlang should all be fine.
- inyorgroove 10y agoDon't most docker containers contain x86 binaries?
- ajross 10y agoOf course, which is sort of the point: ARM is way behind with Linux packaging and distribution. Every vendor has their little tarball of junk that runs on their SoC or device or whatever. There's no architecture-unified distro you can install on everything. And this is where it gets hurt, because while Raspberry Pi can get away with handing out tarballs, no one is going to bet a datacenter install on anything other than RHEL or Ubuntu or whatever.
- my123 10y agoARM and ARM64 Windows uses UEFI and ACPI, with the same OS images for everyone.
- ajross 10y agoRight, I was addressing the Docker problem in the grandparent, sorry for the confusion.
- acdha 10y agoDebian and Ubuntu have had ARM ports for years. Prospective server vendors will need to address the driver situation but once you've booted the userland is highly portable.
- ajross 10y agoFedora has too, I believe. But that's sort of missing the point. Userspace ports got done years ago because they're the easy part. The hard part is the system integration that you sweep away as a "driver situation" to be dealt with by "vendors". And so far there's no significant entry here for the ARM world. So you can't roll up a server install or Docker container that isn't, fundamentally, a hacked up tarball from some random vendor. And the market doesn't trust that.
- dragontamer 10y agoMicrosoft has UWP Apps as part of Windows 10. Any UWP application will automatically run in the .NET Virtual Machine and work on both x86 and ARM. That, in combination with emulation for the x86-based legacy stuff, should be a powerful reason to use the Microsoft platform. Even if ARM servers don't become a thing, the support of ARM servers only benefits Microsoft and their current "Universal Windows Platform" strategy.
- Const-me 10y agoYes, Microsoft has UWP. No, UWP and .NET are orthogonal. When I need to, I’m using C++ to develop my UWP apps just fine. Edit: and even when using .NET, by default, UWP apps don’t run in the virtual machine. Instead, they’re compiled to native code with .NET Native.
- jdmichal 10y agoThis is correct. However, it's important to point out that the .NET native compilation can also target ARM architectures. For native development in C++, one would need to build and distribute ARM-targeted binaries also in order to actually be "universal".
- pjmlp 10y agoIt is no different for .NET Native.
- pjmlp 10y agoThis is why using some kind of bytecode as portable binary format has been a long tradition on mainframes, almost since the early days, when it was executed via microcode. Modern computing has just been catching up with them.