Re: Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
On Wednesday, 13 July 2022 at 01:23:35 UTC, D Lark wrote: First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library? Yes, it should behave the way you expect. The current behavior is a bug. I've submitted a report for it here: https://issues.dlang.org/show_bug.cgi?id=23242
Why does inputRangeObject fail to derive correctly for RandomAccessInfinite ranges?
This is slightly related to this issue I reported earlier: https://forum.dlang.org/post/wghdwxptjfcjwptny...@forum.dlang.org Here's the snippet that captures what fails for me ```dlang import std.range: ElementType, isRandomAccessRange, inputRangeObject, sequence, MostDerivedInputRange, RandomAccessInfinite; auto seq = sequence!((a, n) => n); alias SeqType = typeof(seq); static assert(isRandomAccessRange!SeqType); static assert(is(MostDerivedInputRange!SeqType == RandomAccessInfinite!(ElementType!SeqType))); auto seqInputRange = seq.inputRangeObject; static assert(isRandomAccessRange!(typeof(seqInputRange))); // returns 'false'; I expect this to return 'true' as the most derived type of 'seq' is of 'RandomAccessInfinite' as demonstrated above ``` I am compiling using dmd v2.100.1 First, please can someone clarify if the behaviour I expect in the last line is consistent with the intention of the library? I have poked around the source and I can see that the `InputRangeObject` (the object returned by `inputRangeObject` derives from the return type of the `MostDerivedInputRange` template, which as shown above returns the correct interface. However it seems that the implementation of `InputRangeObject` does not implement `enum bool empty = false` in the case of the `RandomAccessInfinite` ranges, which leads to the template `isRandomAccessRange` returning false.
Re: null == "" is true?
On 7/12/22 4:36 PM, Antonio wrote: On Tuesday, 12 July 2022 at 18:56:43 UTC, Paul Backus wrote: On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote: Because an empty string is, by default, represented by an empty slice of the null pointer. Do not rely on this, however; it's possible sometimes to get an empty string that isn't null, e.g., if you incrementally shrink a slice over a string until it's empty. In that case, .ptr will not be null, but the string will still be empty. Always compare strings against "" rather than null, because the latter may not do what you think it does sometimes. This is actually 100% reliable when comparing with the `==` operator because two empty strings always compare equal with `==`, regardless of what they point to. string s = "hello"; string empty1 = s[0 .. 0]; string empty2 = s[1 .. 1]; assert(empty1 == null); assert(empty2 == null); assert(empty1 == empty2); The real problem is that `s == null` looks like it does one thing (test for a null pointer) while actually doing something slightly different (test for an empty string). Then: ```d string a = null; assert(a is null); assert(a == ""); string b = ""); assert(b !is null); assert(b == null); ``` Honestly, it is difficult to understand for newcomers... there is a reason, but there is a reason in javascript for `0 == ''` too It's not just for `null`. And it's unrelated to what javascript is doing. ```d string a = "abcabc"; assert(a[0 .. 3] == a[3 .. $]) assert(a[0 .. 3] !is a[3 .. $]) ``` The point is, `==` compares *value*, `is` always compares *identity*. And you cannot override `is`, it must always be predictable. For arrays, of course, you can't override `==`, but custom types can. -Steve
Re: null == "" is true?
On Tuesday, 12 July 2022 at 20:36:03 UTC, Antonio wrote: Honestly, it is difficult to understand for newcomers... there is a reason, but there is a reason in javascript for `0 == ''` too Correction ```d string a = null; assert(a is null); assert(a == ""); string b = ""; assert(b !is null); assert(b == null); ```
Re: null == "" is true?
On Tuesday, 12 July 2022 at 18:56:43 UTC, Paul Backus wrote: On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote: Because an empty string is, by default, represented by an empty slice of the null pointer. Do not rely on this, however; it's possible sometimes to get an empty string that isn't null, e.g., if you incrementally shrink a slice over a string until it's empty. In that case, .ptr will not be null, but the string will still be empty. Always compare strings against "" rather than null, because the latter may not do what you think it does sometimes. This is actually 100% reliable when comparing with the `==` operator because two empty strings always compare equal with `==`, regardless of what they point to. string s = "hello"; string empty1 = s[0 .. 0]; string empty2 = s[1 .. 1]; assert(empty1 == null); assert(empty2 == null); assert(empty1 == empty2); The real problem is that `s == null` looks like it does one thing (test for a null pointer) while actually doing something slightly different (test for an empty string). Then: ```d string a = null; assert(a is null); assert(a == ""); string b = ""); assert(b !is null); assert(b == ""); ``` Honestly, it is difficult to understand for newcomers... there is a reason, but there is a reason in javascript for `0 == ''` too
Re: null == "" is true?
On Tuesday, 12 July 2022 at 19:55:46 UTC, ag0aep6g wrote:
On Tuesday, 12 July 2022 at 19:02:01 UTC, user1234 wrote:
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
[...]
Do not rely on this, however;
Absolutely. I'd like to add: especially as default parameter
value that's an array. Never use null. use `[]` (empty array
literal).
Just to be clear: `[]` and `null` are the exact same thing
(null pointer, zero length). The reason to prefer `[]` over
`null` is purely for readability. The meaning is exactly the
same.
ah yes. The case I thought to was actually
```d
void test1(string s = null)
{
assert(s is null);
}
void test2(string s = "") // s is null term'ed, i.e not null
{
assert(s is null);
}
void main()
{
test1();
test2(); // fails
}
```
the rule of thumb is to use `stuff.length` as condition, always,
and not `stuff` itself, to prevent natyx, hard to find bugs.
Re: null == "" is true?
On 12.07.22 22:14, H. S. Teoh wrote:
Pedantically, no, they're not the same. You can assign null to a
pointer, but you can't assign [] to a pointer. `null` is a supertype of
`[]`.
But probably nobody actually cares about this distinction. :-D
If we're ignoring context, "null" has four characters, while "[]" has
only two. Clearly, they're not similar at all.
The context was arrays, not pointers. `void f(T[] a = null) {}` has
exactly the same meaning as `void f(T[] a = []) {}`.
Re: null == "" is true?
On Tue, Jul 12, 2022 at 07:55:46PM +, ag0aep6g via Digitalmars-d-learn wrote: > On Tuesday, 12 July 2022 at 19:02:01 UTC, user1234 wrote: > > On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote: > [...] > > > Do not rely on this, however; > > > > Absolutely. I'd like to add: especially as default parameter value > > that's an array. Never use null. use `[]` (empty array literal). > > Just to be clear: `[]` and `null` are the exact same thing (null > pointer, zero length). The reason to prefer `[]` over `null` is purely > for readability. The meaning is exactly the same. Pedantically, no, they're not the same. You can assign null to a pointer, but you can't assign [] to a pointer. `null` is a supertype of `[]`. But probably nobody actually cares about this distinction. :-D T -- By understanding a machine-oriented language, the programmer will tend to use a much more efficient method; it is much closer to reality. -- D. Knuth
Re: How can I match every instance of a template type (struct)?
On Tuesday, 12 July 2022 at 13:34:42 UTC, rempas wrote: [...] Thank you all for your help! @Ali Çehreli That makes things much much easier! I'll look at the source code in "traits.d" and I'll copy-paste it into my library ;)
Re: null == "" is true?
On Tuesday, 12 July 2022 at 19:02:01 UTC, user1234 wrote: On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote: [...] Do not rely on this, however; Absolutely. I'd like to add: especially as default parameter value that's an array. Never use null. use `[]` (empty array literal). Just to be clear: `[]` and `null` are the exact same thing (null pointer, zero length). The reason to prefer `[]` over `null` is purely for readability. The meaning is exactly the same.
curl: byChunkAsync and onProgress
Hello everyone! How to track file download with byChunkAsync? I couldn't think of a way, and onProgress doesn't work for obvious reasons. Any ideas other than writing an analogue of byChunkAsync (I looked at the source code and realized that I couldn't do it)?
Re: Background thread, async and GUI (dlangui)
On Tuesday, 12 July 2022 at 19:25:42 UTC, Ali Çehreli wrote:
On 7/12/22 11:47, Bagomot wrote:
> I now have a couple more questions about `Task`:
> 1) How to run a non-static class method through `task`?
> 2) How to use `taskPool` to run a series of tasks of the same
type (from
> question 1)?
As a friendly reminder, these questions could be more useful in
a separate forum thread. :)
import std.stdio;
import std.parallelism;
import std.algorithm;
import std.range;
interface Animal {
string song();
}
class Dog : Animal {
string voice_;
this(string voice) {
this.voice_ = voice;
}
string song() {
return voice_ ~ " " ~ voice_;
}
}
void main() {
auto voices = [ "hav", "woof", "bark", "gav", "grrr" ];
auto dogs = voices.map!(voice => new Dog(voice)).array;
// No need to specify this; just being silly...
const workerCount = totalCPUs + 7;
auto tp = new TaskPool(workerCount);
scope (exit) tp.finish();
// a) Classic foreach loop
foreach (dog; tp.parallel(dogs)) {
writeln(dog.song);
}
// b) Adding individual tasks (could be a foreach loop)
dogs.each!(dog => tp.put(task!(d => writeln(d.song))(dog)));
}
Ali
Thank you! I will take into account the advice and will not
inflate the forum thread.
Re: Background thread, async and GUI (dlangui)
On 7/12/22 11:47, Bagomot wrote:
> I now have a couple more questions about `Task`:
> 1) How to run a non-static class method through `task`?
> 2) How to use `taskPool` to run a series of tasks of the same type (from
> question 1)?
As a friendly reminder, these questions could be more useful in a
separate forum thread. :)
import std.stdio;
import std.parallelism;
import std.algorithm;
import std.range;
interface Animal {
string song();
}
class Dog : Animal {
string voice_;
this(string voice) {
this.voice_ = voice;
}
string song() {
return voice_ ~ " " ~ voice_;
}
}
void main() {
auto voices = [ "hav", "woof", "bark", "gav", "grrr" ];
auto dogs = voices.map!(voice => new Dog(voice)).array;
// No need to specify this; just being silly...
const workerCount = totalCPUs + 7;
auto tp = new TaskPool(workerCount);
scope (exit) tp.finish();
// a) Classic foreach loop
foreach (dog; tp.parallel(dogs)) {
writeln(dog.song);
}
// b) Adding individual tasks (could be a foreach loop)
dogs.each!(dog => tp.put(task!(d => writeln(d.song))(dog)));
}
Ali
Re: null == "" is true?
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via
Digitalmars-d-learn wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
Because an empty string is, by default, represented by an empty
slice of the null pointer.
Do not rely on this, however;
Absolutely. I'd like to add: especially as default parameter
value that's an array. Never use null. use `[]` (empty array
literal).
Re: null == "" is true?
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote: Because an empty string is, by default, represented by an empty slice of the null pointer. Do not rely on this, however; it's possible sometimes to get an empty string that isn't null, e.g., if you incrementally shrink a slice over a string until it's empty. In that case, .ptr will not be null, but the string will still be empty. Always compare strings against "" rather than null, because the latter may not do what you think it does sometimes. This is actually 100% reliable when comparing with the `==` operator because two empty strings always compare equal with `==`, regardless of what they point to. string s = "hello"; string empty1 = s[0 .. 0]; string empty2 = s[1 .. 1]; assert(empty1 == null); assert(empty2 == null); assert(empty1 == empty2); The real problem is that `s == null` looks like it does one thing (test for a null pointer) while actually doing something slightly different (test for an empty string).
Re: How can I match every instance of a template type (struct)?
On Tuesday, 12 July 2022 at 15:30:03 UTC, Ali Çehreli wrote:
An alternative:
https://dlang.org/phobos/std_traits.html#isInstanceOf
This is a really good alternative. Because I used to have to
write longer. Thanks, the LOG thing is better now:
```d
struct LOG(T...) {
T[0] id;
T[1] data;
}
void main()
{
auto obj = //make_test(20);/*
make_test('T');//*/
alias typ = //typeof(obj);/*
LOG!(int, char);//*/
"Type: ".write;
if(isInstanceOf!(LOG, typ)/*
is(typ : Template!Args,
alias Template, Args...)//*/
) "LOG".writeln;
}
```
SDB@79
Re: Background thread, async and GUI (dlangui)
On Monday, 11 July 2022 at 09:32:46 UTC, evilrat wrote:
curl.onProgress = delegate int(size_t dltotal, size_t dlnow,
size_t ultotal, size_t ulnow)
{
// even though onProgress can be run in another thread this
delegate will be run on next UI tick
executeInUiThread( (){
progressBar.setProgress(dlnow/dltotal * 100); } );
return 0;
};
curl.perform();
}
```
Yes. Thanks, I did just that for the download.
I now have a couple more questions about `Task`:
1) How to run a non-static class method through `task`?
2) How to use `taskPool` to run a series of tasks of the same
type (from question 1)?
Re: null == "" is true?
On 7/12/22 10:11, Steven Schveighoffer wrote:
> The algorithm to compare *any* arrays is first verify the lengths are
> the same. Then for each element in the array, compare them. Since there
> are 0 elements in both the empty string and the null string, they are
> equal.
Checking .empty() covered all of my uses cases. I think... :)
void foo(string s) {
import std.array;
assert(s.empty);
}
void main() {
// Literal null
foo(null);
// Zero-length and pointing at '\0'
foo("");
// Fresh
string a;
foo(a);
// Shrunk
string b = "hello";
b.length = 0;
assert(b.ptr !is null);
foo(b);
}
Ali
Re: null == "" is true?
On 7/12/22 12:40 PM, H. S. Teoh wrote: Because an empty string is, by default, represented by an empty slice of the null pointer. No, it's not a null pointer. It's a pointer to a zero-character. But it is indeed an empty slice. -Steve
Re: null == "" is true?
On 7/12/22 12:27 PM, Antonio wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
A string is not exactly a reference type. It's a length and a pointer.
This can be confusing to newcomers, especially ones that come from
languages that treat arrays and strings as object references.
`null` as an array with `0` length and `null` pointer.
`""` is an array with `0` length and a pointer to a zero character (not
`null`).
The algorithm to compare *any* arrays is first verify the lengths are
the same. Then for each element in the array, compare them. Since there
are 0 elements in both the empty string and the null string, they are equal.
-Steve
Re: null == "" is true?
On Tuesday, 12 July 2022 at 16:40:38 UTC, H. S. Teoh wrote:
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via
Digitalmars-d-learn wrote:
It works
```d
void main()
{
assert(null=="");
}
```
why?
Because an empty string is, by default, represented by an empty
slice of the null pointer.
Do not rely on this, however; it's possible sometimes to get an
empty string that isn't null, e.g., if you incrementally shrink
a slice over a string until it's empty. In that case, .ptr will
not be null, but the string will still be empty. Always
compare strings against "" rather than null, because the latter
may not do what you think it does sometimes.
T
Yup, always compare the string with "". I have had this kind of
problem a bunch of times, comparing it with null but it is not
actually null
Re: null == "" is true?
On Tue, Jul 12, 2022 at 04:27:44PM +, Antonio via Digitalmars-d-learn wrote:
> It works
>
> ```d
> void main()
> {
>assert(null=="");
> }
> ```
>
> why?
Because an empty string is, by default, represented by an empty slice of
the null pointer.
Do not rely on this, however; it's possible sometimes to get an empty
string that isn't null, e.g., if you incrementally shrink a slice over a
string until it's empty. In that case, .ptr will not be null, but the
string will still be empty. Always compare strings against "" rather
than null, because the latter may not do what you think it does
sometimes.
T
--
One reason that few people are aware there are programs running the internet is
that they never crash in any significant way: the free software underlying the
internet is reliable to the point of invisibility. -- Glyn Moody, from the
article "Giving it all away"
null == "" is true?
It works
```d
void main()
{
assert(null=="");
}
```
why?
Re: How can I match every instance of a template type (struct)?
On 7/12/22 06:34, rempas wrote:
>static if (is(typeof(obj) == Test)) { printf("YES!!!\n"); }
An alternative:
import std.traits;
static if (isInstanceOf!(Test, typeof(obj))) { printf("YES!!!\n"); }
https://dlang.org/phobos/std_traits.html#isInstanceOf
Ali
Re: How to dynamically calculate an index?
On Tuesday, 12 July 2022 at 14:55:47 UTC, anonymouse wrote:
I've tried using a foreach loop to achieve this but failed
miserably.
--anonymouse
Wait, I think I've got it.
This little snippet does the trick:
int index;
foreach(i, v; a) {
int t = v;
foreach(d; dims[i+1 .. a.length])
tmp *= d;
index += tmp;
}
Thanks, everyone.
--anonymouse
Re: How can I match every instance of a template type (struct)?
On Tuesday, 12 July 2022 at 13:56:11 UTC, rempas wrote:
On Tuesday, 12 July 2022 at 13:37:49 UTC, ag0aep6g wrote:
static if (is(typeof(obj) == Test!T, T)) {
printf("YES!!!\n"); }
Haah? Ok, what does this work anyway? I thought you needed
parenthesis for more than 1 templated arguments...
The second `T` is not a template argument. It's an operand of the
"IsExpression".
You can read more about those expressions here:
https://dlang.org/spec/expression.html#is-parameter-list
Re: How to dynamically calculate an index?
On Tuesday, 12 July 2022 at 14:17:36 UTC, ananymouse wrote:
Been racking my brain on this for hours. Please point me in the
right direction.
Thanks,
--anonymouse
My current implementation:
``` d
// Allow for indexing to read a value, e.g a[0,0,0]
T opIndex(A...)(A a) {
static if(a.length == 3) {
int index = a[0] * dims[1] * dims[2] + a[2];
return data[index];
}
else static if(a.length == 2) {
return data[a[0] * dims[1] + a[1];
}
else static if (a.length == 1) {
return data[0]
}
assert(0);
}
```
This does not scale well. Therefore, I'd like to change the first
if statement to work with any array.length > 2 and dynamically
generate the code. I've tried using a foreach loop to achieve
this but failed miserably.
--anonymouse
Re: How can I match every instance of a template type (struct)?
On Tue, Jul 12, 2022 at 01:56:11PM +, rempas via Digitalmars-d-learn wrote:
> On Tuesday, 12 July 2022 at 13:37:49 UTC, ag0aep6g wrote:
> >
> > static if (is(typeof(obj) == Test!T, T)) { printf("YES!!!\n"); }
>
> Haah? Ok, what does this work anyway? I thought you needed
> parenthesis for more than 1 templated arguments...
If your template has multiple parameters, just write:
static if (is(typeof(obj) == Test!Args, Args...)) ...
T
--
Don't drink and derive. Alcohol and algebra don't mix.
How to dynamically calculate an index?
Given a 3D matrix of shape[3, 5, 7] that is implemented using a 1D array, I can calculate the index of any element (e.g. [1, 0, 6]) as follows: index = 1 * 5 * 7 + 0 * 7 + 6 In general, if I have a K x L x M matrix, I can access index[i][j][k] by calculating i*L*M + j*M + k to yield the index. Likewise, when working with a 4D matrix[h][i][j][k], I can achieve the same by calculating h*L*M*N + i*M*N + j*N + k. If I have both the index ([i, j, k]) and the shape ([K, L, M]) stored in two separate arrays of equal length, how could I dynamically generate the above calculations for any two such arrays of arbitrary length 3 or greater? Been racking my brain on this for hours. Please point me in the right direction. Thanks, --anonymouse
Re: How can I match every instance of a template type (struct)?
On Tuesday, 12 July 2022 at 13:37:49 UTC, ag0aep6g wrote:
static if (is(typeof(obj) == Test!T, T)) {
printf("YES!!!\n"); }
Haah? Ok, what does this work anyway? I thought you needed
parenthesis for more than 1 templated arguments...
Re: How can I match every instance of a template type (struct)?
On 12.07.22 15:34, rempas wrote:
extern (C) void main() {
auto obj = make_test(20);
static if (is(typeof(obj) == Test)) { printf("YES!!!\n"); }
}
static if (is(typeof(obj) == Test!T, T)) { printf("YES!!!\n"); }
How can I match every instance of a template type (struct)?
I want to do something like the following:
```d
import core.stdc.stdio;
Test!(T, "mode1") make_test(T)(T data) {
Test!(T, "mode1") t = { data };
return t;
}
struct Test(T, string mode = "ref") { T data; }
extern (C) void main() {
auto obj = make_test(20);
static if (is(typeof(obj) == Test)) { printf("YES!!!\n"); }
}
```
So, I just want to be able check if a variable is a given struct
type. I also want to be able to do something similar but having a
(templated) function that returns a struct type without having to
be limited to a specific initialization of it.
Obviously, the given code will not work. It will result to the
following error message:
```
Error: template struct `test.Test(T, string mode = "ref")` is
used as a type without instantiation; to instantiate it use
`Test!(arguments)`
```
Any ideas? Also, like in every question I make, the solution must
be "betterC" compatible.
**CLARIFICATION**
I have a bad feeling that the post is not clear enough, so I'll
save us all some time by making it clear.
I know I can do this:
```d
static if (is(typeof(obj) == Test!(int, "mode1"))) {
printf("YES!!!\n"); }
```
And it will work but this is not what I want. I want to much
EVERY "Test" type regardless of what's the value
of its templated arguments.
Re: vectorization of a simple loop -- not in DMD?
On Tuesday, 12 July 2022 at 12:47:26 UTC, bauss wrote: Of course if you're alone it doesn't matter, but if it's a larger project that will have multiple maintainers then it will never work and will tarnish the project entirely. That's true, i work solo on my project so it doesn't bother me It definitely is something hard to balance But one sure thing is that's something you have to monitor every so often, if you don't, then you end up with poor build speed that's harder to fix I wonder if DMD/LDC/GDC have built in tools to profile and track performance Rust have this: https://perf.rust-lang.org/ Maybe we need to do something similar
Re: vectorization of a simple loop -- not in DMD?
On Monday, 11 July 2022 at 21:46:10 UTC, IGotD- wrote: Just depreciate the the DMD backend, it's just not up to the task anymore. Just deprecate LDC and GDC. They compile slowly and are unlikely to ever deliver fast compile times, due to their design. Some people say they like it because it is fast, yes it is fast because it doesn't do much. If it produces code that's fast enough, there is zero benefit to using a different compiler. If you use a development workflow that's heavy on compilation, stay away from LDC or GDC until you're done - and even then, you might not have any motivation to use either.
Re: vectorization of a simple loop -- not in DMD?
On Tuesday, 12 July 2022 at 10:32:36 UTC, ryuukk_ wrote: How do i achieve fast compile speed (results above were on windows, on linux i get much faster results): I maintain healthy project management: This - Imports of std: i simply don't, and i copy/paste functions i need - I avoid dub packages, instead i prefer import/src path, and i chery pick what i need And this. Can be argued to not be healthy project management. Of course if you're alone it doesn't matter, but if it's a larger project that will have multiple maintainers then it will never work and will tarnish the project entirely.
Re: How to debug thread code
On Sunday, 10 July 2022 at 21:27:08 UTC, Hipreme wrote: "Your app has entered a break state, but there is no code to show because all threads were executing external code (typically system or framework code)." Open the threads window and click on threads there, their stack will be in the stack window.
Re: vectorization of a simple loop -- not in DMD?
How do i achieve fast compile speed (results above were on windows, on linux i get much faster results): I maintain healthy project management: - Templates ONLY when necessary and when the cost is worth the time saved in the long term - this is why i try to lobby for builtin tagged union instead of std.sumtype - Dependencies, only dependency WITHOUT dependencies, and i keep them at the bare minimum! - Imports of std: i simply don't, and i copy/paste functions i need - I avoid dub packages, instead i prefer import/src path, and i chery pick what i need
Re: vectorization of a simple loop -- not in DMD?
On Tuesday, 12 July 2022 at 07:58:44 UTC, bauss wrote: You don't think this difference is huge? DMD is over 2x as fast. I think that DMD having more than 10x faster compilation speed in ryuukk_'s project shows that there is likely either a misconfiguration in DUB build setup or some other low hanging fruit for LDC. This looks like an opportunity to easily improve something in a major way.
Re: vectorization of a simple loop -- not in DMD?
On Tuesday, 12 July 2022 at 07:06:37 UTC, Siarhei Siamashka wrote: ``` real0m34.371s user0m32.883s sys 0m1.488s ``` ``` real0m14.078s user0m12.941s sys 0m1.129s ``` Is there an open source DUB package, which can be used to reproduce a huge build time difference between LDC and DMD? You don't think this difference is huge? DMD is over 2x as fast.
Re: vectorization of a simple loop -- not in DMD?
On Monday, 11 July 2022 at 22:16:05 UTC, ryuukk_ wrote: LDC clean full rebuild ``` $ time dub build -f --compiler=ldc2 Performing "debug" build using ldc2 for x86_64. game ~master: building configuration "desktop"... Linking... real0m18.033s user0m0.000s sys 0m0.015s ``` DMD clean full rebuild ``` $ time dub build -f --compiler=dmd Performing "debug" build using dmd for x86_64. game ~master: building configuration "desktop"... Linking... real0m1.348s user0m0.031s sys 0m0.015s ``` BTW, I'm very curious about investigating the reason for such huge build time difference, but can't reproduce it on my computer. For example, compiling the DUB source code itself via the same DUB commands only results in DMD showing roughly twice faster build times (which is great, but nowhere close to ~13x difference): ``` $ git clone https://github.com/dlang/dub.git $ cd dub ``` ``` $ time dub build -f --compiler=ldc2 Performing "debug" build using ldc2 for x86_64. dub 1.29.1+commit.38.g7f6f024f: building configuration "application"... Serializing composite type Flags!(BuildRequirement) which has no serializable fields Serializing composite type Flags!(BuildOption) which has no serializable fields Linking... real0m34.371s user0m32.883s sys 0m1.488s ``` ``` $ time dub build -f --compiler=dmd Performing "debug" build using dmd for x86_64. dub 1.29.1+commit.38.g7f6f024f: building configuration "application"... Serializing composite type Flags!(BuildRequirement) which has no serializable fields Serializing composite type Flags!(BuildOption) which has no serializable fields Linking... real0m14.078s user0m12.941s sys 0m1.129s ``` Is there an open source DUB package, which can be used to reproduce a huge build time difference between LDC and DMD?
Re: vectorization of a simple loop -- not in DMD?
On Monday, 11 July 2022 at 22:16:05 UTC, ryuukk_ wrote: I use D because DMD compiles my huge project in ~1 second (full clean rebuild) It is a competitive advantage that many languages doesn't have The other programming languages typically use an interpreter for quick iterations and rapid development. For example, Python programming language has CPython interpreter, PyPy Just-in-Time compiler and Cython optimizing static compiler (not perfect right now, but shows a lot of promise). D still has a certain advantage over interpreters, because DMD generated code is typically only up to twice slower than LDC generated code. If the x86 architecture stops being dominant in the future and gets displaced by ARM or RISC-V, then this may become a problem for DMD. But we'll cross that bridge when we get there.
