Do you need an ARM64 compiler for Windows?

[Brandon Staggs 278]

20 minutes ago, Dalija Prasnikar said:

 

Since there is already plenty of low level RTL code that runs with LLVM based compilers, the only part where those exceptions could cause issues is VCL. I would say that this is probably less of a problem than it may look like on the first sight. 

 

Developing Windows ARM compiler is much simpler than 64-bit IDE

The events of the last six months have certainly changed some of my opinions on this, but I am still trepidatious about an LLVM ARM64 Windows compiler "just working" with code that has been in production for 25 years.

 

And regardless of my concerns about potential issues, I very much want an ARM64 Windows compiler as soon as possible. I'd actually like the option to build x64 with LLVM as well. Whatever issues there are to deal with, such as making sure exception handling works as I expect it to, I'll deal with them.

[Brandon Staggs 278]

18 minutes ago, RonaldK said:

Intel-based applications already run on Windows ARM. I fear that Delphi ARM64 applications are much slower than x64 applications, even though they run in the emulator.

The x64 compiler is no paragon of code output. I think it would be nice to not have to rely on Embarcadero writing its own compilers. Obviously it goes without saying I would hope they configure the toolchain properly for good output, too.

 

20 minutes ago, RonaldK said:

What is the advantage for native ARM64 applications?

Performance and power use. So far the testing of Windows applications on Snapdragon indicates you're going to get the best performance and efficiency with native code, which is exactly what one would expect...

[RonaldK 18]

2 minutes ago, Brandon Staggs said:

Performance and power use. So far the testing of Windows applications on Snapdragon indicates you're going to get the best performance and efficiency with native code, which is exactly what one would expect...

Is this already fixed?
https://quality.embarcadero.com/browse/RSP-17724

[Brandon Staggs 278]

7 minutes ago, RonaldK said:

Is this already fixed?
https://quality.embarcadero.com/browse/RSP-17724

I wouldn't know. I don't build for Linux and I don't work for Embarcadero.

[Dalija Prasnikar 1396]

2 hours ago, Brandon Staggs said:

The events of the last six months have certainly changed some of my opinions on this, but I am still trepidatious about an LLVM ARM64 Windows compiler "just working" with code that has been in production for 25 years.

Just the fact that the code has been working for over 25 years means that it will have very little issues when it comes to exception handling. Only hardware exceptions are the problem, which for VCL means mostly dereferencing nil and dangling pointers and floating point exceptions (which are now masked by default). I doubt that there are many places in VCL that would need code changes for exception handling.

[Rollo62 536]

16 hours ago, Brandon Staggs said:

Right now it's obviously a question of whether you want performance or efficiency.

So you would say Apple M3, M4 is not performant enough against Intel?
You're maybe right in the top 5 positions, but there is also the parameter "Price".
All in all, I would say ARM has the strong ability to overtake all parameters in the near future, while Intel struggels a bit at the moment.

 

Edited October 29 by Rollo62

[RonaldK 18]

15 hours ago, Brandon Staggs said:

I wouldn't know. I don't build for Linux and I don't work for Embarcadero.

I don't think the codegen has improved and so a Delphi x86/x64 program runs faster on a Windows ARM with emulation (Prism) than the same Delphi program with the ARM compiler.
So what's the benefit?

[Lars Fosdal 1792]

20 hours ago, RonaldK said:

fear

uncertainty, doubt

- Is it unthinkable that the codegen would be scheduled for improvements when adding support for Windows for ARM?

 

 

[Brandon Staggs 278]

7 hours ago, Rollo62 said:

So you would say Apple M3, M4 is not performant enough against Intel?
You're maybe right in the top 5 positions, but there is also the parameter "Price".
All in all, I would say ARM has the strong ability to overtake all parameters in the near future, while Intel struggels a bit at the moment.

 

This also depends on application.

 

There is no way I would trade my desktop AMD cpu for Snapdragon. I do not care about power consumption there and there is no comparison on performance.

 

