Re: Can we rely on LDC respecting "align" (for avx) ??
On Wednesday, 8 September 2021 at 04:43:31 UTC, Tejas wrote:
On Wednesday, 8 September 2021 at 04:32:50 UTC, james.p.leblanc
wrote:
[...]
Yes you are correct (to my understanding)
DMD only respects `align` keyword upto the value 16,ie, until
`align(16)`, the code behaves the way you expect it to. It is
100% a bug(don't have the link on me right now)
Try the following code on DMD, then LDC. See for yourself
```d
import std.stdio:writeln;
void main()
{
align(16) int[100] a;
align(1024) int[100] b;
writeln(cast(ulong)[0] % 16);
writeln(cast(ulong)[0] % 1024);
}
```
Here's the link:
https://issues.dlang.org/show_bug.cgi?id=16098
Re: Can we rely on LDC respecting "align" (for avx) ??
On Wednesday, 8 September 2021 at 04:32:50 UTC, james.p.leblanc
wrote:
Dear All,
In searching through the forum archives (going back to 2013,
2016
etc), and experiments, it **appears to me** that LDC does indeed
respect the standard "align" properties. (Meaning: proper
alignment
for using AVX with static arrays can be guaranteed).
Experiments (and forum discussions) also lead me to believe that
DMD does NOT respect this alignment.
So, what is the "official status" of AVX alignment
possibilities?
Succinctly:
1) Can we truly rely on LDC's alignment for AVX ?
2) Is DMD presently **not** respecting alignment? (Or have I
misunderstood?)
This has important impact on performance of numerical
computations.
Thanks for all illumination!
James
Yes you are correct (to my understanding)
DMD only respects `align` keyword upto the value 16,ie, until
`align(16)`, the code behaves the way you expect it to. It is
100% a bug(don't have the link on me right now)
Try the following code on DMD, then LDC. See for yourself
```d
import std.stdio:writeln;
void main()
{
align(16) int[100] a;
align(1024) int[100] b;
writeln(cast(ulong)[0] % 16);
writeln(cast(ulong)[0] % 1024);
}
```
Can we rely on LDC respecting "align" (for avx) ??
Dear All, In searching through the forum archives (going back to 2013, 2016 etc), and experiments, it **appears to me** that LDC does indeed respect the standard "align" properties. (Meaning: proper alignment for using AVX with static arrays can be guaranteed). Experiments (and forum discussions) also lead me to believe that DMD does NOT respect this alignment. So, what is the "official status" of AVX alignment possibilities? Succinctly: 1) Can we truly rely on LDC's alignment for AVX ? 2) Is DMD presently **not** respecting alignment? (Or have I misunderstood?) This has important impact on performance of numerical computations. Thanks for all illumination! James
Re: Curious effect with traits, meta, and a foreach loop ... mystifies me.
On Tuesday, 7 September 2021 at 17:33:31 UTC, Adam D Ruppe wrote:
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
If you want to do a runtime lookup, you need to separate the
two pieces. This pattern works:
switch(runtime_index) {
foreach(i, val; item.tupleof)
case i:
// use val
}
So the switch is at runtime but the loop and cases are all
known at compile time.
Adam,
Thanks for the very fast, and very thorough explanation. I
especially
appreciate the fact that you seem to have predicted where my
thoughts
were heading with my experiments ...
The "switch(runtime_index)" snippet will come in handy ...
What I would **REALLY** like is to be able to do (but I think
this is
impossible) would be to "dig out" the needed "x" array depending
on
which one of them suits my alignment needs. (Yes, I am still
playing
with avx2 ideas ...).
What I mean by "dig out" the needed "x" is: if I could
alias/enum/
or someother trick be then able just to use that "x" as a simple
static array.
(I doubt this is possible ... but ?).
Thanks again, Keep Warm in Upstate!
James
Re: Curious effect with traits, meta, and a foreach loop ... mystifies me.
On Tuesday, 7 September 2021 at 17:24:34 UTC, james.p.leblanc
wrote:
// this fails with: "Error: variable 'i' cannot be read at
compile time
//
// foreach( i ; 0 .. 3 ){
//ptr = u.tupleof[i].x.ptr;
tuples only exist at compile time, so you'd have to make sure the
indexing is itself compile time. Consider that unlike an array,
each index might give a different type, so like what would
struct A { int a; string b; }
A a;
int idx;
some_type c = a.tupleof[idx];
Which type is some_type? Is it int or string? Impossible to tell
since it doesn't know what idx is. So idx needs to be known at
compile time so it knows which type you get there.
The reason why it works here:
foreach( i, val ; u.tupleof ){
is because the compiler knows you're specifically looping over
the tupleof, so it expands it and knows what i is going to be at
compile time. If you assigned that i to an intermediate variable
then it would break this direct knowledge and it doesn't compile
again.
If you want to do a runtime lookup, you need to separate the two
pieces. This pattern works:
switch(runtime_index) {
foreach(i, val; item.tupleof)
case i:
// use val
}
So the switch is at runtime but the loop and cases are all known
at compile time.
Curious effect with traits, meta, and a foreach loop ... mystifies me.
Dear All,
In playing with some reflection and meta programming, this
curiosity
appeared.
Does someone understand what is happening? I would appreciate
learning
about it if possible. Enclosed code snippet tells the story:
```d
import std.stdio;
import std.traits;
import std.meta;
struct S0{ double[3] x; };
struct S1{ double junk0 ; double[3] x; };
union U { S0 s0; S1 s1; }
void main(){
U u;
double* ptr;
u.s0.x = [ 0.0, 0.1, 0.3 ];
u.s1.x = [ 1.0, 1.1, 1.3 ];
writeln("typeid( u.tupleof): ",typeid( u.tupleof ) );
writeln("typeid( u.tupleof[0]): ", typeid( u.tupleof[0] ) );
writeln("typeid( u.tupleof[0].x): ", typeid( u.tupleof[0].x )
);
writeln();
// indeed both tuples exist
writeln("u.tupleof[0].x.ptr: ", u.tupleof[0].x.ptr );
writeln("u.tupleof[1].x.ptr: ", u.tupleof[1].x.ptr );
// this is fine (notice that 'val' is never used
foreach( i, val ; u.tupleof ){
ptr = u.tupleof[i].x.ptr;
writeln("ptr: ", ptr);
}
// this fails with: "Error: variable 'i' cannot be read at
compile time
//
// foreach( i ; 0 .. 3 ){
//ptr = u.tupleof[i].x.ptr;
//writeln("ptr: ", ptr);
// }
}
```
Best Regards,
James
Re: Looking to get typeof parseXML return value
On Tuesday, 7 September 2021 at 05:00:50 UTC, Chris Piker wrote:
On Tuesday, 7 September 2021 at 04:40:25 UTC, jfondren wrote:
typeof(parseXML!simpleXML("")) xml;
Hey, I like this trick!
I was wondering what to use for the const(char)[] variable in
the typeof statement. It's blindingly obvious in retrospect.
Wouldn't work so well if there wasn't a literal for the input
data range type.
You can always use the `.init` value of a type (in this case,
`(const(char)[]).init`) as a dummy value for things like this.
Re: Looking to get typeof parseXML return value
On Tuesday, 7 September 2021 at 08:27:33 UTC, JN wrote: On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote: Like almost all new users to D I'm tripping over how to save and pass around variables since nothing has an understandable type anymore and you can't use "auto" for *class member* storage types. I struggle with this often. Templated types that pretty much require you to use auto look nice on the paper and in samples, but once you try to integrate them into a larger project, it can get messy. I agree with this, that's why I avoid templates anywhere they're not necessary and wrap everything in structs/classes with little to no template parameters. Templates gets messy soon because you often end up overengineering trivial problems.
Re: Phobos Unittest
On Friday, 3 September 2021 at 23:39:44 UTC, Per Nordlöw wrote: When is a phobos unittest supposed to be qualified with version `(StdUnittest)`? Ideally, always? I don't see that their current use is consistenly following a rule. If so, is the purpose of its presence to reduce the burden of the compiler when the application using phobos is compiled with -unittest? (edited). For reference, see my previous attempt at making dmd more flexible at compiling unittests at https://github.com/dlang/dmd/pull/6375
Re: Looking to get typeof parseXML return value
On Tuesday, 7 September 2021 at 04:13:08 UTC, Chris Piker wrote: Like almost all new users to D I'm tripping over how to save and pass around variables since nothing has an understandable type anymore and you can't use "auto" for *class member* storage types. I struggle with this often. Templated types that pretty much require you to use auto look nice on the paper and in samples, but once you try to integrate them into a larger project, it can get messy.
