On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:
> I contacted one of the few companies putting out RISC-V dev boards, Sifive, a couple weeks ago with the suggestion of making available a paid RISC-V VPS, and one of their field engineers got back to me last week with a note that they're looking into it.
>
> 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.

I could not agree more - look at Parallella! Their model is the same yet it ultimately failed (unfortunately as I think Exynos is seriously good stuff)! :(

On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:

>
> I don't think there's a "dedicated team" for any platform that D runs on, so we don't have "first class support" for any platform then.

But ARM (Android/iOS) has always been treated worse than a stepchild by D devs. No interest whatsoever, leave it to the LDC guys...

> D is largely a volunteer effort: if that's not enough, maybe D isn't right for you. This isn't Kotlin or Swift, where one of the largest companies in the world puts full-time devs on the language and gives everything away for free because it suits their agenda.
>
> In Apple's case, that means Swift doesn't really support Android and definitely doesn't support Android/AArch64, because putting full-time devs on getting Swift working well with Android doesn't suit their agenda of pushing iOS:

Swift locks you in too much.

> Kotlin is becoming more cross-platform now since google is more cross-platform, but then you're depending on google continually funding development on an OSS project, which they've backed out of before:
>
> https://arstechnica.com/gadgets/2018/07/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/
>
> I don't fault google for making those choices, as nobody has a right to their OSS contributions, but it is something to consider when using any platform, and even more so for an OSS project: who is funding this and why? Will their model be sustainable?
>
> There are no easy answers here: if you want a free-priced, OSS toolchain, you're going to be marching to the beat of someone's drum.

We all understand that. But often you don't get to choose. If the user wants an app for Android/iOS what you're gonna tell him or her? "I'm not marching to the beat of Google's drum."?

Also, having no or no smooth support for something doesn't make the D community "rebels".

> As for ongoing maintenance, Android/ARM was done years ago and hasn't taken much in the way of maintenance to keep most of the stdlib/dmd tests passing, so I don't think that's much of an issue.

Just to make sure it all works. The less work the better.

> btw, it was a thread _you_ started that finally spurred me to begin this Android port five years back, though I'd enquired about and had been considering it earlier:
>
> https://forum.dlang.org/thread/yhulkqvlwnxjklnogmfv@forum.dlang.org

Ha ha! I know and you picked up on it. Thank you very much, it's much appreciated. But look at the date: November 2013 (!) and we're still talking about it while others have overtaken D in this respect. 5 years + the founding of the D Language Foundation. Sometimes it's good to think outside the box a little and see what's going on around you. It's not just fancy ranges and allocators. The software has to actually run somewhere.

On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:
> On Tuesday, 11 September 2018 at 08:34:31 UTC, Chris wrote:
>> [...]
>
> Yes, something like that should be done, but I won't be doing much with dub till next year. If anyone else is interested in doing it earlier, feel free.
>
> [...]

On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:

From one of the articles you linked:

"The Apple Swift compiler has had the ability to compile code for the Android platform for a few years now, but it hasn’t made many friends in the developer community owing to its complexity. Our toolchain was designed to solve this problem by taking the complexity and headaches out of the process, so you can focus on building great apps for your users."

If Android devs have been reluctant to touch Swift owing to its complexity (not the language, the toolchain), do you think they would touch D?

On Monday, 10 September 2018 at 14:00:43 UTC, Iain Buclaw wrote:
> PPC64

Why superscalar is a thing at all? Didn't Itanium prove to be difficult to optimize for?

On Wednesday, 12 September 2018 at 06:41:38 UTC, Gambler wrote:
> On 9/10/2018 9:43 AM, Joakim wrote:
>> Yes, I know, these devices won't replace your quad-core Xeon workstation with 32-64 GBs of RAM anytime soon, but most people don't need anywhere near that level of compute. That's why PC sales keep dropping while mobile sales are now 6-7X that per year:
> I'm all for supporting modern open CPU architectures. At the same time,
> I fear that the specific trend you're describing here (people ditching
> PCs for cellphones/tablets) is effectively a reversal of the PC revolution.
>
> For the last 30+ years people benefited from "trickle down computing". They had access to PCs that were equivalent to cutting edge servers of 6-7 years prior. They had ability to choose their operating system, expand and upgrade their hardware and install any software they wanted.
>
> All of this is breaking down right now.

Yes and no, it is true that that is the way tech  _used_ to diffuse. However, do you know what the largest tech company in the world is right now? It's not IBM, Apple, HP, or Microsoft, ie none of the server or PC companies. It's Apple, which doesn't sell into the server or traditional enterprise markets almost at all and only has 15-20% unit share in the mobile market.

In other words, consumer tech markets are _much_ larger than the server/enterprise markets that used to lead tech R&D, which means consumer tech like mobile is what leads the way now.

