On Wednesday, 12 September 2018 at 22:41:31 UTC, Iain Buclaw
wrote:
On 12 September 2018 at 10:09, Joakim via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
I think their model of having an open ISA with proprietary
extensions will inevitably win out for hardware, just as a
similar model has basically won already for software, but that
doesn't mean that RISC-V will be the one to do it. Someone
else might execute that model better.
POWER9 has been making some headway, for instance finally they
have a sensible real type (IEEE Quadruple). Though the
developers working on glibc support seem to be making a
shambles of it, where they want to support both new and old
long double types at the same time at run-time! It seems that
no one thought about Fortran, Ada, or D when it came to long
double support in the C runtime library *sigh*.
For us, I think we can choose to ignore the old IBM 128-bit
float, and so remove any supporting code from our library,
focusing instead only on completing IEEE 128-bit float support
(LDC, upstream your local patches before i start naming and
shaming you).
All the pulls linked from that AArch64 tracker issue above were
submitted upstream first before merging into the ldc repo. Only
one patch that I know of hasn't been merged upstream yet: my
commit to add IEEE Quadruple support to core.internal.convert,
only because I want to add another Android commit to that pull
soon, but the patch is available in the open druntime pulls.
If you know of some other patches that need to be upstreamed, let
us know, AFAIK they were all upstreamed first.
ARM seems to be taking RISC-V seriously at least (this site was
taken down after a couple days if I understand right:
http://archive.fo/SkiH0). There is currently a lot of
investment going into ARM64 in the server space right now, but
signals I'm getting from people working on those projects are
that it just doesn't hold water. With one comparison being a
high end ARM64 server is no better than a cheap laptop bought 5
years ago.
As Kagamin says, it depends on how many cores you're using and
what benchmark you run, but most of the time, that's not true at
all:
https://blog.cloudflare.com/arm-takes-wing/
And ARM does it with much less electric power used, as shown in
that last graph, which you have to take into account when looking
at the total costs. The ARM blog post I linked earlier in this
thread shows they've gone ahead with using ARM too.
RISC-V got accepted into gcc-7, and runtime made it into glibc
2.27, there's certainly a lot effort being pushed for it. They
have excellent simulator support on qemu, porting druntime only
took two days. Patches for RISCV64 will come soon, probably
with some de-duplication of large blocks.
Great, but it's still in very nascent stages, with linux only
running on it this year. I thought about using Qemu but figured
the slowness and possible hardware compatibility issues weren't
worth it.
I hope some open arch like these takes off sometime soon, as I
don't like an ARM monopoly much better than the previous Intel
one, but it's going to take awhile for POWER/RISC-V to get
anywhere close.