But on a laptop, I am already using Snapdragon and I am pleased with it.

 

I don't know what we're arguing about here. Personally I want the ability to target Arm64 on Windows now that there are seriously good Windows computers using the architecture. 

[Brandon Staggs 278]

7 hours ago, RonaldK said:

I don't think the codegen has improved and so a Delphi x86/x64 program runs faster on a Windows ARM with emulation (Prism) than the same Delphi program with the ARM compiler.
So what's the benefit?

I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet. Ostensibly, the benefit will be not having to rely on a layer of processor architecture emulation.

 

I certainly can't see the benefit of Embarcadero pretending there is no ARM64 Windows executable format and ignoring it altogether. If you decide the x64 output works better you aren't going to be forced to distribute ARM64 binaries.

[RonaldK 18]

5 minutes ago, Brandon Staggs said:

I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet.

Oh wait, you can:
Try native ARM64 application on macOS <-> x86/x64 application on Windows 11 ARM,

on the same Mac machine with Apple-CPU.

 

[Brandon Staggs 278]

14 minutes ago, RonaldK said:

Oh wait, you can:
Try native ARM64 application on macOS <-> x86/x64 application on Windows 11 ARM,

on the same Mac machine with Apple-CPU.

 

To be clear, I do compile MacOS (Arm64) targets. 

 

It seems self-evident to me that the comparison you suggest is invalid.

 

Doesn't make a difference either way; unless Windows on ARM is a passing fad, which I doubt, we need a compiler that can target it.

[RonaldK 18]

16 hours ago, Brandon Staggs said:

 

It seems self-evident to me that the comparison you suggest is invalid.

You can get a good impression of how good the x86/x64 compiler is

or how bad the ARM64 compiler.

Edited October 30 by RonaldK

[Brian Evans 105]

34 minutes ago, Brandon Staggs said:

I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet. Ostensibly, the benefit will be not having to rely on a layer of processor architecture emulation.

 

I certainly can't see the benefit of Embarcadero pretending there is no ARM64 Windows executable format and ignoring it altogether. If you decide the x64 output works better you aren't going to be forced to distribute ARM64 binaries.

There is not one executable format but two: ARM64 and ARM64EC (ARM64X PE files) on Windows 11 ARM64. The latter makes moving to ARM incrementally easier but does complicate things for third party compiler makers like Embarcadero. Bit a shit show from Microsoft over the last decade - first Windows on ARM had a new API only, then Win32 / x86 emulation and now finally a way to mix x86 and specially built ARM binaries. 

 

I think ARM will fall behind as a platform because it is fragmented and siloed. Remember how M68000 got beat by x86 - thanks to DOS and then Windows becoming a widely used platform x86 got an order of magnitude more $$$ invested into the platform. ARM just doesn't have the $$$ getting invested into platform improvements that x86 does and some of the improvements don't go to all users - like x86 emulation help on Apple M1 CPUs not available elsewhere. Contrast that to AMD's Ryzen/EPYC all using the same CPU tiles - the improvements from investment hit everything from Valve Steam Deck handhelds, Threadripper PRO workstations and the FRONTIER supercomputer. 

[Stefan Glienke 2002]

8 hours ago, Lars Fosdal said:

Is it unthinkable that the codegen would be scheduled for improvements when adding support for Windows for ARM?

Yes, pretty much - we all know they first ship a half-baked feature to generate marketing hype and then spend the next decade tinkering around the edges to make it work while representatives are telling us "eh, its complicated"

[Lajos Juhász 293]

9 hours ago, Stefan Glienke said:

Yes, pretty much - we all know they first ship a half-baked feature to generate marketing hype and then spend the next decade tinkering around the edges to make it work while representatives are telling us "eh, its complicated"

 

I believed it is a different aproach. They give to us something that compiles and is working. Then based on user review and bug reports they are accepting suggestions how to make it work.  If everything else fail they buy some source code to make things working again.