As for choosing your own OS, that's still possible, but as always, it can be tough to get drivers for your hardware:

https://together.jolla.com/question/136143/wiki-available-devices-running-sailfish-os/

And if you simply want to tinker with the Android OS on your device, there are many ways to do that:

https://www.xda-developers.com/how-to-install-custom-rom-android/

No need to expand and upgrade your hardware when prices keep dropping in this Darwinian market. There's now a $500 phone with a faster chip than the one I got just 7 months back for $700:

https://m.newegg.com/products/N82E16875220078

As for installing any software you want, Android allows it: it's how I debug the apps I build on my phone or tablet. The iPhone doesn't, but it's a minority of the mobile market.

> Intel got lazy without competition and high-end CPU architectures stagnated. All the cutting-edge computing is done on NVidia cards today. It requires hundreds of gigabytes of RAM, tens of terabytes of data and usage of specialized computing libraries. I very much doubt this will "trickle down" to mobile in foreseeable future. Heck, most developer laptops today have no CUDA capabilities to speak of.

I question the need for such "cutting-edge computing" in the first place, but regardless, it has already moved down to mobile and other edge devices:

https://arstechnica.com/gadgets/2017/10/the-pixel-2-contains-a-custom-google-soc-the-pixel-visual-core/
https://www.theverge.com/2018/7/26/17616140/google-edge-tpu-on-device-ai-machine-learning-devkit

> Moreover, mobile devices are locked down by default and it's no trivial task to break out of those walled gardens. IIRC, Apple has an official policy of not allowing programming tools in their app store. Alan Kay had to personally petition Steve Jobs to allow Scratch to be distributed, so kids could learn programming. I believe the general policy is still in place.

They have their own app for that now:

https://www.apple.com/swift/playgrounds/

> Android is better, but it's still a horror to do real work on, compared to any PC OS. Fine, you rooted it, installed some compilers and so on. How will you share your software with fellow Android users?

You seem to have missed all the posts I've made here before about native Android support for ldc: :) _I have never rooted any of my Android devices_. Compiling D code on most any Android device is as simple as installing an app from the official Play Store and typing a single command, `apt install ldc`:

https://wiki.dlang.org/Build_D_for_Android

The instructions there even show you how to package up an Android GUI app, an apk, on Android itself, by using some other packages available in that Android app.

> In essence, we are seeing the rapid widening of two digital divides. The first one is between users and average developers. The second one is between average developers and researchers at companies like Google. I very much doubt that we will see an equivalent of today's high-end machine learning server on user's desk, let alone in anyone's pocket, within 7 years.

I disagree on both counts. First off, people were running supercomputers and UNIX workstations while you were piddling along on your PC decades ago. That changed nothing about what you were able to learn and accomplish on your PC. In fact, you were probably much better off than they were, as the PC skills you picked up were likely in much more demand than their supercomputing abilities. ;)

It's similar today. Billions of people can now access programming through that open-source Termux app that can be installed on almost any Android device. That's _HUGE_ for the user, and D is one of only about 15 programming languages currently available in that app, and one of only 5 that eventually compile down to native assembly, alongside Vala, Go, C, and C++.

As for machine learning researchers and the like, I think that's way overhyped, as this guy says:

https://blog.piekniewski.info/2018/05/28/ai-winter-is-well-on-its-way/

I'm confident that the app market will continue being much larger than the cloud/research market you're concerned about, though both are due for a shakeout.

> My only hope is that newer AMD processors and popularity of VR rigs may help narrow these divides.

I doubt either of those will matter at all anytime soon.

On Wednesday, 12 September 2018 at 08:51:17 UTC, Chris wrote:
> On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:
>> I don't fault google for making those choices, as nobody has a right to their OSS contributions, but it is something to consider when using any platform, and even more so for an OSS project: who is funding this and why? Will their model be sustainable?
>>
>> There are no easy answers here: if you want a free-priced, OSS toolchain, you're going to be marching to the beat of someone's drum.
>
> We all understand that. But often you don't get to choose. If the user wants an app for Android/iOS what you're gonna tell him or her? "I'm not marching to the beat of Google's drum."?
>
> Also, having no or no smooth support for something doesn't make the D community "rebels".

Heh, that's not what I was saying at all: in fact, my point was that you're still marching to a bunch of random volunteers' drums with D. ;)

And the drumbeat comment referred to toolchains, so I wasn't saying that in regard to D supporting a platform like Android/iOS, only that you should know how they're funded.

>> btw, it was a thread _you_ started that finally spurred me to begin this Android port five years back, though I'd enquired about and had been considering it earlier:
>>
>> https://forum.dlang.org/thread/yhulkqvlwnxjklnogmfv@forum.dlang.org
>
> Ha ha! I know and you picked up on it. Thank you very much, it's much appreciated. But look at the date: November 2013 (!) and we're still talking about it while others have overtaken D in this respect.

