Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
On Wednesday, 3 August 2016 at 20:53:59 UTC, Ilya Yaroshenko wrote: Hi all, There are two first [1] benchmarks for upcoming ndslice.algorithm [2]. Recent LDC alpha based on LLVM 3.8 and recent Mir v0.16.0-alpha3 are required. @fasmath syntax may be changed a little bit and will be simplified anyway. Keep up the good work!
Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
On Wednesday, 3 August 2016 at 22:22:19 UTC, Johan Engelen wrote: On Wednesday, 3 August 2016 at 20:53:59 UTC, Ilya Yaroshenko Dot Product: ndReduce vectorized = 3 ms, 314 μs ndReduce = 14 ms, 767 μs **That's** the difference with or without fastmath?? The first one is with @fastmath and addition execution branch for iteration in case of stride equal to 1.
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 23:23:24 UTC, Joel wrote: On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: Hi, I finally managed to compile some D code to asm.js, using Emscripten. Good work. [snip] You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html [snip] Though, it looks like the score isn't reset when you start a new game. Or, is it intended that way? Oh, I read it wrong, the score is reset. Dummy, me!
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: Hi, I finally managed to compile some D code to asm.js, using Emscripten. It had been done by one dude several years ago, but some changes in the inner workings of Emscripten (the introduction of fastcomp, also probably combined with changes in the way LDC generates LLVM bitcode) made it impossible to use the same technique. You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html The source code + toolchain deployment scripts are available on github: https://github.com/Ace17/dscripten And a blogpost explaining the technique is available here: http://code.alaiwan.org/wp/?p=103 (Spoiler: at some point, it involves lowering the source code back to C) Please let me know what you think! Interesting but a bit lame. 1. The movement should continue in the same general direction, if not exactly the same. It is impossible to avoid something that can do anything. 2. The movement shouldn't accelerate so fast, it's harder to control where you want to go when if you hold the key down a you end up on the other side of the screen. Of course, I doubt this was a game intended to be fun ;) The good news is that you have a lot of upside. Consider making a video player... replace stinking flash! Could create better websites by having more programmatic functionality, etc.. (more app like websites) The upside, from the initial looks, seems to be quite good if you go in that direction.
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: [snip] Please let me know what you think! Another thing, the sound effects are late.
Re: LDC 1.1.0-beta2 has been released!
On Wednesday, 3 August 2016 at 20:12:59 UTC, Kai Nacke wrote: Hi everyone, LDC 1.1.0-beta2, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.071.1 frontend and standard library and supports LLVM 3.5-3.9. We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM (armv7hf), now bundled with DUB. :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/nskepdckljprrxsjb...@forum.dlang.org Regards, Kai Great to see ldc catching up with dmd. :)
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: Hi, I finally managed to compile some D code to asm.js, using Emscripten. Good work. [snip] You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html [snip] Though, it looks like the score isn't reset when you start a new game. Or, is it intended that way?
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: I finally managed to compile some D code to asm.js, using Emscripten. I know virtually nothing about compilers and even less about Emscripten, but the fact that you managed to get a D game running inside a browser is plain awesome. Congratulations!
Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
On Wednesday, 3 August 2016 at 20:53:59 UTC, Ilya Yaroshenko wrote: Hi all, There are two first [1] benchmarks for upcoming ndslice.algorithm [2]. Recent LDC alpha based on LLVM 3.8 and recent Mir v0.16.0-alpha3 are required. @fasmath syntax may be changed a little bit and will be simplified anyway. Dot Product: ndReduce vectorized = 3 ms, 314 μs ndReduce = 14 ms, 767 μs **That's** the difference with or without fastmath?? (awesome work of course!) -Johan
Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
On Wednesday, 3 August 2016 at 20:53:59 UTC, Ilya Yaroshenko wrote: Hi all, There are two first [1] benchmarks for upcoming ndslice.algorithm [2]. Recent LDC alpha based on LLVM 3.8 and recent Mir v0.16.0-alpha3 are required. @fasmath syntax may be changed a little bit and will be simplified anyway. [...] Ilya: The result are awesome!! Let's make some noise: https://www.reddit.com/r/programming/comments/4w16i5/ndslicealgorithm_speed_up_your_matrix/
Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
The tests above are for double precision floating point numbers. The results for single precision are below. Dot Product (single precision): ndReduce vectorized = 2 ms, 200 μs ndReduce = 14 ms, 543 μs numeric.dotProduct, arrays = 7 ms, 208 μs numeric.dotProduct, slices = 14 ms, 414 μs zip & reduce = 43 ms, 657 μs Euclidean Distance (single precisoin): ndReduce vectorized = 2 ms, 226 μs ndReduce = 14 ms, 661 μs numeric.euclideanDistance, arrays = 14 ms, 597 μs numeric.euclideanDistance, slices = 14 ms, 581 μs zip & reduce = 46 ms, 759 μs
Re: ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
On Wednesday, 3 August 2016 at 20:53:59 UTC, Ilya Yaroshenko wrote: Update: Dot Product: zip & reduce = 74 ms, 280 μs zip & reduce = 44 ms, 57 μs Euclidean Distance: zip & reduce = 73 ms, 678 μs zip & reduce = 44 ms, 646 μs
Re: std.experimental.xml available on DUB
On Wednesday, 3 August 2016 at 09:04:30 UTC, Jacob Carlborg wrote: Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type. Well, currently you have to make that choice as developer, and there is always the BufferedLexer which should be good choice is most cases. Polymorphic design was not a goal of the project, so I think it is going to be hard to add that without sacrificing to much.
ndBenchmarks #1: ndslice.algorithm vs std.numeric vs std.algorithm
Hi all, There are two first [1] benchmarks for upcoming ndslice.algorithm [2]. Recent LDC alpha based on LLVM 3.8 and recent Mir v0.16.0-alpha3 are required. @fasmath syntax may be changed a little bit and will be simplified anyway. Dot Product: ndReduce vectorized = 3 ms, 314 μs ndReduce = 14 ms, 767 μs numeric.dotProduct, arrays = 7 ms, 260 μs numeric.dotProduct, slices = 14 ms, 782 μs zip & reduce = 74 ms, 280 μs Euclidean Distance: ndReduce vectorized = 3 ms, 668 μs ndReduce = 14 ms, 595 μs numeric.euclideanDistance, arrays = 14 ms, 463 μs numeric.euclideanDistance, slices = 14 ms, 465 μs zip & reduce = 73 ms, 678 μs [1] https://github.com/libmir/mir/tree/master/benchmarks/ndslice [2] https://github.com/dlang/phobos/pull/4652 Best regards, Ilya
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: Hi, I finally managed to compile some D code to asm.js, using Emscripten. It had been done by one dude several years ago, but some changes in the inner workings of Emscripten (the introduction of fastcomp, also probably combined with changes in the way LDC generates LLVM bitcode) made it impossible to use the same technique. You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html The source code + toolchain deployment scripts are available on github: https://github.com/Ace17/dscripten And a blogpost explaining the technique is available here: http://code.alaiwan.org/wp/?p=103 (Spoiler: at some point, it involves lowering the source code back to C) Please let me know what you think! That's awesome! Do you still know the modifications you made to compile LDC with emscripten-fastcomp? I would be interested to have a look into the "PNaCl legalization passes" problem. Regards, Kai
Running a D game in the browser
Hi, I finally managed to compile some D code to asm.js, using Emscripten. It had been done by one dude several years ago, but some changes in the inner workings of Emscripten (the introduction of fastcomp, also probably combined with changes in the way LDC generates LLVM bitcode) made it impossible to use the same technique. You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html The source code + toolchain deployment scripts are available on github: https://github.com/Ace17/dscripten And a blogpost explaining the technique is available here: http://code.alaiwan.org/wp/?p=103 (Spoiler: at some point, it involves lowering the source code back to C) Please let me know what you think!
LDC 1.1.0-beta2 has been released!
Hi everyone, LDC 1.1.0-beta2, the LLVM-based D compiler, is available for download! This BETA release is based on the 2.071.1 frontend and standard library and supports LLVM 3.5-3.9. We provide binaries for Linux, OX X, FreeBSD, Win32 & Win64, Linux/ARM (armv7hf), now bundled with DUB. :-) As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/nskepdckljprrxsjb...@forum.dlang.org Regards, Kai
Re: std.experimental.xml available on DUB
On 2016-07-30 11:26, Lodovico Giaretta wrote: Hi, I'm proud to announce that std.experimental.xml v0.1.0 is available on DUB [1]! Another question. I see that there are a couple of different lexers available. Can those be exposed with the same interface/type instead of using different types? Perhaps based on the input type. -- /Jacob Carlborg
Re: std.experimental.xml available on DUB
On 2016-08-03 09:20, Lodovico Giaretta wrote: On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote: * Does it work at CTFE? I don't think so. It would be cool if it did. I think it would at least be worth taking a couple of minutes and investigate if it does work or not. If doesn't work, what it would take to make it work. Most parts in D work at CTFE but there are some particular things that are not compatible like allocating with malloc instead of the GC. I see that allocators are used, not sure how well those work at CTFE. At least in theory the GC allocator should work. You are talking about upper/lower cases in the names, right? I will correct them in the Phobos PR. Yes, and some methods use Java style getters and setters, instead of D style properties. Example: // Java style int getFoo(); void setFoo(int foo); // D style int foo(); int foo(int foo); In D, the above can be called like: Bar bar; auto i = bar.foo; bar.foo = 3; -- /Jacob Carlborg
Re: std.experimental.xml available on DUB
On Tuesday, 2 August 2016 at 15:32:50 UTC, Jacob Carlborg wrote: * Does it work at CTFE? I don't think so. * I see that it doesn't follow the D naming conventions You are talking about upper/lower cases in the names, right? I will correct them in the Phobos PR.
