By: Doug S (foo.delete@this.bar.bar), July 4, 2021 5:18 am
Room: Moderated Discussions
Foo_ (foo.delete@this.nomail.com) on July 4, 2021 2:25 am wrote:
> Doug S (foo.delete@this.bar.bar) on July 3, 2021 12:05 pm wrote:
> >
> > The problem with introducing mixed mode support like Microsoft has done is that they will
> > never get rid of it.
>
> Why do you think so? Apparently 16-bit x86 support is being phased out of Windows (it's
> not provided by default anymore in Windows 10). It just took them a long time.
OK so by that timeline then they will drop ARM64EC somewhere around 2055? That's approximately "never" as far as I'm concerned.
>
> > What's the incentive for developers to port the 90% of their application
> > that isn't particularly performance sensitive if they don't have to? Not only is that a handicap
> > that limits the performance of ARM PCs,
>
> Why would it be "a handicap that limits the performance of ARM PCs"
> if we're talking about non-performance sensitive components?
You're assuming that everything performance critical would be ported. If they have third party libraries like Linus indicates, and like the example Michael S gave (IPP) which includes exactly the kind of performance critical stuff which may hurt performance if forced to run via emulation...
> > The reason for the difference has to do with the end goal for each. Microsoft is adding ARM support
> > but has no plans to ever drop x86 support.
>
> Of course they don't. Why would they? Microsoft's business rests firmly on the
> promise of long-term binary compatibility. They aren't going to change that just
> because a couple of geeks on the Internet think it would be better for them.
>
> Microsoft knows their business better than you do. They know the cost of providing a x86 emulation
> layer, and they're able to estimate the benefits more accurately than you do. The main question
> is whether Windows on ARM will ever be successful (but that question doesn't only affect the x86
> emulation effort, it affects the entire - and much larger - Windows on ARM effort).
>
> > There
> > is no guarantee how long Windows/ARM will be supported, so why should developers invest the time?
>
> Depends on the cost and reward of the "investment" perhaps? If your application is performance-sensitive
> *and* if porting to ARM64 is relatively easy (which it should, if you don't have a particularly
> ugly source base), then porting may still be a beneficial investment.
>
> Really, we're not in the 80-90s anymore, when many application developers had a cowboy (or "rock star")
> mentality and strived to exploit every ugly trick they could think of. Development practices have straightened,
> and porting software to another architecture should most of the time be quite easy nowadays.
I don't understand your argument here. First you state "they know the cost of providing an x86 emulation layer", which is irrelevant because they have to provide that regardless of the strategy they adopt, unless that strategy is "Windows/ARM is a completely separate product so only ARM applications will run". Then you argue "porting software to another architecture should most of the time be quite easy".
If it is so easy, why bother with the ARM64EC crutch? The only reason they do that is if "they know their business" better than I and YOU as well, and know that there's a serious lack of financial incentive for porting (as Michael S alluded to in the case of where he works) which means developers want to do as little work as possible even if they even bother to do an ARM port at all.
That lack of financial incentive is the problem with an architecture that's an alternative to the mainstream rather than a migration path. That's the problem with an alternative architecture being offered by a company with a terrible record of long term support of alternative architectures. Which is what I said in my previous post, and which you didn't address at all other than to say "porting should be easy". It doesn't matter how easy it is, if developers don't believe Windows/ARM will exist five years from now.
> Doug S (foo.delete@this.bar.bar) on July 3, 2021 12:05 pm wrote:
> >
> > The problem with introducing mixed mode support like Microsoft has done is that they will
> > never get rid of it.
>
> Why do you think so? Apparently 16-bit x86 support is being phased out of Windows (it's
> not provided by default anymore in Windows 10). It just took them a long time.
OK so by that timeline then they will drop ARM64EC somewhere around 2055? That's approximately "never" as far as I'm concerned.
>
> > What's the incentive for developers to port the 90% of their application
> > that isn't particularly performance sensitive if they don't have to? Not only is that a handicap
> > that limits the performance of ARM PCs,
>
> Why would it be "a handicap that limits the performance of ARM PCs"
> if we're talking about non-performance sensitive components?
You're assuming that everything performance critical would be ported. If they have third party libraries like Linus indicates, and like the example Michael S gave (IPP) which includes exactly the kind of performance critical stuff which may hurt performance if forced to run via emulation...
> > The reason for the difference has to do with the end goal for each. Microsoft is adding ARM support
> > but has no plans to ever drop x86 support.
>
> Of course they don't. Why would they? Microsoft's business rests firmly on the
> promise of long-term binary compatibility. They aren't going to change that just
> because a couple of geeks on the Internet think it would be better for them.
>
> Microsoft knows their business better than you do. They know the cost of providing a x86 emulation
> layer, and they're able to estimate the benefits more accurately than you do. The main question
> is whether Windows on ARM will ever be successful (but that question doesn't only affect the x86
> emulation effort, it affects the entire - and much larger - Windows on ARM effort).
>
> > There
> > is no guarantee how long Windows/ARM will be supported, so why should developers invest the time?
>
> Depends on the cost and reward of the "investment" perhaps? If your application is performance-sensitive
> *and* if porting to ARM64 is relatively easy (which it should, if you don't have a particularly
> ugly source base), then porting may still be a beneficial investment.
>
> Really, we're not in the 80-90s anymore, when many application developers had a cowboy (or "rock star")
> mentality and strived to exploit every ugly trick they could think of. Development practices have straightened,
> and porting software to another architecture should most of the time be quite easy nowadays.
I don't understand your argument here. First you state "they know the cost of providing an x86 emulation layer", which is irrelevant because they have to provide that regardless of the strategy they adopt, unless that strategy is "Windows/ARM is a completely separate product so only ARM applications will run". Then you argue "porting software to another architecture should most of the time be quite easy".
If it is so easy, why bother with the ARM64EC crutch? The only reason they do that is if "they know their business" better than I and YOU as well, and know that there's a serious lack of financial incentive for porting (as Michael S alluded to in the case of where he works) which means developers want to do as little work as possible even if they even bother to do an ARM port at all.
That lack of financial incentive is the problem with an architecture that's an alternative to the mainstream rather than a migration path. That's the problem with an alternative architecture being offered by a company with a terrible record of long term support of alternative architectures. Which is what I said in my previous post, and which you didn't address at all other than to say "porting should be easy". It doesn't matter how easy it is, if developers don't believe Windows/ARM will exist five years from now.