digitalmars.D - Apple is officially moving away from Intel to a custom Arm chip
- aberba (5/5) Jun 24 2020 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-ho...
- Steven Schveighoffer (9/18) Jun 24 2020 I was wondering about this. DMD I think only supports Intel, right? Are
- aberba (9/29) Jun 24 2020 They're saying the transition will take two yrs. Seems they're
- Seb (15/35) Jun 24 2020 There are _zero_ plans to make DMD work on ARM architectures.
- H. S. Teoh (19/35) Jun 24 2020 Why even bother, when LDC/GDC already support ARM (and have been for a
- Meta (5/22) Jun 24 2020 I somewhat agree, but if we look at the lengths that the Rust
- Chris (9/21) Jun 25 2020 However, this will seriously interrupt the tool chain /
- Jacob Carlborg (5/7) Jun 25 2020 I guess now is the time to start that full rewrite and start
- bachmeier (11/18) Jun 25 2020 Every time I've tried to move to LDC, I've ended up using DMD
- aberba (10/28) Jun 25 2020 I actually don't get why he'll consider the ARM thing confusion.
- solidstate1991 (8/10) Jul 01 2020 I personally had, but I quickly gave up due to the massive amount
- Iain Buclaw (6/20) Jun 24 2020 GCC still only supports powerpc, i386, or x86_64 darwin. I
- Steven Schveighoffer (3/25) Jun 24 2020 Surely you mean GDC, not GCC?
- Iain Buclaw (6/33) Jun 24 2020 GDC only enforces that language semantics are adhered to. It's
- Steven Schveighoffer (4/18) Jun 24 2020 Sorry, I think I was confused, I thought you meant that GCC cannot
- kinke (15/17) Jun 24 2020 Windows ARM laptops have been around for some time, with such
- Guillaume Piolat (5/10) Jun 24 2020 For the D users targetting macOS:
- Paulo Pinto (6/23) Jun 24 2020 Yet, this came out just yesterday,
- Paolo Invernizzi (2/4) Jun 25 2020 +1000
- Kagamin (7/16) Jun 25 2020 Last I checked windows on arm was completely locked down like
- Kagamin (4/5) Jun 25 2020 Also it's another nonintuitive benchmark: Celeron is twice as
- Uknown (22/25) Jun 25 2020 This is more than just PC though. ARM chips cover virtually
- Walter Bright (4/5) Jun 25 2020 Search for "arm computer" on newegg.com:
- Nils Lankila (5/11) Jun 25 2020 ⥀.⥀
- aberba (2/8) Jun 26 2020 Just did. Don't get your point.
- Chris (15/26) Jun 26 2020 ARM is both a threat and a _chance_ for D.
- Adam D. Ruppe (7/9) Jun 26 2020 D just works on plenty of arm devices, including compilers in the
- JN (5/14) Jun 26 2020 Is there a guide for how to create a binary working on Raspberry
- Chris (8/25) Jun 26 2020 There you go. That was exactly my point. There's a difference
- Adam D. Ruppe (6/9) Jun 26 2020 Well, cross-compiling takes a few extra steps (one of which (the
- Mike James (4/13) Jun 26 2020 Or maybe we need something like this...
- John Colvin (8/34) Jun 26 2020 ARM that you need to cross-compile to is old news (and D hasn't
- Adam D. Ruppe (20/22) Jun 26 2020 I have never actually tried it, but a process similar to how the
- Chris (10/32) Jun 26 2020 Sounds like fun! An it's been like this for years. Well, water,
- H. S. Teoh (14/24) Jun 26 2020 [...]
- Paolo Invernizzi (4/19) Jun 26 2020 +1 also for me ...
- Jacob Carlborg (5/28) Jun 26 2020 I've been thinking about writing such a tool for some time now. Just too...
- H. S. Teoh (18/21) Jun 26 2020 [...]
- kinke (24/38) Jun 26 2020 The linker would be the simple part; LLD isn't ready for macOS
- Adam D. Ruppe (7/12) Jun 26 2020 Yeah, it shouldn't be too hard to do. Maybe I'll look at doing it
- Walter Bright (4/15) Jun 26 2020 Not a single computer powered by an ARM CPU shows up.
- Adam D. Ruppe (5/6) Jun 26 2020 Maybe that's just a bad search term cuz there's plenty of arm
- Walter Bright (4/10) Jun 26 2020 Search on "desktop computer". On the left, you'll find a CPU menu. No AR...
- Adam D. Ruppe (19/21) Jun 26 2020 Yeah, ARM's primary competitive advantage over x86 is lower power
- norm (33/55) Jul 01 2020 ARM is everywhere, the entire computer industry and internet
- rikki cattermole (3/3) Jun 26 2020 I think NVIDIA Jetson series might be the only big name boards you can
- Paolo Invernizzi (4/7) Jun 26 2020 D code is alive and kicking inside a Jetson TX2 for quite a long
- rikki cattermole (4/13) Jun 26 2020 Neat!
- Paolo Invernizzi (6/20) Jun 26 2020 The bad things around big medical companies is that they tend to
- rikki cattermole (6/12) Jun 26 2020 Strip out all the medical bits and with just that, could you make a demo...
- Paolo Invernizzi (5/17) Jun 26 2020 Oh, but there's really nothing special about it: D "just works".
- rikki cattermole (3/14) Jun 27 2020 I have never done anything like this, so to me this is really cool to
- Walter Bright (3/6) Jun 27 2020 Yes, please. The D Foundation will also pay for articles accepted for
- Paolo Invernizzi (3/9) Jun 29 2020 Thanks for the encouragement Walter, but I'm a bad and boring
- Chris (20/36) Jun 27 2020 Sorry, but this is a D typical way of answering to such issues.
- Seiji Emery (5/21) Jun 30 2020 apple is / will be shipping $500 dev kits w/ an A10z; might be
- Seiji Emery (32/32) Jun 30 2020 addendum:
- Paolo Invernizzi (15/37) Jul 01 2020 Nvidia is selling pretty popular solutions based on ARM and
- Yatheendra (10/10) Jul 01 2020 Hardware: if IO speeds matter, ASUS has Tinkerboards with
- Yatheendra (5/15) Jul 01 2020 Also, if developing for the host processor on FPGA's could be of
- rikki cattermole (3/4) Jul 01 2020 ldc and gdc are a thing.
- bachmeier (3/8) Jul 01 2020 One might not think so if reading this forum. There are enough
- Yatheendra (6/17) Jul 01 2020 If dmd and its scripting-like development cycle speed stops being
- Steven Schveighoffer (10/27) Jul 01 2020 It may not be a dismissable problem, but it's also not someone anyone
- IGotD- (19/24) Jul 01 2020 It's inevitable that backends using LLVM or GCC will take over.
- Yatheendra (11/11) Jul 01 2020 Yes, ideally a compiler shouldn't need to worry about a backend
- aberba (10/14) Jul 01 2020 Can this be done. Is so, then there wouldn't be much need for DMD
- rikki cattermole (8/25) Jul 01 2020 On Windows LDC and DMD should have the same out of the box experience
- aberba (4/32) Jul 02 2020 For your information, using a deb is actually more simple. It all
- Walter Bright (6/10) Jul 02 2020 I'm pretty sure that 3/4 of the backend can be used pretty much as-is. T...
- Steven Schveighoffer (4/17) Jul 02 2020 Well, as I said, it's you who probably has to do it, so if you want to
- bachmeier (15/21) Jul 01 2020 DMD brings a lot of value with its fast compilation speed. I
- Martin Tschierschke (10/14) Jul 01 2020 What do you mean by "no precompiled LDC?"
- Paolo Invernizzi (6/22) Jul 01 2020 Cool, (a little outdated) but cool!
- aberba (6/32) Jul 01 2020 There's not enough awareness of some of these things.
- Walter Bright (5/24) Jul 02 2020 Clearly, someone needs to write a D blog article explaining how to get a...
- Adam D. Ruppe (11/14) Jul 02 2020 apt install gdc
- JN (2/9) Jul 02 2020 How about on Windows? I guess that might be tricky.
- Adam D. Ruppe (11/12) Jul 02 2020 So that is developing for the pi on the pi itself.
- Walter Bright (3/22) Jul 02 2020 Posting in the n.g. only reaches people already using D. The point of th...
- Walter Bright (10/15) Jul 02 2020 If that's not incentive enough, consider that I know programmers with in...
- aberba (5/11) Jul 02 2020 Its very tricky when dealing with the D folks. 😂 Sometimes its
- Martin Tschierschke (23/50) Jul 03 2020 Beside having two raspberry pi (3B+ and 4) one at home and one at
- Jacob Carlborg (12/13) Jul 01 2020 If we're talking specifically about supporting the new Apple Silicon (as...
- Jacob Carlborg (4/8) Jul 01 2020 No you won't. You need to return it.
- Martin Tschierschke (11/17) Jun 26 2020 :-)
- Walter Bright (2/7) Jun 25 2020 There goes my weekend.
- solidstate1991 (16/22) Jul 01 2020 I'm quite skeptical about how big of an impact it'll have.
- Guillaume Piolat (9/11) Jul 02 2020 Hello,
https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.
Jun 24 2020
On 6/24/20 7:21 AM, aberba wrote:https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-int l-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future? I've used a mac since 2011, and I'm probably going to buy an Intel macbook this year before they are discontinued (my current one is from 2014), just to give myself more time to deal with it. I'm curious to see how this will affect the Mac ecosystem. -Steve
Jun 24 2020
On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:On 6/24/20 7:21 AM, aberba wrote:They're saying the transition will take two yrs. Seems they're really serious about the move to Arm. Two yrs to get DMD to work on Arm. By then, there'll be dozens of other Windows PC's doing that.https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?I've used a mac since 2011, and I'm probably going to buy an Intel macbook this year before they are discontinued (my current one is from 2014), just to give myself more time to deal with it. I'm curious to see how this will affect the Mac ecosystem. -SteveI think others will join Apple in this move. Performance + power efficiency. Power efficiency more importantly as stated by Apple 🍎.
Jun 24 2020
On Wednesday, 24 June 2020 at 14:54:16 UTC, aberba wrote:On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:There are _zero_ plans to make DMD work on ARM architectures. There are so many other actually impactful things to do ;-)On 6/24/20 7:21 AM, aberba wrote:https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?They're saying the transition will take two yrs. Seems they're really serious about the move to Arm. Two yrs to get DMD to work on Arm.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 ...
Jun 24 2020
On Wed, Jun 24, 2020 at 04:27:27PM +0000, Seb via Digitalmars-d wrote:On Wednesday, 24 June 2020 at 14:54:16 UTC, aberba wrote:[...]Why even bother, when LDC/GDC already support ARM (and have been for a while now)?They're saying the transition will take two yrs. Seems they're really serious about the move to Arm. Two yrs to get DMD to work on Arm.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.Exactly.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 ...To be fair, DMD does have amazingly fast compile times, which is very useful during development -- a fast turnaround *really* helps boost productivity during the code-compile-debug cycle. I still use DMD for development of isolated modules / subsets of dependent modules because of this. However, for production code, yeah, LDC is my first choice. I'd still use DMD for non-critical code (if only due to pure laziness), like script-like programs and small utilities where program startup time dominates execution time. But for anything that's even remotely performance-sensitive, I'd reach straight for LDC and not cast another glance at DMD. T -- Obviously, some things aren't very obvious.
Jun 24 2020
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:There are _zero_ plans to make DMD work on ARM architectures. There are so many other actually impactful things to do ;-)I somewhat agree, but if we look at the lengths that the Rust project has gone to to optimize compile times (and people still complain often about them), we should not completely discount the advantage that dmd offers.They're saying the transition will take two yrs. Seems they're really serious about the move to Arm. Two yrs to get DMD to work on Arm.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 ...
Jun 24 2020
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.
Jun 25 2020
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
Jun 25 2020
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.)
Jun 25 2020
On Thursday, 25 June 2020 at 10:10:43 UTC, bachmeier wrote:On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote: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.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.)
Jun 25 2020
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:There are _zero_ plans to make DMD work on ARM architectures. There are so many other actually impactful things to do ;-)I personally had, but I quickly gave up due to the massive amount of work it would have taken, alongside with having less experience with coding. Supposedly it wouldn't be too hard to modify the backend, and now that it's also in D it would be much easier. I personally don't have any will to do as such, and I would like to work on my own projects instead, like the BASIC interpreter I started to design.
Jul 01 2020
On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:On 6/24/20 7:21 AM, aberba wrote:GCC still only supports powerpc, i386, or x86_64 darwin. I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
Jun 24 2020
On 6/24/20 12:40 PM, Iain Buclaw wrote:On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:Surely you mean GDC, not GCC? -SteveOn 6/24/20 7:21 AM, aberba wrote:GCC still only supports powerpc, i386, or x86_64 darwin. I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-int l-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
Jun 24 2020
On Wednesday, 24 June 2020 at 17:19:00 UTC, Steven Schveighoffer wrote:On 6/24/20 12:40 PM, Iain Buclaw wrote:GDC only enforces that language semantics are adhered to. It's GCC (back-end) that takes care of the target support. I imagine library support in druntime should mostly be there, as LDC already has LLVM support for arm-darwin.On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:Surely you mean GDC, not GCC?On 6/24/20 7:21 AM, aberba wrote:GCC still only supports powerpc, i386, or x86_64 darwin. I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
Jun 24 2020
On 6/24/20 4:16 PM, Iain Buclaw wrote:On Wednesday, 24 June 2020 at 17:19:00 UTC, Steven Schveighoffer wrote:Sorry, I think I was confused, I thought you meant that GCC cannot target ARM, but I think now you mean ARM on darwin? -SteveOn 6/24/20 12:40 PM, Iain Buclaw wrote:GDC only enforces that language semantics are adhered to. It's GCC (back-end) that takes care of the target support. I imagine library support in druntime should mostly be there, as LDC already has LLVM support for arm-darwin.GCC still only supports powerpc, i386, or x86_64 darwin. I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0Surely you mean GDC, not GCC?
Jun 24 2020
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.
Jun 24 2020
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.
Jun 24 2020
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote: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.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.
Jun 24 2020
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
Jun 25 2020
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.
Jun 25 2020
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:https://www.techspot.com/review/1599-windows-on-arm-performance/Also it's another nonintuitive benchmark: Celeron is twice as fast as emulation - dire result for emulation, i7 is twice as fast as Celeron - Celeron is fine.
Jun 25 2020
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
Jun 25 2020
On 6/24/2020 4:21 AM, aberba wrote:PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 25 2020
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:On 6/24/2020 4:21 AM, aberba wrote:⥀.⥀ yeah but at the same time this shop sells lighters in the "stop smoking aids" section: https://www.newegg.com/p/0JX-0038-000K0PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 25 2020
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:On 6/24/2020 4:21 AM, aberba wrote:Just did. Don't get your point.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 26 2020
On Friday, 26 June 2020 at 09:18:04 UTC, aberba wrote:On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:ARM is both a threat and a _chance_ for D. Ignore it and D will finally disappear, development will become a chore or just impossible. Embrace it and it will open a new world for D. But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow"). And do it now with a dedicated developer team that works only on this. Maybe use the funds you had allocated for DConf? std.fancy.allocator can wait. If you start again with "Anyone can step up and become a champion of ARM", then you're doomed and D will be history in 2-5 years. Seriously, this is not about CS theory and experimentation. This is serious, especially for all the companies that use D. There's no software without hardware. If you don't act now, this thread will be the one that announced the end of D.On 6/24/2020 4:21 AM, aberba wrote:Just did. Don't get your point.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 26 2020
On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow").D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Jun 26 2020
On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow").D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Jun 26 2020
On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important. You shouldn't have to think about things like that (it's 2020). If you need hot water for your tea you use an electric kettle or a cooker. You shouldn't have to go and collect fire wood, go to the well to fetch water, light the fire and so on.On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow").D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Jun 26 2020
On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important.Well, cross-compiling takes a few extra steps (one of which (the config file) could be eliminated and one (the lib download) could be automated). But if building on the device itself it really is "just press enter". Even this is a lot nicer than it was just one year ago btw.
Jun 26 2020
On Friday, 26 June 2020 at 15:04:11 UTC, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:Or maybe we need something like this... https://wiki.lazarus.freepascal.org/fpcupdeluxe -=mike=-There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important.Well, cross-compiling takes a few extra steps (one of which (the config file) could be eliminated and one (the lib download) could be automated). But if building on the device itself it really is "just press enter". Even this is a lot nicer than it was just one year ago btw.
Jun 26 2020
On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:ARM that you need to cross-compile to is old news (and D hasn't done a great job making that super-easy, for sure). Today/tomorrow's shift is about ARM that you develop *on*. So I'm not sure the current state of affairs (download the compiler on the target platform and it just works) is a disaster. Cross-compilation should be easier though, of course. Maybe you could help the LDC guys out there?On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important. You shouldn't have to think about things like that (it's 2020). If you need hot water for your tea you use an electric kettle or a cooker. You shouldn't have to go and collect fire wood, go to the well to fetch water, light the fire and so on.On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow").D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Jun 26 2020
On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:Is there a guide for how to create a binary working on Raspberry Pi from Windows?I have never actually tried it, but a process similar to how the android cross compiles work should do this as well. 1) get your Windows ldc set up 2) grab the arm-linux ldc package as well. 3) change your ldc.conf to use the libraries from the arm-linux package when targeting arm-linux 4) Compile with the argument to ldc `-mtriple arm-unknown-linux-gnueabi` or `-mtriple aarch64-unknown-linux-gnu` (32 vs 64 bit target) and you should be all set. (note you just use your normal Windows ldc, all that changes is this -mtriple argument to change the target. Or if compiling with dub, it is `dub -a platform_specifier_here`.) Step 3 is the relatively painful one, for android, i made a program to do it automatically https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232 But we should lobby the ldc upstream to just include all the configs out of the box on all systems. Maybe the libraries are a separate download, but no reason not to put the config in so it just works out of the box for cross compile too.
Jun 26 2020
On Friday, 26 June 2020 at 14:02:05 UTC, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:Sounds like fun! An it's been like this for years. Well, water, firewood, stick, stones, sparks...The D community should think outside the hacker box. Also, the point that has been raised remains. DMD is a good dev tool. LDC would be fatal for your average debug-run cycles. But DMD for ARM will probably not happen, realistically seen. Apart from that it's important that ARM becomes a first-class citizen in the D world. It is important and you won't be able to put it on the long finger for ever.Is there a guide for how to create a binary working on Raspberry Pi from Windows?I have never actually tried it, but a process similar to how the android cross compiles work should do this as well. 1) get your Windows ldc set up 2) grab the arm-linux ldc package as well. 3) change your ldc.conf to use the libraries from the arm-linux package when targeting arm-linux 4) Compile with the argument to ldc `-mtriple arm-unknown-linux-gnueabi` or `-mtriple aarch64-unknown-linux-gnu` (32 vs 64 bit target) and you should be all set. (note you just use your normal Windows ldc, all that changes is this -mtriple argument to change the target. Or if compiling with dub, it is `dub -a platform_specifier_here`.) Step 3 is the relatively painful one, for android, i made a program to do it automatically https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232 But we should lobby the ldc upstream to just include all the configs out of the box on all systems. Maybe the libraries are a separate download, but no reason not to put the config in so it just works out of the box for cross compile too.
Jun 26 2020
On Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]3) change your ldc.conf to use the libraries from the arm-linux package when targeting arm-linux[...]Step 3 is the relatively painful one, for android, i made a program to do it automatically https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232 But we should lobby the ldc upstream to just include all the configs out of the box on all systems. Maybe the libraries are a separate download, but no reason not to put the config in so it just works out of the box for cross compile too.+1. It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries. Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case. If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Jun 26 2020
On Friday, 26 June 2020 at 16:03:32 UTC, H. S. Teoh wrote:On Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]+1 also for me ... ... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...[...][...][...]+1. It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries. Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case. If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T
Jun 26 2020
On 2020-06-26 18:12, Paolo Invernizzi wrote:On Friday, 26 June 2020 at 16:03:32 UTC, H. S. Teoh wrote:I've been thinking about writing such a tool for some time now. Just too much other things to do. -- /Jacob CarlborgOn Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote: [...]+1 also for me ... ... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...[...][...][...]+1. It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries. Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case. If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T
Jun 26 2020
On 2020-06-26 18:12, Paolo Invernizzi wrote:[...][...] Y'know what would be a total killer combo? An all-in-one LDC package that contains everything you need to cross compile from any platform to any other platform. Including full linkers and/or system libraries necessary to generate fully-runnable executables (this point is important, because e.g. I can't cross-compile from Linux to MacOS without separately installing a MacOS dev environment, because LDC doesn't come with a linker for that, unlike LDC-windows). Think about it. Install a single package on any OS, and you can instantly cross-compile to all supported LDC targets just by specifying the right -m triple without needing to install/configure anything else. Build your code for all targeted platforms all in one go, without needing to fuss and muss with low-level config file tweaking and manually installing stuff. *That* would be a total killer combo for D. T -- People walk. Computers run.... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...
Jun 26 2020
On Friday, 26 June 2020 at 17:54:08 UTC, H. S. Teoh wrote:The linker would be the simple part; LLD isn't ready for macOS yet though, most likely because Apple prefers a totally closed ecosystem with everything under their control. But it's being worked on. Redistributing their libraries is probably much harder, I doubt they'll allow that, just like Microsoft doesn't allow that. The MinGW-based libs shipped with DMD and LDC, to provide the out-of-the-box experience for Windows targets, have been *a lot* of work from Rainer's and my side (we're talking unpaid man-weeks). Some years ago, I've posted an unfinished Dockerfile going into this direction, merging the available prebuilt LDC packages to a fat Docker image. No feedback at all IIRC. Wrt. automating the last mile (actually, the last few inches), setting up ldc2.conf, I've repeatedly stated that generalizing Adam's little Android tool would clearly be my choice. Sebastian Koppe promised to do that, but he's probably quite busy at the moment. Anyone can do that though, it's absolutely no rocket science, and if help is needed, don't hesitate to ask us LDC people. But as long as people prefer to hang out in the forum instead of getting actual stuff done in form of contributing code, nothing will improve.On 2020-06-26 18:12, Paolo Invernizzi wrote:[...][...] Y'know what would be a total killer combo? An all-in-one LDC package that contains everything you need to cross compile from any platform to any other platform. Including full linkers and/or system libraries necessary to generate fully-runnable executables (this point is important, because e.g. I can't cross-compile from Linux to MacOS without separately installing a MacOS dev environment, because LDC doesn't come with a linker for that, unlike LDC-windows).... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...
Jun 26 2020
On Friday, 26 June 2020 at 18:28:48 UTC, kinke wrote:Wrt. automating the last mile (actually, the last few inches), setting up ldc2.conf, I've repeatedly stated that generalizing Adam's little Android tool would clearly be my choice. Sebastian Koppe promised to do that, but he's probably quite busy at the moment.Yeah, it shouldn't be too hard to do. Maybe I'll look at doing it myself, imagine dub run xc-setup could do a setup wizard kind of thing that does the rest. Then I think all we'd want from you is prolly just a backlink on the readme or whatever.
Jun 26 2020
On Friday, 26 June 2020 at 19:18:44 UTC, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 18:28:48 UTC, kinke wrote:That'd be awesome. I have a pretty concrete idea of how this should look like, and would definitely prefer a little tool directly inside the LDC repo, analogous to ldc-build-runtime. The main reason being that it's tightly coupled to the prebuilt packages, and they are controlled by the CI scripts in the LDC repo. See https://forum.dlang.org/post/pujpcnubepoknwbircob forum.dlang.org for how I imagine this to be used.Wrt. automating the last mile (actually, the last few inches), setting up ldc2.conf, I've repeatedly stated that generalizing Adam's little Android tool would clearly be my choice. Sebastian Koppe promised to do that, but he's probably quite busy at the moment.Yeah, it shouldn't be too hard to do. Maybe I'll look at doing it myself
Jun 26 2020
On Friday, 26 June 2020 at 19:33:03 UTC, kinke wrote:That'd be awesome. I have a pretty concrete idea of how this should look like, and would definitely prefer a little tool directly inside the LDC repo, analogous to ldc-build-runtime. The main reason being that it's tightly coupled to the prebuilt packages, and they are controlled by the CI scripts in the LDC repo. See https://forum.dlang.org/post/pujpcnubepoknwbircob forum.dlang.org for how I imagine this to be used.That would be very useful. Keep in mind that many would like to have several targets installed at the same time so that you don't have to have a separate ldc directory for each target. As mentioned using ldc -mtriple=x-y-z will just take another target than the default one and automatically choose the right libraries and import paths. BTW, why is LDC using -mtriple when clang is using --target?
Jun 26 2020
On 6/26/2020 2:18 AM, aberba wrote:On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.On 6/24/2020 4:21 AM, aberba wrote:Just did. Don't get your point.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 26 2020
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:Not a single computer powered by an ARM CPU shows up.Maybe that's just a bad search term cuz there's plenty of arm devices on the market, they are just often called other things like "ipads" and "chromebooks" and other brand names instead of being generically called "computers".
Jun 26 2020
On 6/26/2020 1:48 PM, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:Search on "desktop computer". On the left, you'll find a CPU menu. No ARM processors in it. Neither for Amazon. I find it curious that nobody makes one.Not a single computer powered by an ARM CPU shows up.Maybe that's just a bad search term cuz there's plenty of arm devices on the market, they are just often called other things like "ipads" and "chromebooks" and other brand names instead of being generically called "computers".
Jun 26 2020
On Friday, 26 June 2020 at 20:58:19 UTC, Walter Bright wrote:Search on "desktop computer". On the left, you'll find a CPU menu. No ARM processors in it. Neither for Amazon.Yeah, ARM's primary competitive advantage over x86 is lower power consumption, which means they are biased toward the portable market. There are still various wall-outlet arm devices, especially single-board computers (SBC for short) like the raspberry pi and pine64, but they are still a different form-factor than the traditional desktop... probably just because there's no actual need for them to be larger, and while many new x86 devices don't need much space either, arm devices don't have the same traditional history to push it out of habit either. They also tend to be sold in those single board forms rather than individual components for DIYers who don't like the big brands, so instead of getting a CPU on newegg, you'd just order an all-in-one board and a case for it. Anyway, whether wall-power SBC, or one of the portable options like a laptop or phone, you can connect them to all the same accessories to give a desktop experience: keyboard, mouse, speakers, monitor, and not know the difference unless you look under the cover for a great many tasks.
Jun 26 2020
On Friday, 26 June 2020 at 22:46:53 UTC, Adam D. Ruppe wrote:On Friday, 26 June 2020 at 20:58:19 UTC, Walter Bright wrote:ARM is everywhere, the entire computer industry and internet hangs off devices with ARM cores. This is not true for Intel. For the last 5 yrs the entire embedded industry has moved towards ARM. Apple are just jumping on the bandwagon :-) Any device running software that was manufactured in the last 5 yrs will likely have an ARM core in there somewhere. Even in a desktop in the PSU or motherboard. More recent AMD x86 CPUs have an ARM core in the silicon. All those ARM cores are running software and that production software is currently C or C++11 (or higher). The current trend for embedded is C++14 with GCC or IAR compilers. Prior to C++11 the industry was stuck in its ways with C, but C++11 and the committee direction has really changed all that. There are teams that still insist on C only but they are becoming less and less. Rust is starting to gain a lot of traction in embedded as the alternative language for production code. Most people I talk with at trade shows and conferences like that the compiler shouts loudly a them if they do something considered unsafe by the language. When I ask about the friction Rust introduces most say they get used to it and then begin to like it because they see all the noise is actually for good reasons. Frequent I hear comments like "once the code compiles I have a lot more confidence my program is memory safe and correct". This is not true for C++, even C++20 because there are so many corners in the language rules. Sadly D isn't even on the radar, mostly because Rust marketing is so strong but also for those that do look at it there is no official ARM support. D could compete and do well in the embedded space with its feature set, low-friction like Python yet familiar C-like syntax. NormSearch on "desktop computer". On the left, you'll find a CPU menu. No ARM processors in it. Neither for Amazon.Yeah, ARM's primary competitive advantage over x86 is lower power consumption, which means they are biased toward the portable market. There are still various wall-outlet arm devices, especially single-board computers (SBC for short) like the raspberry pi and pine64, but they are still a different form-factor than the traditional desktop... probably just because there's no actual need for them to be larger, and while many new x86 devices don't need much space either, arm devices don't have the same traditional history to push it out of habit either. They also tend to be sold in those single board forms rather than individual components for DIYers who don't like the big brands, so instead of getting a CPU on newegg, you'd just order an all-in-one board and a case for it. Anyway, whether wall-power SBC, or one of the portable options like a laptop or phone, you can connect them to all the same accessories to give a desktop experience: keyboard, mouse, speakers, monitor, and not know the difference unless you look under the cover for a great many tasks.
Jul 01 2020
I think NVIDIA Jetson series might be the only big name boards you can get. But they are dev kits meant for machine learning (high end boards are quad core, 8gb ram).
Jun 26 2020
On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole wrote:I think NVIDIA Jetson series might be the only big name boards you can get. But they are dev kits meant for machine learning (high end boards are quad core, 8gb ram).D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Jun 26 2020
On 27/06/2020 8:58 AM, Paolo Invernizzi wrote:On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole wrote:Neat! Could you do a D blog article on what you do with it? It would be a good show of application of D.I think NVIDIA Jetson series might be the only big name boards you can get. But they are dev kits meant for machine learning (high end boards are quad core, 8gb ram).D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Jun 26 2020
On Friday, 26 June 2020 at 21:00:53 UTC, rikki cattermole wrote:On 27/06/2020 8:58 AM, Paolo Invernizzi wrote:The bad things around big medical companies is that they tend to tie your hands with a pletora of NDA agreements ... I've literally lost the count around how many I've signed! What I can tell is that it's driving a depth camera, and mixing data in realtime received by an eye-tracker device.On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole wrote:Neat! Could you do a D blog article on what you do with it? It would be a good show of application of D.I think NVIDIA Jetson series might be the only big name boards you can get. But they are dev kits meant for machine learning (high end boards are quad core, 8gb ram).D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Jun 26 2020
On 27/06/2020 9:05 AM, Paolo Invernizzi wrote:The bad things around big medical companies is that they tend to tie your hands with a pletora of NDA agreements ... I've literally lost the count around how many I've signed! What I can tell is that it's driving a depth camera, and mixing data in realtime received by an eye-tracker device.Strip out all the medical bits and with just that, could you make a demo of D being used in it? It could be a good time to try out some new hardware to throw people off the trail ;) Tech is cool, regardless of how its being used in practice.
Jun 26 2020
On Friday, 26 June 2020 at 22:23:21 UTC, rikki cattermole wrote:On 27/06/2020 9:05 AM, Paolo Invernizzi wrote:Oh, but there's really nothing special about it: D "just works". Looking at the gitlab CI script, the project started with ldc-1.13.0, so it's not really a 'new thing' ... curl, source activate, ldmd2 -I, et voilà!The bad things around big medical companies is that they tend to tie your hands with a pletora of NDA agreements ... I've literally lost the count around how many I've signed! What I can tell is that it's driving a depth camera, and mixing data in realtime received by an eye-tracker device.Strip out all the medical bits and with just that, could you make a demo of D being used in it? It could be a good time to try out some new hardware to throw people off the trail ;) Tech is cool, regardless of how its being used in practice.
Jun 26 2020
On 27/06/2020 6:53 PM, Paolo Invernizzi wrote:I have never done anything like this, so to me this is really cool to see D being used like this!It could be a good time to try out some new hardware to throw people off the trail ;) Tech is cool, regardless of how its being used in practice.Oh, but there's really nothing special about it: D "just works". Looking at the gitlab CI script, the project started with ldc-1.13.0, so it's not really a 'new thing' ... curl, source activate, ldmd2 -I, et voilà!
Jun 27 2020
On 6/26/2020 2:00 PM, rikki cattermole wrote:Could you do a D blog article on what you do with it? It would be a good show of application of D.Yes, please. The D Foundation will also pay for articles accepted for publication on the blog!
Jun 27 2020
On Saturday, 27 June 2020 at 08:45:25 UTC, Walter Bright wrote:On 6/26/2020 2:00 PM, rikki cattermole wrote:Thanks for the encouragement Walter, but I'm a bad and boring writer ... and short of time in this period!Could you do a D blog article on what you do with it? It would be a good show of application of D.Yes, please. The D Foundation will also pay for articles accepted for publication on the blog!
Jun 29 2020
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:On 6/26/2020 2:18 AM, aberba wrote:Sorry, but this is a D typical way of answering to such issues. Put your blinders on and say that it's not an issue, all is good. ARM has been an issue for quite a while and it was obvious years ago that there would be more and more ARM in the future. Things are going in this direction (small devices etc.) Adam gave you a good answer. He's right. And things may change quite fast. Look at Steve, he wants to buy an "old" MacBook in order to have time to transition to ARM. It is urgent and you have to act now. I hope you don't think that if people have enough skin in the game (i.e. their livelihood), then somebody will step up and tackle it. No, this is the job of the DLF. You should be glad that the LDC crowd has done a fantastic job already. Do you understand that their work might actually save D one day? I strongly advise you to make ARM a top priority, maybe not with DMD, but with a package (LDC / GDC) that makes for a smooth development experience and is future proof - not as a community project (as people might just leave for various reasons) but as a LTS project managed directly by the DLF (like DMD).On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.On 6/24/2020 4:21 AM, aberba wrote:Just did. Don't get your point.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 27 2020
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:On 6/26/2020 2:18 AM, aberba wrote:apple is / will be shipping $500 dev kits w/ an A10z; might be seriously worth looking into if anyone wanted to try doing compiler and/or toolchain work on arm https://developer.apple.com/programs/universal/On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.On 6/24/2020 4:21 AM, aberba wrote:Just did. Don't get your point.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 30 2020
addendum: yes, this means you'd be stuck w/ an apple dev kit (and need to be a registered apple developer so the full cost of getting this is ~$600) but this is probably your best bet, by far, for getting a full, working developer environment on an arm chipset atm, outside of running an old surface tablet w/ windows RT, or running a linux distro off a phone, or something. Apple's implementation of this is running full mac os, with probably one of the fastest arm chipsets out atm And it can run x86_64 code using an emulation layer (which I'm guessing is mostly just binary recompilation to arm, or something), which... obviously neither of the other two options can do afaik Geekbench, supposedly, is running on it (and w/ the x64 version), and it benchmarks pretty darn close to a 4-5 year old i5 / i7 laptop (source: have a 5 year old laptop w/ an i7 4980hq, and the dev kit's benchmarks are shockingly close to that) it'd be pretty interesting to see if dmd can run on this out of the box, and what problems (if any) there might be with that. (intrinsics? threading? runtime code modification??) For porting bits of dmd and/or druntime and/or toolchain stuff to arm, I'm not sure you could do better than working on a pretty powerful arm chip that can run both arm *and* x86_64 code You'd be stuck w/ macos ofc, but I'm pretty sure you could do quite a bit worse on that front in terms of having a real, working desktop development environment, that can run real dev tools and w/ performance that will probably not suck. no visual studio, but eh, vscode should work (hopefully), and there's intellij stuff. and there's xcode, which... if nothing else has pretty good debugging and profiling tools, and can be run on d binaries if you're sufficiently motivated and/or desperate
Jun 30 2020
On Wednesday, 1 July 2020 at 03:10:41 UTC, Seiji Emery wrote:addendum: yes, this means you'd be stuck w/ an apple dev kit (and need to be a registered apple developer so the full cost of getting this is ~$600) but this is probably your best bet, by far, for getting a full, working developer environment on an arm chipset atm, outside of running an old surface tablet w/ windows RT, or running a linux distro off a phone, or something.Nvidia is selling pretty popular solutions based on ARM and Nvidia GPU, all linux powered. You really don't need to rely on a Phone or (ugh) old surface tablets ...it'd be pretty interesting to see if dmd can run on this out of the box, and what problems (if any) there might be with that. (intrinsics? threading? runtime code modification??) For porting bits of dmd and/or druntime and/or toolchain stuff to arm, I'm not sure you could do better than working on a pretty powerful arm chip that can run both arm *and* x86_64 codeAgain, LDC runs out of the box on ARM since a long time now ... just check on the release page for the available tarred distributionsYou'd be stuck w/ macos ofc, but I'm pretty sure you could do quite a bit worse on that front in terms of having a real, working desktop development environment, that can run real dev tools and w/ performance that will probably not suck. no visual studio, but eh, vscode should work (hopefully), and there's intellij stuff. and there's xcode, which... if nothing else has pretty good debugging and profiling tools, and can be run on d binaries if you're sufficiently motivated and/or desperateA 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...) There are plenty of solutions, without having to rely on Apple! (Disclaimer, message written on my 2019 iMac, eheh) /P
Jul 01 2020
Hardware: if IO speeds matter, ASUS has Tinkerboards with dual-channel RAM - I think those are rare in ARM land. Form factor: realizing the market for SBC's, there are amd64 SBC's now like the lattepanda (soldered RAM, like most SBC's). dmd: does its backend play a big role in compilation speed? Would maintaining a fork of a backend from somewhere else (SBCL?) provide wider platform support without harming dmd performance? RISC-V is behind ARM on the horizon. ARM may be urgent, if say, the Pinebook, takes off among developers.
Jul 01 2020
On Wednesday, 1 July 2020 at 13:39:57 UTC, Yatheendra wrote:Hardware: if IO speeds matter, ASUS has Tinkerboards with dual-channel RAM - I think those are rare in ARM land. Form factor: realizing the market for SBC's, there are amd64 SBC's now like the lattepanda (soldered RAM, like most SBC's). dmd: does its backend play a big role in compilation speed? Would maintaining a fork of a backend from somewhere else (SBCL?) provide wider platform support without harming dmd performance? RISC-V is behind ARM on the horizon. ARM may be urgent, if say, the Pinebook, takes off among developers.Also, if developing for the host processor on FPGA's could be of enough interest, most FPGA's only have ARM (or Synopsys ARC, or MIPS) host processors - even the Intel-owned Altera FPGA's, I guess.
Jul 01 2020
On 02/07/2020 1:39 AM, Yatheendra wrote:ARM may be urgent, if say, the Pinebook, takes off among developers.ldc and gdc are a thing. We are ok.
Jul 01 2020
On Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole wrote:On 02/07/2020 1:39 AM, Yatheendra wrote:One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.ARM may be urgent, if say, the Pinebook, takes off among developers.ldc and gdc are a thing. We are ok.
Jul 01 2020
On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:On Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole wrote:If dmd and its scripting-like development cycle speed stops being the primary entry point for newbies, it is a "pretend one". Until then, it doesn't seem to be a dismissible problem. Again, until a Pinebook or an ARM Macbook/Mini becomes a developer preference, there is no urgency for the "dmd experience on ARM".On 02/07/2020 1:39 AM, Yatheendra wrote:One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.ARM may be urgent, if say, the Pinebook, takes off among developers.ldc and gdc are a thing. We are ok.
Jul 01 2020
On 7/1/20 12:27 PM, Yatheendra wrote:On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:It may not be a dismissable problem, but it's also not someone anyone but Walter can fix. So the question from a community standpoint is (allowing that we have really no control over this), is it worth having Walter create an entirely new backend instead of doing other work? I'd say no. Unless someone else knows how to make this happen? Another approach may be to figure out a way to make a non-optimized build with ldc run as fast as or close to dmd. -SteveOn Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole wrote:If dmd and its scripting-like development cycle speed stops being the primary entry point for newbies, it is a "pretend one". Until then, it doesn't seem to be a dismissible problem. Again, until a Pinebook or an ARM Macbook/Mini becomes a developer preference, there is no urgency for the "dmd experience on ARM".On 02/07/2020 1:39 AM, Yatheendra wrote:One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.ARM may be urgent, if say, the Pinebook, takes off among developers.ldc and gdc are a thing. We are ok.
Jul 01 2020
On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer wrote:It may not be a dismissable problem, but it's also not someone anyone but Walter can fix. So the question from a community standpoint is (allowing that we have really no control over this), is it worth having Walter create an entirely new backend instead of doing other work? I'd say no.It's inevitable that backends using LLVM or GCC will take over. Already today the DMD backend falls short when it comes to code generation compared to LDC and GDC. DMD has its benefits but as LDC and GDC progresses those benefits become less and it will not be worth using DMD at all. Walter may work all he wants on the DMD backend but the question is how well spent time that is as not many people will use it. If I would be Walter I would retire the DMD code generator and completely migrate to LLVM and GCC. This is a project with limited resources and that's one way to streamline the project. About all new language projects use an external backends like GCC or LLVM. Mention one project that has its own in the last 10 years. Now this was not the case during 90s where D was being formed. LDC is my default compiler and it was that from the very beginning. I just tried out DMD a bit but never ever used for something serious.
Jul 01 2020
Yes, ideally a compiler shouldn't need to worry about a backend nowadays. Yet, SBCL and OCaml have comfortably maintained their own non-GCC non-LLVM backends. They are fairly imperative languages, so the choice of dmd backend may hypothetically be among 4, not 2. If it comes to evolving dmd backend, maybe it should shift, but maintaining script-like development seems useful. It doesn't help that ARM is a fragmented land, compiling dmd from source may be commonly required and I haven't had success compiling gdc on amd64 with less than 4GB of RAM. It sounds bad to need a separate big machine just for compilation, when ARM isn't an embedded targer.
Jul 01 2020
On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer wrote:On 7/1/20 12:27 PM, Yatheendra wrote:On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:Another approach may be to figure out a way to make a non-optimized build with ldc run as fast as or close to dmd.Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
Jul 01 2020
On 02/07/2020 1:45 PM, aberba wrote:On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer wrote:On Windows LDC and DMD should have the same out of the box experience thanks to LLD today. LDC is packaged in linux repositories like debian. https://packages.debian.org/buster/ldc Not the latest, but it is simpler than dmd as no looking for a deb file. $ apt install ldc ;)On 7/1/20 12:27 PM, Yatheendra wrote:On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:Another approach may be to figure out a way to make a non-optimized build with ldc run as fast as or close to dmd.Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
Jul 01 2020
On Thursday, 2 July 2020 at 01:56:34 UTC, rikki cattermole wrote:On 02/07/2020 1:45 PM, aberba wrote:For your information, using a deb is actually more simple. It all depends on how you're conditioned. Also where you're coming from. There's a reason why dmd installer downloads keep ticking.On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer wrote:On Windows LDC and DMD should have the same out of the box experience thanks to LLD today. LDC is packaged in linux repositories like debian. https://packages.debian.org/buster/ldc Not the latest, but it is simpler than dmd as no looking for a deb file. $ apt install ldc ;)On 7/1/20 12:27 PM, Yatheendra wrote:On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:Another approach may be to figure out a way to make a non-optimized build with ldc run as fast as or close to dmd.Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
Jul 02 2020
On 7/1/2020 10:00 AM, Steven Schveighoffer wrote:It may not be a dismissable problem, but it's also not someone anyone but Walter can fix. So the question from a community standpoint is (allowing that we have really no control over this), is it worth having Walter create an entirely new backend instead of doing other work? I'd say no.I'm pretty sure that 3/4 of the backend can be used pretty much as-is. The optimizer, for example, is independent. The 16 bit stuff can be omitted, so can the floating point emulator and x87 code. The rest of the structure can be kept, just replacing the tinsel on the christmas tree. The exception handling support, symbolic debug support, and object file support should be the same.
Jul 02 2020
On 7/2/20 6:31 AM, Walter Bright wrote:On 7/1/2020 10:00 AM, Steven Schveighoffer wrote:Well, as I said, it's you who probably has to do it, so if you want to do it, then I would love to keep using DMD on my (future) macbook ;) -SteveIt may not be a dismissable problem, but it's also not someone anyone but Walter can fix. So the question from a community standpoint is (allowing that we have really no control over this), is it worth having Walter create an entirely new backend instead of doing other work? I'd say no.I'm pretty sure that 3/4 of the backend can be used pretty much as-is. The optimizer, for example, is independent. The 16 bit stuff can be omitted, so can the floating point emulator and x87 code. The rest of the structure can be kept, just replacing the tinsel on the christmas tree. The exception handling support, symbolic debug support, and object file support should be the same.
Jul 02 2020
On Wednesday, 1 July 2020 at 16:27:27 UTC, Yatheendra wrote:If dmd and its scripting-like development cycle speed stops being the primary entry point for newbies, it is a "pretend one". Until then, it doesn't seem to be a dismissible problem. Again, until a Pinebook or an ARM Macbook/Mini becomes a developer preference, there is no urgency for the "dmd experience on ARM".DMD brings a lot of value with its fast compilation speed. I don't see D losing all of its value without fast compilation, though, and I don't see ARM taking over the developer world any time soon. There's no reason you can't compile on a "normal" computer in the early stages and then move over to ARM for the final stages using LDC. I have trouble believing there will be a lot of exclusively ARM development going on anytime soon. Just today there was a story posted where Linus said "Over the last 10 years or so I've been complaining about the fact that it's really hard to find Arm hardware that is usable for a developer," Torvalds responded. Everything about this being the end of the D programming language is speculative if the Linux kernel doesn't even support ARM as a first class citizen. https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
Jul 01 2020
On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...)What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 01 2020
On Wednesday, 1 July 2020 at 15:48:59 UTC, Martin Tschierschke wrote:On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:Cool, (a little outdated) but cool! Usually we use the tar from the release page of the LDC GitHub page, but good to know LDC it's available also on that platform! Thank you Martin for the info!A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...)What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 01 2020
On Wednesday, 1 July 2020 at 15:55:34 UTC, Paolo Invernizzi wrote:On Wednesday, 1 July 2020 at 15:48:59 UTC, Martin Tschierschke wrote:There's not enough awareness of some of these things. If you don't get why DMD is so important in this ARM talk is unless you're a seasoned D developer of LLVM guy, you'll most likely start with DMD. Cus it's the default compiler and it's quite easy to use with a simple .deb file download.On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:Cool, (a little outdated) but cool! Usually we use the tar from the release page of the LDC GitHub page, but good to know LDC it's available also on that platform! Thank you Martin for the info!A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...)What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 01 2020
On 7/1/2020 8:48 AM, Martin Tschierschke wrote:On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...)What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 02 2020
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi.apt install gdc gdc program.d where's my cash? :P It really is that simple, with the one caveat that the gdc in the package manager is a bit old, so not all libraries will just work. Getting gdc into gcc is a real victory - it is this simple on various Linux systems now. I recently did a gpio module too and made a little D program to do audio and trigger leds on a raspberry pi http://dpldocs.info/this-week-in-d/Blog.Posted_2020_05_11.html#gpio.d
Jul 02 2020
On Thursday, 2 July 2020 at 20:46:52 UTC, Adam D. Ruppe wrote:On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:How about on Windows? I guess that might be tricky.Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi.apt install gdc gdc program.d where's my cash? :P
Jul 02 2020
On Thursday, 2 July 2020 at 21:40:24 UTC, JN wrote:How about on Windows? I guess that might be tricky.So that is developing for the pi on the pi itself. Cross compiling is easiest on ldc: you get ldc for your host system, grab ldc for the target, then merge the library directories and configuration files. It still isn't hard, but it is a bit more work. I'm gonna be working with the ldc people some time later this month to make it very simple too (I did it for android already, just gonna generalize that to other targets as well), so you just do like "ldc setup" and check off the targets you want and then it sets it all up for you.
Jul 02 2020
On 7/2/2020 1:46 PM, Adam D. Ruppe wrote:On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:Posting in the n.g. only reaches people already using D. The point of the D Blog is outreach.Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi.apt install gdc gdc program.d where's my cash? :P It really is that simple, with the one caveat that the gdc in the package manager is a bit old, so not all libraries will just work. Getting gdc into gcc is a real victory - it is this simple on various Linux systems now. I recently did a gpio module too and made a little D program to do audio and trigger leds on a raspberry pi http://dpldocs.info/this-week-in-d/Blog.Posted_2020_05_11.html#gpio.d
Jul 02 2020
On 7/2/2020 1:42 PM, Walter Bright wrote:Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)If that's not incentive enough, consider that I know programmers with in excess of $1m in annual compensation. What do they have in common? They write blogs and articles about what they do. It's great marketing for yourself. You might be every bit good a programmer as they are, but nobody knows that because you don't write any articles, do any presentations at conferences, etc. When nobody knows you're good, you aren't going to be highly compensated. BTW, something I'm very proud about, many people who presented at DConf have gotten very well paying jobs as a direct result.
Jul 02 2020
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:On 7/1/2020 8:48 AM, Martin Tschierschke wrote:Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)Its very tricky when dealing with the D folks. 😂 Sometimes its hard to know if it'll be any interesting. But yeah, I've got stuff in the pipeline to do something about it...not just on the D blog.
Jul 02 2020
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:On 7/1/2020 8:48 AM, Martin Tschierschke wrote:Beside having two raspberry pi (3B+ and 4) one at home and one at work under my control, I just tried if LDC is available - and compiled a "Hello World". There seams to be a repository to control the GPIO-pins for doing some maker stuff, (https://github.com/fgheorghe/D-Lang-Raspbian-GPIO-Module) I only use the Pis as MediaCenter and backup target (just cron + rsync). But there are several posts about D on Raspberry pi in the forum, so someone might bring up interesting use cases. (Vibe.d webserver) The very low power consumption compared to desktops make the pi a cheap always-run solution. The latest PI generation (4) is available with up to 8 GB Ram and a new 64 bit OS is available as beta software. The PI Foundation just renamed Raspbian to Raspberry Pi OS. (Which still, as I understand, is based on the Debian Linux distribution ) With 4 or 8GB memory, it can replace a desktop pc for most simple office use cases. The latest version has USB 3.0, so access to bigger storage is much faster than with the older generations (3,2 and 1).On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...)What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 03 2020
On 2020-07-01 10:22, Paolo Invernizzi wrote:There are plenty of solutions, without having to rely on Apple!If we're talking specifically about supporting the new Apple Silicon (as they call their ARM chip) any old ARM won't do. Apple uses a slightly different ABI then regular ARM. It might get you close, but not all the way. Alternatively, one can work with an iPhone or an iPad. iPhone and iPad apps run unmodified on Macs with Apple Silicon. It happens so, that this dev kit is running exactly the same CPU as the latest iPad Pro. Also, one probably need to be able to cross-compile, which DMD doesn't support. Or using an old version from when DMD was written in C++ to bootstrap. -- /Jacob Carlborg
Jul 01 2020
On 2020-07-01 05:10, Seiji Emery wrote:addendum: yes, this means you'd be stuck w/ an apple dev kit (and need to be a registered apple developer so the full cost of getting this is ~$600)No you won't. You need to return it. -- /Jacob Carlborg
Jul 01 2020
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:On 6/24/2020 4:21 AM, aberba wrote::-) But there is more with ARM: ARM-based Japanese supercomputer is now the fastest in the world https://www.theverge.com/2020/6/23/21300097/fugaku-supercomputer-worlds-fastest-top500-riken-fujitsu-arm Question: How complicated would it be to replace the compilation result of DMD (X86 code) with the code an X86 emulator on ARM would use. By this "trick" you might get the fast DMD compilation times for development and use LDC for production? Best regards mt.PC was the only compelling target for Intel/Amd targets but now its changing.Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 26 2020
On 6/24/2020 4:21 AM, aberba wrote:This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.There goes my weekend.
Jun 25 2020
On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690 This means there's genuine interest in Arm. Note there's similar move by Microsoft to get their system to work on Arm chips. PC was the only compelling target for Intel/Amd targets but now its changing.I'm quite skeptical about how big of an impact it'll have. Apple's main customers are rich business people wanting to do regular office-work on a luxury machine. Machined aluminium is the new beige. Yes, other people still use them, but seeing how long Apple have neglected it's professional users, I wouldn't be surprised if they either ditched them completely, or just force them into their restrictive ecosystem. There's a lot of productivity apps ported to ARM processors already, but some people will suffer as a consequence of Apple's move. Even if Apple will fail massively with their ARM chips, we still need to get into ARM more than currently. I personally would have gotten a Raspberry Pi, unfortunately my country has a quite infamous used market, where people are trying to sell outdated hardware barely below their original price. Money is still a concern for me, although I have a few plans to remedy it.
Jul 01 2020
On Thursday, 2 July 2020 at 00:12:03 UTC, solidstate1991 wrote:Money is still a concern for me, although I have a few plans to remedy it.Hello, I don't know your current status and plans, but we have a Bug Bounty program in Dplug that a D freelancer could use: https://github.com/AuburnSounds/Dplug/wiki/Bug-Bounty-Program Those are are well defined and known tasks with hopefully reduced scopes. enter the conversation)
Jul 02 2020