On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
> Note there's similar move by Microsoft to get their system to
> work on Arm chips.

Windows ARM laptops have been around for some time, with such enormous success that many people haven't even heard or already forgotten about it. E.g., https://www.techspot.com/review/1599-windows-on-arm-performance/.

Providing (software) x86 emulation (32-bit only IIRC) on an already slow CPU wasn't a great idea. Apple will probably just hope/try to enforce that the publishers port and recompile all their packages (incl. any x86-specific optimizations), so that the code is at least native.

They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.

On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
>
> They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.

For the D users targetting macOS:
A future plan for package "intel-intrinsics" is to translate the intrinsics to Neon so that stuff is at least a bit optimized on ARM also.

On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
> On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
>> Note there's similar move by Microsoft to get their system to
>> work on Arm chips.
>
> Windows ARM laptops have been around for some time, with such enormous success that many people haven't even heard or already forgotten about it. E.g., https://www.techspot.com/review/1599-windows-on-arm-performance/.
>
> Providing (software) x86 emulation (32-bit only IIRC) on an already slow CPU wasn't a great idea. Apple will probably just hope/try to enforce that the publishers port and recompile all their packages (incl. any x86-specific optimizations), so that the code is at least native.
>
> They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.

Yet, this came out just yesterday,

"Announcing OpenJDK for Windows 10 on ARM"

https://devblogs.microsoft.com/java/announcing-openjdk-windows-arm/

When companies have deep pockets, things eventually happen as long as there is internal political support to keep going at it.

On Thursday, 25 June 2020 at 05:53:18 UTC, Paulo Pinto wrote:

> When companies have deep pockets, things eventually happen as long as there is internal political support to keep going at it.

+1000

On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
> [...]
> PC was the only compelling target for Intel/Amd targets but now its changing.

This is more than just PC though. ARM chips cover virtually everything, from small SBCs like the Raspberry Pi, to high end servers like the Graviton. Also, with things like postmarketOS[1] becoming more prominent, I think D's support for ARM and other non-x86 architectures will become more and more important in the coming years.

Also an interesting anecdote:

Many people often think ARM cores are small and slow compared to x86, but this simply hasn't been true for a very long time in *many* use cases. Consider for e.g. compiling a large C/C++ codebase. Compiling mesa on my i5 4258u (28W part) takes more than 30minutes. I have 8GB of ram and a fast SSD too. Compare that with my phone which comes with a low end 8xA53 cores, and compiles mesa in 10 minutes!

And its no longer just areas which can be heavily parallelised, like code compiling. Apple's latest cores are as fast or faster than x86 chips in a lot of tasks[2].

[1]: https://postmarketos.org/ based on Alpine linux, which just recently added official D support
[2]: https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/2

On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:

> To clarify and avoid confusion I see absolutely no reason anyone would waste this huge effort of time into getting DMD to work on ARM as there are two superior and working compiler backends and thus this won't be happening.
>
> So yes you'll have to move away from DMD to LDC or GDC, but that shouldn't be a concern to anyone as even today with the amazing LDC team there's absolutely no reason to use DMD either. In fact I personally believe using DMD for production is irresponsible and at the very least should be strongly discouraged as mwe can't seem to convince the DFL/Walter to drop the DMD backend for obvious reasons.
>
> Tl;Dr: it's just yet another nail in the coffin against DMD ...

However, this will seriously interrupt the tool chain / development workflow I'd imagine. You'd better start working on the toolchain so that basic D development remains as simple as downloading DMD and typing "$ dmd ..." in the CLI. I don't know how dvm is now, but it used to only support dmd, and dvm is a valuable tool.

Sorry lads, but it was foreseeable that neglecting ARM support for so long would come back to bite you one day.

On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:

> So yes you'll have to move away from DMD to LDC or GDC, but that shouldn't be a concern to anyone as even today with the amazing LDC team there's absolutely no reason to use DMD either. In fact I personally believe using DMD for production is irresponsible and at the very least should be strongly discouraged as mwe can't seem to convince the DFL/Walter to drop the DMD backend for obvious reasons.

Every time I've tried to move to LDC, I've ended up using DMD again. It just gets annoying using a slow compiler with my workflow, which is heavy on recompilation. Every so often LDC can be a fair amount slower than DMD. I'm rarely able to get better than a 20% improvement using LDC. Production and development are both important. Until LDC can match DMD's compilation speed, there's a very good argument in favor of having DMD around. (That doesn't mean it's worthwhile to have an ARM DMD compiler, but you're making the stronger statement that DMD doesn't provide any value in any circumstances.)

On Thursday, 25 June 2020 at 09:45:40 UTC, Chris wrote:

> I don't know how dvm is now, but it used to only support dmd, and dvm is a valuable tool.

I guess now is the time to start that full rewrite and start adding support for LDC, which I've postponed waaayy too long.

--
/Jacob Carlborg

On Thursday, 25 June 2020 at 10:10:43 UTC, bachmeier wrote:
> On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:
>
>> So yes you'll have to move away from DMD to LDC or GDC, but that shouldn't be a concern to anyone as even today with the amazing LDC team there's absolutely no reason to use DMD either. In fact I personally believe using DMD for production is irresponsible and at the very least should be strongly discouraged as mwe can't seem to convince the DFL/Walter to drop the DMD backend for obvious reasons.
>
> Every time I've tried to move to LDC, I've ended up using DMD again. It just gets annoying using a slow compiler with my workflow, which is heavy on recompilation. Every so often LDC can be a fair amount slower than DMD. I'm rarely able to get better than a 20% improvement using LDC. Production and development are both important. Until LDC can match DMD's compilation speed, there's a very good argument in favor of having DMD around. (That doesn't mean it's worthwhile to have an ARM DMD compiler, but you're making the stronger statement that DMD doesn't provide any value in any circumstances.)


I actually don't get why he'll consider the ARM thing confusion. You might not like that its happening but as we stand now, almost every new user starts with DMD and almost everyone uses DMD for fast prototyping. It's frustrating without it.

So DMD plays a key role than you may think. And it should be ready for ARM. This doesn't just affect DMD but most currently software stack and OSes need to start thinking about Arm.


But eventually, say 3-5yrs from now, it can't ignore ARM and still stay the default compiler.

On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
> Windows ARM laptops have been around for some time, with such enormous success that many people haven't even heard or already forgotten about it. E.g., https://www.techspot.com/review/1599-windows-on-arm-performance/

Last I checked windows on arm was completely locked down like ios. Microsoft like Apple wants to be alone in its ecosystem.

> They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.

The reviewer conveniently forgot to add that only Celeron can realistically fit in a notebook, anything more powerful will simply melt under your fingers, because Intel games TDP numbers to death for the sake of competition.