Article series about patterns idioms in D
I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
On 7/11/13 11:53 PM, Benjamin Thaut wrote: I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut Well you have a typo in the first title... Andrei
Re: Article series about patterns idioms in D
I think it's a nice blog and encourage you to do more! On 7/12/2013 12:34 AM, Andrei Alexandrescu wrote: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 Well you have a typo in the first title... The same misspelling occurs repeatedly in the article, so it's not a typo. implicit also, buildin = builtin D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation.
Re: Article series about patterns idioms in D
D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation. I did talk about implict conversions between user defined types. D does not have implict construction, or implict casting like C++ does. I did not talk about builtin types. -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
On 7/12/13 3:53 AM, Benjamin Thaut wrote: I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut This sentence worries me a bit: The code shown above has been tested with dmd 2.063.2 It seems like every minor release of D works different than previous ones. Is that true? Isn't it enough to say D2? Can something be done to prevent this?
Re: Article series about patterns idioms in D
On Friday, 12 July 2013 at 09:42:28 UTC, Benjamin Thaut wrote: D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation. I did talk about implict conversions between user defined types. D does not have implict construction, or implict casting like C++ does. I did not talk about builtin types. What's about alias this?
Re: Article series about patterns idioms in D
Am 12.07.2013 17:12, schrieb Tobias Pankrath: On Friday, 12 July 2013 at 09:42:28 UTC, Benjamin Thaut wrote: D strives to prevent implict conversion between user defined types at all costs. I don't think this is true. Implicit conversions are very useful. What D prevents are implicit conversions that can result in data loss, such as integer truncation. I did talk about implict conversions between user defined types. D does not have implict construction, or implict casting like C++ does. I did not talk about builtin types. What's about alias this? Did you even read the article? -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
On Friday, 12 July 2013 at 13:26:21 UTC, Ary Borenszweig wrote: This sentence worries me a bit: The code shown above has been tested with dmd 2.063.2 It seems like every minor release of D works different than previous ones. Is that true? Isn't it enough to say D2? Can something be done to prevent this? D is still in the alpha phase of development, so things are still likely to change and break regularly. There's not much that can be done other than what's already being done, i.e. just try to implement everything and fix the major bugs as fast as possible. There's no silver bullet.
Re: Article series about patterns idioms in D
Am 12.07.2013 15:26, schrieb Ary Borenszweig: On 7/12/13 3:53 AM, Benjamin Thaut wrote: I started a small article series on D specific patterns idioms on my blog. I'm going to add more over time and hope that there are at least some in there which are not already known to everyone. You can find them here: http://3d.benjamin-thaut.de/?cat=17 Currently there are two: 1) D implict conversion idiom: http://3d.benjamin-thaut.de/?p=90 2) D templated interface idiom: http://3d.benjamin-thaut.de/?p=94 Feedback is welcome. Kind Regards Benjamin Thaut This sentence worries me a bit: The code shown above has been tested with dmd 2.063.2 It seems like every minor release of D works different than previous ones. Is that true? Isn't it enough to say D2? Can something be done to prevent this? The shown code should work all versions of D 2.0 since 2.053 (I'm using it since then). I only mentioned the version of the dmd compiler, because I previously had issues with some of my articles where someone would say but that statement is not true, it works with the current version of dmd. Kind Regards Benjamin Thaut -- Kind Regards Benjamin Thaut
Re: Article series about patterns idioms in D
Am 12.07.2013 21:00, schrieb Walter Bright: On 7/12/2013 2:42 AM, Benjamin Thaut wrote: D strives to prevent implicit conversion between user defined types at all costs. Ok - but I think it would be clearer if the statement added for user defined types. For me there is already a between user defined types in the following sentence: D strives to prevent implicit conversions between user defined types at all costs. Is that not clear enough?
Re: Article series about patterns idioms in D
On 7/12/2013 12:22 PM, Benjamin Thaut wrote: Am 12.07.2013 21:00, schrieb Walter Bright: On 7/12/2013 2:42 AM, Benjamin Thaut wrote: D strives to prevent implicit conversion between user defined types at all costs. Ok - but I think it would be clearer if the statement added for user defined types. For me there is already a between user defined types in the following sentence: D strives to prevent implicit conversions between user defined types at all costs. Is that not clear enough? It is. I was commenting from memory rather than re-reading it. My mistake.
Re: DConf 2013 Day 3 Talk 5: Effective SIMD for modern architectures by Manu Evans
Manu:
This is interesting. I didn't know about this.
I have taken a look at this page:
https://github.com/ispc/ispc
There is a free compiler binary for various operating systems:
http://ispc.github.io/downloads.html
I have tried the Windows compiler on some of the given examples
of code, and it works! And the resulting asm is excellent. Normal
compilers for the usual languages aren't able to do produce not
even nearly as good asm.
To try the code of the examples I compile like this:
ispc.exe --emit-asm stencil.ispc -o stencil.s
Or even like this to see the AVX2 asm instructions:
ispc.exe --target=avx2 --emit-asm stencil.ispc -o stencil.s
As example it compiles a function like this:
static void
stencil_step(uniform int x0, uniform int x1,
uniform int y0, uniform int y1,
uniform int z0, uniform int z1,
uniform int Nx, uniform int Ny, uniform int Nz,
uniform const float coef[4], uniform const float
vsq[],
uniform const float Ain[], uniform float Aout[]) {
const uniform int Nxy = Nx * Ny;
foreach (z = z0 ... z1, y = y0 ... y1, x = x0 ... x1) {
int index = (z * Nxy) + (y * Nx) + x;
#define A_cur(x, y, z) Ain[index + (x) + ((y) * Nx) + ((z) * Nxy)]
#define A_next(x, y, z) Aout[index + (x) + ((y) * Nx) + ((z) *
Nxy)]
float div = coef[0] * A_cur(0, 0, 0) +
coef[1] * (A_cur(+1, 0, 0) + A_cur(-1, 0, 0) +
A_cur(0, +1, 0) + A_cur(0, -1, 0) +
A_cur(0, 0, +1) + A_cur(0, 0, -1)) +
coef[2] * (A_cur(+2, 0, 0) + A_cur(-2, 0, 0) +
A_cur(0, +2, 0) + A_cur(0, -2, 0) +
A_cur(0, 0, +2) + A_cur(0, 0, -2)) +
coef[3] * (A_cur(+3, 0, 0) + A_cur(-3, 0, 0) +
A_cur(0, +3, 0) + A_cur(0, -3, 0) +
A_cur(0, 0, +3) + A_cur(0, 0, -3));
A_next(0, 0, 0) = 2 * A_cur(0, 0, 0) - A_next(0, 0, 0) +
vsq[index] * div;
}
}
To asm like (using SSE4):
pshufd $0, %xmm7, %xmm9# xmm9 = xmm7[0,0,0,0]
cmpl156(%rsp), %r8d # 4-byte Folded Reload
movups (%r14,%rdi), %xmm0
mulps %xmm6, %xmm5
pshufd $0, %xmm2, %xmm2# xmm2 = xmm2[0,0,0,0]
movq424(%rsp), %rdx
movups (%rdx,%r15), %xmm6
mulps %xmm3, %xmm2
pshufd $0, %xmm10, %xmm3 # xmm3 = xmm10[0,0,0,0]
mulps %xmm11, %xmm3
addps %xmm2, %xmm3
addps %xmm5, %xmm3
addps %xmm4, %xmm0
movslq %eax, %rax
movups (%r14,%rax), %xmm2
addps %xmm0, %xmm2
movslq %ebp, %rax
movups (%r14,%rax), %xmm0
addps %xmm2, %xmm0
mulps %xmm9, %xmm0
addps %xmm3, %xmm0
mulps %xmm6, %xmm0
addps %xmm1, %xmm0
movups %xmm0, (%r11,%r15)
jl .LBB0_5
.LBB0_6:# %partial_inner_all_outer
# in Loop: Header=BB0_4
Depth=2
movq%r13, %rbp
movl156(%rsp), %r13d# 4-byte Reload
movq424(%rsp), %r9
cmpl64(%rsp), %r8d # 4-byte Folded Reload
movq%r11, %rbx
jge .LBB0_257
# BB#7: # %partial_inner_only
# in Loop: Header=BB0_4
Depth=2
movd%r8d, %xmm0
movl84(%rsp), %r15d # 4-byte Reload
imull 400(%rsp), %r15d
pshufd $0, %xmm0, %xmm0# xmm0 = xmm0[0,0,0,0]
paddd .LCPI0_1(%rip), %xmm0
movdqa %xmm8, %xmm1
pcmpgtd %xmm0, %xmm1
movmskps%xmm1, %edi
addl68(%rsp), %r15d # 4-byte Folded Reload
leal(%r8,%r15), %r10d
Or using AVX2 (this not exactly the equievalent piece of code)
(The asm generates with AVX2 is usually significant shorter):
movslq %edx, %rdx
vaddps (%rax,%rdx), %ymm5, %ymm5
movl52(%rsp), %edx # 4-byte Reload
leal(%rdx,%r15), %edx
movslq %edx, %rdx
vaddps (%rax,%rdx), %ymm5, %ymm5
vaddps %ymm11, %ymm6, %ymm9
vaddps %ymm10, %ymm8, %ymm10
vmovups (%rax,%rdi), %ymm12
addl$32, %r15d
vmovups (%r11,%rcx), %ymm6
movq400(%rsp), %rdx
vbroadcastss12(%rdx), %ymm7
vbroadcastss8(%rdx), %ymm8
vbroadcastss(%rdx), %ymm11
vaddps %ymm12, %ymm10, %ymm10
cmpl48(%rsp), %r14d # 4-byte Folded Reload
vbroadcastss4(%rdx), %ymm12
vmulps %ymm9, %ymm12, %ymm9
vfmadd213ps %ymm9, %ymm3, %ymm11
vfmadd213ps %ymm11, %ymm8, %ymm10
vfmadd213ps %ymm10, %ymm5, %ymm7
vfmadd213ps %ymm4, %ymm6, %ymm7
vmovups %ymm7, (%r8,%rcx)
jl .LBB0_8
# BB#4:
Re: Article series about patterns idioms in D
This statement kind of worries me: It seems like every minor release of D works different than previous ones. Why would you release a version if it wasn't different from the previous? It would be nice if one could give the oldest known working compiler, but there are still changes to old behavior which means some code would have more specific compiler versions needed. Work is being done, but the issue will exist for some time so process to make it less painful is being put in place.
