back to article Windows on ARM: It's nearly here (again)

It's a milestone in Windows history: the first benchmarks for a new generation of ARM-powered Windows hardware have been sighted in the wild. Geekbench has recorded an instance of a box running Windows 10 on the "Qualcomm CLS" platform. This entry describes an octocore processor, running 8GB of memory, and cites a Qualcomm …

  1. hammarbtyp Silver badge

    The questions is why?

    You have the following choices.

    Run something like a cheap Chromebook running efficiently on native ARM,

    a wintel machine running native x86 apps relatively efficiently

    or a arm box running windows native on a x86 emulator slowly

    The last one seems to be the worst of both worlds

    1. Dan 55 Silver badge

      It's not that bad for ancient exes where all it is is a GUI with fields and an event loop and does some magic calculation or talk to a database when you hit 'Go'. Somewhat grandly called enterprise software.

      1. Yet Another Anonymous coward Silver badge

        Somewhat grandly called enterprise software.

        An x86 probably VisualBasic GUI running on an x86 emulator running on ARM, simulating an IBM3270 terminal session talking to a mainframe. over an ethernet connection pretending to be RS232

    2. Anonymous Coward
      Anonymous Coward

      Option 3. Long battery life running thinks at an OK speed.

      Not everyone wants fastest.

      1. P0l0nium

        Screen power ....

        Since 50-70% of the device power goes to the screen then why would anyone bother having the most efficient SOC at any cost?

        And there's no evidence that an ARM SOC is any more efficient than an X86 SOC doing the same work. If there was then the world would be full of ARM servers.

        1. Ken 16 Silver badge
          Trollface

          If there wasn't then the world would be full of Intel smartphones

          There, fixed it.

      2. defiler Silver badge

        Option 3. Long battery life running thinks at an OK speed.

        Well, that's fine, but Intel have come on leaps and bounds on power consumption these past few years (spurred / scared on, I expect by ARM). Surely a small, native implementation of x86 (looking at you, Atom) could be created more efficiently than ARM running an emulator (albeit on in hardware).

        Or course, my understanding it that the current x86/x64 chips decode the instructions into smaller chunks, and that the native silicon actually runs a simplified instruction set. I could well be wrong on that (CPU design is not my thing), but that would suggest to me that even Xeons are running "emulated" x86.

        And yes, that was a fair few brackets I used there - not even sorry. :P

        1. Def Silver badge

          ...current x86/x64 chips decode the instructions into smaller chunks, and that the native silicon actually runs a simplified instruction set...

          Yes, they essentially do. You wouldn't believe the things modern Intel processors go through to support the x86 instruction set.

        2. CheesyTheClown

          Instruction set doesn’t really matter

          You’re absolutely right. Intel hasn’t run x86 or x64 natively for years. Instead, they have an internal instruction set decoder/recompiler implemented mostly as ASIC and partially as microcode to make it so x86 and x64 is little more that a means of delivering a program. In fact, it’s similar to .NET CIL or Java IL. It’s actually much closer to LLVM IL.

          There are some real benefits to this, first is that the recompiler can identify instructions that can be executed out of order as there are no register or cache read/write dependencies. Alternatively, it can automatically run instructions on parallel on separate parts of one or more ALUs which lack dependencies. As such, more advanced cores can process the same code in less clock cycles assuming there is no contentions.

          Microsoft has spent 15 years moving most non-performance critical code away from x86 or anything else and over to .NET. They also have implemented the concept of fat-binaries like Apple did with PPC, ARM and x86/x64. In addition, they have been making LLVM and CLang part of Visual Studio. Windows probably has a dozen technologies that allow platform agnostic code to run on Windows now.

          Emulating x86 is nice, but is really only necessary for older and unmaintained software. Most modern programs can carry across platforms with little more than a recompile and for power conscious devices GPU intensive code will be the same and CPU intensive code is frowned upon. So, you wouldn’t want to run x264 for example on a low power device ... and certainly not emulated. You’d favor either a video encoder core or a GPU encoder.

          As for JIT and AOT dynamic recompilers, I can literally write a book on the topic, but there is absolutely no reason why two architectures as similar as x86 and ARM shouldn’t be able to run each other’s code at near native speed. In fact, it may be possible to make the code run faster if targeting the specific local platform. Also consider that we have run ARM binaries emulated on x86 for a long time, the performance is very respectable. I believe Microsoft is more focused on accuracy and limitation of patent infringement. Once they get it working, it is entirely possible that running x86 on x86 may be faster than running native because JITs are amazing technology in that they can do things like intelligently pipeline execution branches and realign execution order for the host processor.

          Nice comment though :)

    3. Anonymous Coward
      Anonymous Coward

      I would have a Chromebook (one that runs android like the R11) over pretty much anything else, even a windows PC.

      Security foremost and only Chromebook offers that.

      1. Anonymous Coward
        Anonymous Coward

        "Security foremost and only Chromebook offers that."

        LOL, you must have missed all the numerous previous vulnerabilities patched in Chrome OS! Take a look at the CVE database...

        1. hplasm Silver badge
          Windows

          Re: LOL

          "...vulnerabilities patched in Chrome OS!"

          There's the operative word, right there.

          1. Anonymous Coward
            Anonymous Coward

            Re: LOL

            "There's the operative word, right there"

            But the problem is that the utterly vast number of them for such a cut down OS suggests that an attacker with resources could easily find more...

          2. HandleAlreadyTaken

            Re: LOL

            >>...vulnerabilities patched in Chrome OS!"

            >There's the operative word, right there.

            I'll venture to say that the operative word is "vulnerabilities".

          3. CheesyTheClown

            Re: LOL

            “Known” is the key word.

        2. Anonymous Coward
          Anonymous Coward

          No, I understand how Chromebook works and how it's architecture fundamentally changes how an OS works for the better. Fully signed read-only runtime that can't be modified, and can only be updated by a matching bootloader cert means no room for dodgy stuff to slip in.

          1. Anonymous Coward
            Anonymous Coward

            "Fully signed read-only runtime that can't be modified, and can only be updated by a matching bootloader cert means no room for dodgy stuff to slip in."

            So just like secure boot on Windows you mean?

            1. Anonymous Coward
              Anonymous Coward

              Nope, not like secure boot at all. You don't appear to understand the huge difference between a hash (Windows) and a hash-tree (ChromeOS). Also the term Read-Only appears to be an alien concept too.

              Literally on ChromeOS, you can't change a single byte on the entire OS without it failing a boot check, or runtime check.

              1. Anonymous Coward
                Anonymous Coward

                "Nope, not like secure boot at all."

                No, that is just like Secure Boot + Device Guard.

        3. CheesyTheClown

          Sorry... I vomited in my mouth as choking

          On what planet is Chromebook secure?

          A) runs Linux as a core

          B) has very little security research targeting it, so most vulnerabilities are unknown.

          C) Runs on fairly generic hardware produced by vendors who don’t customize to the local security hardware.

          D) has a fairly small business user base and hasn’t properly been tossed to the wild as a hacker target.

          I can go on... but that comment was as good as Blackberry claiming that 11 million lines of untested code for a total rewrite with an entirely new OS Core was secure.

          1. Paul

            Re: Sorry... I vomited in my mouth as choking

            Given that the entire internet thing on Linux, I'm not sure whether you're trolling.

            the fact that Google pay huge bug bounties to people who uncover security bugs gives a clue how serious they are about security. They also have dedicated zero-day security researchers.

            There's a huge base of users, e.g. educational establishments in the USA, who have fleets of these.

      2. asdf Silver badge

        except

        Security foremost and privacy who gives a sh1t eh? Must be a millennial. Biggest problem with ChromeOS is having to always browse in Guest mode to even have a chance at privacy and even then have to make sure to disable all those helpful services Google enables by default in the browser to data mine you.

    4. thames

      @hammarbtyp: "The questions is why?"

      The reason is that the Achilles heel of Windows when it comes to portability is that the only reason people buy Windows is to run proprietary x86 applications. Microsoft can port Windows, MS Office, MS SQL Server, Dot Net, and various other bits of software that they own to ARM, but each customer will always a handful of third party applications that haven't been ported and that they don't want to do without. Being able to run those poorly is better than not being able to run them at all.

      It's a chicken and egg problem Third party developers won't support Windows on ARM until there's a market for it, but customers won't create a market for it until there's enough third party software to run on it.

      There's work in porting software, since you have to fix the application bugs which have been there all along but haven't surfaced on x86 but will show up on ARM. Then you have to worry about performance tuning on a different architecture. Plus you have to set up the development, testing, and QA servers to support the new architecture and add it to your release pipeline. And you have to do all this while waiting for years for a significant market to materialise.

      Linux distros have supported multiple architectures for years because they have the source code for the applications they distribute and can simply recompile them in most cases. Since portability has been a core feature of most "unix" style operating systems from the early days, most of these applications have had the porting bugs wrung out of them years ago. Debian has official support for AMD64, i386, ARM, MIPS, PPC, and S390x (IBM mainframe). They have unofficial support for others as well, including SPARC.

      Microsoft is starting without any of these advantages. Their Itanic port died some years ago and the few third party software developers who bought into that will be shy of repeating that experience until they see a real market running Windows.

      1. teknopaul Silver badge

        turns out "native" code is portable

        Its amazing how portable 20 year old C code is. Compared to languages that claim a common runtime as a goal like Java and .Net.

        I just wrote a lot of new C code on a fairly new framework and to my surprise it compiled and ran with minimal tweaks on ARM (on an rpi).

    5. Richard Plinston Silver badge

      > or a arm box running windows native on a x86 emulator slowly

      Note that the ARM x86 emulator will only run 32bit x86 and not AMDx86-64.

      Some years ago Microsoft announced that there would be "no more 32bit versions of Windows". Of course they still do have 32bit versions, but many software companies switched entirely to 64bit only. Now, are they able and willing to revert to 32bit versions just to run on slow ARM emulation ?

      1. AndersBreiner

        It's because the emulation is part of Windows on Windows.

        Back in the NT 3.x days they supported Win32 code via the Win32 API in the kernel and Win16 code via WOW. On x86 the code was both the Win32 code and the Win16 code in WOW could be run natively by setting the processor up in the right mode and WOW was mostly a thunking layer. On Risc platforms - PowerPC, Mips, Alpha - WOW had a x86 emulator which they licensed from Insignia called SoftPC. So back then if you had a Win32 app it needed to be compiled natively, which of course was unlikely for the Risc platforms.

        It's the same now, though I believe the x86 emulator is in house. So 64 bit apps must be native and call 64 bit APIs. 32 bit apps go through WOW. On an x64 chip that's a thunking layer. On a Risc platform they use an emulator. Though from what they're saying they're going to JIT code in their in house x86 on ARM emulator.

        Back in the NT 3.x days Dec actually did produce a clever emulator called FX!32 which emulated initially but later JITted the most frequently emulated Win32 x86 code ended up native Alpha. There is/was actually a hook in the Windows loader to allow this - it calls out if it is asked to load a Win32 PE file compiled for the wrong architecture. FX!32 used that to do it's 'emulate and profile first, then JIT the performance critical parts' magic.

        However for Microsoft have decided to stick with the 'put the emulator only in the WOW path' for some reason and not do a FX!32 equivalent which would run x64 binaries on ARM64.

        The performance they're reporting isn't very good compared to code running natively on a Snapdragon 835 aka MSM8998. The Geekbench 3 score is about half what it should be

        http://browser.geekbench.com/geekbench3/search?dir=desc&q=MSM8998&sort=score

    6. Anonymous Coward
      Anonymous Coward

      a wintel machine running native x86 apps relatively efficiently

      or a arm box running windows native on a x86 emulator slowly

      Most low-end Windows PCs use Atom / Celeron / Pentium / AMD A-series CPUs, and their performance is similar to the Qualcomm ARM emulating x86. For example, my 2+ year old N2840 netbook is slower at both single and multicore Geekbench according to http://cpuboss.com/cpu/Intel-Celeron-N2840

      So it looks like the low-end x86 market is under threat. I would include games consoles in that.

    7. Anonymous Coward
      Anonymous Coward

      Why?

      Moore's law. Today it's a tad underpowered. Give it a couple of years and it will be exceptionally adequate.

      Intel is big and lumbering so can't afford to make cheap low margin processors, so the choice is going to be between cheap but adequate or expensive and overpowered.

  2. Anonymous Coward
    Anonymous Coward

    Why can’t Windows run ARM natively, and all none MS software run in an emulator?

    Most legacy software was written to run on much slower hardware than what was written today, so the perform hit shouldn’t be that big a deal...

    —-

    I guess the point is Microsoft needs to recompile/rewrite everything they sell for ARM before anyone is going to take this seriously. Likely what would happen is a mixed environment of x86 (autocad etc.) + ARM (MS software only) which sounds like a pain in the ass to support.

    1. Def Silver badge

      Windows and Universal Apps will be running natively.

      It's only legacy applications that'll be sandboxed into thinking they're running on x86.

      In a way, I imagine this is not much different to shoehorning 32-bit apps into 64-bit Windows.

      1. jab701

        And only the user parts of the code will be emulated.

        Any Kernel calls will call the native ARM code in the OS.

        So I guess it depends what your app is doing as to how fast it will run....

  3. /dev/null

    Alpha, MIPS, PA RISC, and PowerPC

    Don't recall an NT port to PA-RISC, at least not one that was publicly announced. OTOH there were Itanic releases of XP and Server 2003/2008.

    1. Dave Pickles

      Re: Alpha, MIPS, PA RISC, and PowerPC

      No, but on the topic of x86 emulation, the DEC Alpha machines had an x86 emulator in their boot ROM. It was needed to execute the x86 code in the boot ROM of the graphics card.

  4. Anonymous Coward
    Anonymous Coward

    When Microsoft attempted to run Windows natively on ARM, in the shape of Windows RT, the world stayed away. There was too much technical debt, aka legacy cruft, to make a clean port. Something, somewhere wouldn't run.

    Something, somewhere? More like everything, everywhere. Apart from the set of Microsoft's own apps that they ported and the small amount of worthwhile stuff from the spectacularly successful Windows Store, the vast majority of existing Windows applications were incompatible with RT. Even if you were talking about apps being recompiled for Arm, RT only supported Windows Store apps from third party developers. So even if your "legacy" desktop application would have recompiled cleanly, it still wouldn't run on RT.

    1. Dan 55 Silver badge

      VC did support Win32 on ARM if you changed a few settings first and Surface RT did run ARM exes if unlocked. link

  5. Anonymous Coward
    Windows

    Smart

    Good move by MSFT as it pulls the rug out from under lazy churnalists who scuppered RT and WIndow 10 Mobile by spewing FUD about the 'app gap'.

    Now MSFT can move on from Intel and still run the Win32 apps where the coder's been dead for years.

    1. Dan 55 Silver badge

      Re: Smart

      What are you on about? Nobody was interested in RT because they thought they could run Desktop apps and nobody was interested in Windows 10 Mobile because there were hardly any apps of any kind.

      1. Anonymous Coward
        Anonymous Coward

        Re: Smart

        Thank you for proving my point.

  6. AndersBreiner

    About as fast as an Atom

    To put it in perspective that puts it about level with an Intel Atom x5-Z8550

    http://browser.geekbench.com/geekbench3/8255581

    I.e. you're not going to get a good experience running Photoshop on it as in Microsoft's demo

    https://www.youtube.com/watch?v=gQ5bmRjBDeg

    Even worse consider SIMD. Intel pointedly reminded everyone that recent SSE instructions are still patented here

    https://newsroom.intel.com/editorials/x86-approaching-40-still-going-strong/

    Now it's fair to assume that Photoshop uses a lot of recent SSE which could be translated to ARM SIMD. However the Intel blog posts is essentially threatening the OEMs with a lawsuit if this is enabled. The best way to avoid that is to disable SSE to ARM SIMD translations but that has a significant performance impact. I.e. not only would you be running Photoshop on a processor equivalent to an Atom, it's won't implement any SIMD instructions. And there's the question of how many Win32 x86 applications actually require SSE since it has been around for long and is actually a pretty well designed SIMD instruction set.

    It's shame really. I'd love to see a Win32 phone based on Atom or Snapdragon chips that let you run Win32 applications. In fact that's what I thought they'd do with Windows Phone and/or WIndows RT. Unfortunately they decided to disable non Microsoft WIn32 ARM executables to try to get people to use Metro apps from the store. Now Windows Phone is dead could they try WIn32 Phone? On an Atom I reckon that might be viable. Most of the Android apps I use have a Win32 version. Chrome and Opera do. Pleco, my favourite Chinese dictionary actually run well on Windows Mobile before it run on Android and iOS. Problem is killing off Win32 WIndows Mobile applications on Windows Phone has alienated a lot of ISVs. Even if Microsoft launched Win32 Phone now, it's not clear if they'd bother to support it given how dominant Android and iOS are.

    I suspect the ship has sailed. Everyone has moved on to Android and iOS and another phone OS isn't really viable.

    1. Anonymous Coward
      Anonymous Coward

      Re: About as fast as an Atom

      Photoshop is a relatively high-end use case. If you're spending £50 a month on a CC subscription you're probably not bothered about splashing out for a high-end i5 or i7, and you're probably not the target market for this.

      I expect this is aimed squarely at the high volume "back room terminal which runs Office + Edge + Web apps" type workload, and if it's Microsoft apps then it's all going to get recompiled to real native code anyway (and browser includes the JIT for scripting, so nicely platform agnostic). For a lot of use cases a low-cost all-in-one or Mac mini-like form-factor would make a huge amount of sense.

    2. Adam 1

      Re: About as fast as an Atom

      > However the Intel blog posts is essentially threatening the OEMs with a lawsuit if this is enabled

      The difference here is that Microsoft definitely want this to happen. They want to compete with tablets and Chromebooks but RT lacks traction and Intel can't hit that day spot on price/speed/power.

      Microsoft have a big enough stick to force them to negotiate a license with OEMs to use those instructions.

  7. Chris Miller

    If you can remember the '90s, you weren't really there, man.

    1. Korev Silver badge
      Coat

      What are you raving on about?

    2. Anonymous Coward
      Anonymous Coward

      "If you can remember the '90s, you weren't really there, man."

      That was back when things could only get better.

  8. DrXym Silver badge

    Utterly, utterly pointless

    "Hooray now I can run a subset of Windows software at a fraction of the speed of an x86 computer!"

    Said nobody ever.

  9. Paul

    These won't be running a BIOS! Come on, El Reg, you should know BIOSes are long dead.

    Anyway, I have a horrible suspicion these will have locked down UEFI firmware and locked bootloaders, and thus will only boot a signed Windows kernel, so can only be made to run Windows son-of-RT or whatever Microsoft will call it, and also only run signed apps from the Windows store.

    Thereby basically achieving what Apple have done with the iOS (iPad/Phone/Pod) and trying to do with the Mac.

    1. Anonymous Coward
      Anonymous Coward

      "Anyway, I have a horrible suspicion these will have locked down UEFI firmware and locked bootloaders"

      I don't think it likely. Firstly most of these wont be made by Microsoft so it will be an OEM decision. Secondly near zero people would install an non MS OS and if it's Intel hardware both manufacturers and users would probably want the option of installing other Windows OSs too.

      And whilst we know Windows 10 has historically had far fewer holes in boot loaders, etc. than Android / Linux, etc. to compromise such a system, someone normally always finds a way if there is a demand!

  10. Anonymous Coward
    Anonymous Coward

    Native code good, x86 emulation bad

    On servers anyway, because non-x86 gave a degree of Windows virus protection.

    Probably not so true now as I guess malware written in higher level languages, browser apps etc.

    Still, non-x86 for servers seems like a smart idea to me.

    1. Anonymous Coward
      Anonymous Coward

      Re: Native code good, x86 emulation bad

      "On servers anyway, because non-x86 gave a degree of Windows virus protection"

      Viruses on Windows server have never been a significant issue as 99% of Windows virus attacks require user interaction. There have been a few notable worms but then Linux has also had a few of those. Now that Windows Server is a minimal feature install and is firewalled and locked down by default and also has no GUI by default it has a reasonably good security profile.

      If I was to choose an OS based only on security then it would probably be Open BSD, but that's not usually the only consideration.

      When used as an Internet facing Web server, Windows is actually circa 4 times less likely to be hacked / defaced than an OSS stack on Linux when allowing for market share of servers. To be fair on Linux, a fair proportion of such exploits are due to the stack rather than the OS, but still...

      According to Netcraft ~ 50% of Internet websites now run IIS on Windows so if there was a significant security issue I think we would have seen it by now!

      1. Richard Plinston Silver badge

        Re: Native code good, x86 emulation bad

        > According to Netcraft ~ 50% of Internet websites now run IIS on Windows so if there was a significant security issue I think we would have seen it by now!

        """While more than half of the websites in the survey are using Microsoft web server software, relatively few of these are active sites. Discounting link farms, domain holding pages and other automatically generated content, Microsoft accounts for only 7.3% of all active sites, while Apache leads with 44.9%, and nginx follows with 20.7%. Microsoft's active sites share has never exceeded Apache's, and ever since it peaked at 38% in early 2009, it has experienced a general decline."""

        https://news.netcraft.com/archives/2017/09/11/september-2017-web-server-survey.html

        IIS is the perfect webserver if you have no content and no visitors.

        1. Anonymous Coward
          Anonymous Coward

          Re: Native code good, x86 emulation bad

          """"While more than half of the websites in the survey are using Microsoft web server software, relatively few of these are active sites. "

          Yawn. % of sites was always the figure quoted when Apache was leading. LOL @ strangely how now it's not good enough...

          "IIS is the perfect webserver if you have no content and no visitors."

          Well in a way, yes because it's very secure and you can just leave it alone. If they were easily hackable you know people would be doing it for the bandwidth, the use of the server, and just for the lols..

          However Microsoft IIS also has a 10% share of the top 1 million busiest sites, so it's quite capable scaling if needed. Indeed recent benchmarks show that IIS on Server 2016 significantly outscales Apache on Linux on the same hardware:

          https://www.rootusers.com/windows-iis-speed-test-benchmark-2017-results/

          And that was with the now included AV enabled...

          1. Richard Plinston Silver badge

            Re: Native code good, x86 emulation bad

            > Yawn. % of sites was always the figure quoted when Apache was leading. LOL @ strangely how now it's not good enough...

            It is "not good enough" because Microsoft went on a campaign to wrought the figures by paying hosting sites to put all their parked domains onto Windows servers, probably with Microsoft supplying the server to put these on. This bumped up the "% of sites" to, as you say, 50%, but the vast majority had no content and no traffic.

            > However Microsoft IIS also has a 10% share of the top 1 million busiest sites,

            Down from 20% a decade ago, and falling.

            Microsoft's market share of computers (as distinct from sites) has also halved in the last decade.

      2. Paul

        Re: Native code good, x86 emulation bad

        I'm sure it's the case that its trivially easy to set up an internet facing server that runs Linux and run some web service and then never patch it, that is the problem, and giving inflated scores for Linux attacks.

        You can rent a low end server for just a few dollars a month (see lowendbox blog).

        If you want to get a Windows server and connect it publicly to the internet you'd have to put in a lot of effort, enough perhaps to deter anyone who doesn't know what they're doing.

        1. Anonymous Coward
          Anonymous Coward

          Re: Native code good, x86 emulation bad

          "I'm sure it's the case that its trivially easy to set up an internet facing server that runs Linux and run some web service"

          Clearly you have never tried. It's an order of magnitude easier to install Windows + IIS. And the stats allow for market share, so cost is irrelevant.

          1. Richard Plinston Silver badge

            Re: Native code good, x86 emulation bad

            > It's an order of magnitude easier to install Windows + IIS.

            You think that it is easier than one command ?

            https://www.storagecraft.com/blog/install-lamp-server-linux-mint-18-command/

    2. bombastic bob Silver badge
      Trollface

      Re: Native code good, x86 emulation bad

      might as well do everything in javascript.

      no, wait...

  11. jason 7 Silver badge

    I said this would be...

    ... a load of crap a month ago and got laughed at.

    https://forums.theregister.co.uk/forum/1/2017/10/19/windows_10_on_arm_near_with_mutli_day_battery_life/#c_3321531

    Now the rumours are coming through and suddenly everyone is changing their tune.

    Ah well.

    Told you so.

  12. jelabarre59 Silver badge

    Power

    I still think it would be amusing to see MSWin on Power64le. Might actually get decent MSWin performance when running it on your z10.

    1. Anonymous Coward
      Anonymous Coward

      Re: Power

      "Might actually get decent MSWin performance when running it on your z10."

      Well Windows Server does tend to outperform say Linux in most benchmarks these days. Especially very high end requirements like dedicated low latency interconnects etc. And as far as I know you don't have options like SMB DIrect (SMB over RDMA) on Linux...

      1. Richard Plinston Silver badge

        Re: Power

        > Well Windows Server does tend to outperform say Linux in most benchmarks these days. Especially very high end requirements like dedicated low latency interconnects etc.

        Which is obviously why there are so many supercomputer in the top 500 using Windows, given that interconnects are what they are all about. Oh wait, there are zero since 2015.

        > And as far as I know you don't have options like SMB DIrect (SMB over RDMA) on Linux...

        According to https://en.wikipedia.org/wiki/Samba_(software) SMB 3, which includes SMB over RDMA, was introduced in Samba 4.1 in October 2013.

  13. Tim Seventh

    Should have Done it Years ago

    since the mobile race.

    Windows 7 had xp mode integration for software compatibility to bridge those from windows xp.

    Windows RT should have the x86 emulator for software compatibility to bridge those from x86 windows.

    But since it didn't, no one really came use them.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019