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.
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
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: 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 2:42 AM, 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. "alias this" is used for implicit casting. BTW, it's implicit. There's an 'i' there! I did not talk about builtin types. Ok - but I think it would be clearer if the statement added "for user defined types".
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
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 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 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
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
"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
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
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