Not Swift, ;) at least not from Apple.

> 5 years + the founding of the D Language Foundation. Sometimes it's good to think outside the box a little and see what's going on around you. It's not just fancy ranges and allocators. The software has to actually run somewhere.

Sure, we're both on the same page about the importance of mobile.

On Wednesday, 12 September 2018 at 09:18:46 UTC, Chris wrote:
> From one of the articles you linked:
>
> "The Apple Swift compiler has had the ability to compile code for the Android platform for a few years now, but it hasn’t made many friends in the developer community owing to its complexity. Our toolchain was designed to solve this problem by taking the complexity and headaches out of the process, so you can focus on building great apps for your users."
>
> If Android devs have been reluctant to touch Swift owing to its complexity (not the language, the toolchain), do you think they would touch D?

It depends what they mean by that complexity. The official page on Swift for Android that I linked shows that it takes about the same kind of steps to build apps as with D. But that Medium post you quote now says that they're missing some SwiftFoundation pieces on Android, whereas I suspect much less is missing from the D stdlib on Android. They added a JNI generator for Swift, don't think we have one for D yet. They integrate Swift with Android Studio using a Gradle plugin; I've said I do nothing with IDEs.

So yes, D is missing some of the polish added by that outside developer to Swift on Android, so depending on which of those Android devs need, they may not want to use it. But at least D supports Android/AArch64 now, which even that more polished toolchain from Readdle doesn't.

On Wednesday, 12 September 2018 at 15:38:36 UTC, Joakim wrote:
> the world is right now? It's not IBM, Apple,

Whoops, meant to write Intel here, but wrote Apple again. :D

On 12 September 2018 at 10:46, Dejan Lekic via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 12 September 2018 at 08:09:46 UTC, Joakim wrote:
>>
>> I contacted one of the few companies putting out RISC-V dev boards,
>> Sifive, a couple weeks ago with the suggestion of making available a paid
>> RISC-V VPS, and one of their field engineers got back to me last week with a
>> note that they're looking into it.
>>
>> 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.
>
>
> I could not agree more - look at Parallella! Their model is the same yet it ultimately failed (unfortunately as I think Exynos is seriously good stuff)! :(

I only ever saw Parallella used in the context of a CPU where you offload computation onto, rather than something your system runs directly on-top of.

For this, I assumed their target audience was mainly places that currently use expensive GPUs.

On 12 September 2018 at 10:09, Joakim via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 11 September 2018 at 16:50:33 UTC, Dejan Lekic wrote:
>>
>> On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote:
>>>
>>> LDC recently added a linux/AArch64 CI for both its main branches and
>>> 64-bit ARM, ie AArch64, builds have been put out for both linux and Android.
>>> It does not seem that many are paying attention to this sea change that is
>>> going on with computing though, so let me lay out some evidence. ...
>>
>>
>> I mostly agree with you, Joakim. I own a very nice (but now old) ODROID U2
>> (check the ODROID XU4 or C2!) so ARM support is important for me...
>>
>> Also, check this: https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626
>>
>> HOWEVER, I think Iain is right - PPC64 and RISC-V are becoming more and more popular nowadays and may become more popular than ARM in the future but that future is unclear.
>
>
> If and when they do, I'm sure D and other languages will be ported to them, but right now they're most definitely not.
>
> I know because I actually looked for a RISC-V VPS on which to port ldc and found nothing. Conversely, I was able to rent out an ARM Cubieboard2 remotely four years back when I was first getting ldc going on ARM:
>
> https://forum.dlang.org/post/steigfwkywotxsyppvza@forum.dlang.org
>
> I contacted one of the few companies putting out RISC-V dev boards, Sifive, a couple weeks ago with the suggestion of making available a paid RISC-V VPS, and one of their field engineers got back to me last week with a note that they're looking into it.
>
> 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).

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.

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.

Iain.

On Wednesday, 12 September 2018 at 22:41:31 UTC, Iain Buclaw wrote:
> With one comparison being a high end ARM64 server is no better than a cheap laptop bought 5 years ago.

For single thread performance that's true, but it's not how a server works?

> 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.

Druntime works on riscv?

On 13 September 2018 at 10:11, Kagamin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 12 September 2018 at 22:41:31 UTC, Iain Buclaw wrote:
>>
>> With one comparison being a high end ARM64 server is no better than a cheap laptop bought 5 years ago.
>
>
> For single thread performance that's true, but it's not how a server works?
>

Wait, how do YOU think a server works?

>> 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.
>
>
> Druntime works on riscv?

Yes - on a simulator at least.  Haven't tried running all unittests yet, nor shared library support.  I did run two of the most convuluted tests I can think of after building - runnable/eh.d and runnable/sdtor.d - both pass with flying colours.