Re: New language based on D
On 2020-11-12 20:00, bachmeier wrote: On Thursday, 12 November 2020 at 15:28:44 UTC, Faux Amis wrote: Maybe these type of subset languages could be integrated in the D frontpage. I hope not. That would create lots of problems: - There are multiple versions of the language. - What happens when a version dies? What do you tell the developers (perhaps even businesses) that relied on a version they downloaded from the official homepage that now have a dead version? - What if a developer makes weird changes (like removing int, which would still be a subset) or goes Windows-only because of the burden maintaining for multiple OSes? Is that something that should be promoted on the official homepage? These are just the problems that immediately come to mind. I'm sure there are others. Open source is wonderful because it lets things like this happen. That doesn't mean we want to promote them on dlang.org. I wasn't clear before. The subset I was thinking about would only be supervisual; the basic-D documentation and tutorials would only touch those parts that would be part of the basic-D version. The underlying compiler would just be the normal dmd compiler, nothing changed. I thik that within D there is a nice novice language lurking, but it is hidden by all the complex parts.
Re: DIP 1030-- Named Arguments--Formal Assessment
On Thursday, 17 September 2020 at 12:59:05 UTC, Mike Parker wrote:
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker
wrote:
DIP 1030, "Named Arguments", has been accepted.
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1030.md
Fantastic news.
The fact that it is a caller decision to use or not names
emphasizes the D "syntax sugar" oriented conventions (like "dot
notation"): same method can be called using the way it fits
better with your on convention.
countOcurrences("hello", "e");
"hello".countOcurrences("e");
"hello".countOcurrences(of:"e"),
countOcurrences(of:"e", in:"hello");
I use rdmd as scripting tool, and I have to say that I will adopt
immediately named parameters usage: in addition to scope(...),
ranges and the simplicity/power of the standard library, D
becomes an expressive and powerful scripting language.
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 15:20:19 UTC, 9il wrote: On Wednesday, 18 November 2020 at 13:14:37 UTC, jmh530 wrote: On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: It also looks like you are compiling on ldc with -mcpu=native --boundscheck=off. Why not -O as well? -O is added by DUB Just -O? LDC is quite impressive with lto and cross-module-inlining turned on
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 15:20:19 UTC, 9il wrote: [snip] -O is added by DUB Ah, the -release-nobounds
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Feedback is very welcome. Please feel free to open issues, pull requests or simply post your thoughts below. Kind regards, Tobias Thank you a lot! It is a huge benefit for Mir and D to have so quality benchmarks. Python's sweep_3D access memory only once for one element computation, while old D's sweep_slice access it 7 times. A PR [1] for new version of sweep_slice was added, I expect it will be at least twice faster. The new sweep_slice uses a more D'sh approach and single memory access to the computation element. [1] https://github.com/typohnebild/numpy-vs-mir/pull/1 Cheers, Ilya
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 13:14:37 UTC, jmh530 wrote: On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: It also looks like you are compiling on ldc with -mcpu=native --boundscheck=off. Why not -O as well? -O is added by DUB
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 13:01:42 UTC, Bastiaan Veelo wrote: On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Nice numbers. I’m not a Python guy but I was under the impression that Numpy actually is written in C, so that when you benchmark Numpy you’re mostly benchmarking C, not Python. Therefore I had expected the Numpy performance to be much closer to D’s. An important factor I think, which I’m not sure you have discussed (didn’t look too closely), is the compiler backend that was used to compile D and Numpy. Then again, as a user one is mostly interested in the out-of-the-box performance, which this seems to be a good measure of. — Bastiaan. A lot of numpy is in C, C++, fortran, asm etc But when you chain a bunch of things together, you are going via python. The language boundary (and python being slow) means that internal iteration in native code is a requirement for performance, which leads to eager allocation for composability via python, which then hurts performance. Numpy makes a very good effort, but is always constrained by this. Clever schemes with laziness where operations in python are actually just composing operations for execution later/on-demand can work as an alternative, but a) that's hard and b) even if you can completely avoid calling back in to python during iteration you would still need JIT to really unlock the performance. Julia fixes this by having all/most in one language which is JIT'd D can do the same with templates AOT, like C++/Eigen does but more flexible and less terrifying code. That's (one part of) what mir provides.
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Feedback is very welcome. Please feel free to open issues, pull requests or simply post your thoughts below. Kind regards, Tobias Very nice write up. It's been a while since I've used numba, so I was a little confused on the numba 1 and numba 8 runs. It also looks like you are compiling on ldc with -mcpu=native --boundscheck=off. Why not -O as well?
Re: MIR vs. Numpy
On Wednesday, 18 November 2020 at 10:05:06 UTC, Tobias Schmidt wrote: Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Nice numbers. I’m not a Python guy but I was under the impression that Numpy actually is written in C, so that when you benchmark Numpy you’re mostly benchmarking C, not Python. Therefore I had expected the Numpy performance to be much closer to D’s. An important factor I think, which I’m not sure you have discussed (didn’t look too closely), is the compiler backend that was used to compile D and Numpy. Then again, as a user one is mostly interested in the out-of-the-box performance, which this seems to be a good measure of. — Bastiaan.
MIR vs. Numpy
Dear all, to compare MIR and Numpy in the HPC context, we implemented a multigrid solver in Python using Numpy and in D using Mir and perforemd some benchmarks with them. You can find our code and results here: https://github.com/typohnebild/numpy-vs-mir Feedback is very welcome. Please feel free to open issues, pull requests or simply post your thoughts below. Kind regards, Tobias
