Re: Release vibe.d 0.7.27
On Sunday, 14 February 2016 at 08:17:34 UTC, Sönke Ludwig wrote: Am 11.02.2016 um 00:24 schrieb sigod: Did some benchmarks between `std.net.curl.get` and `vibe.http.client.requestHTTP`. Only GET requests. 100 requests, ~1.4mb file: curl total: 131304, average: 1 sec and 313 ms vibe total: 21975, average: 219 ms 52 different files: curl total: 24851, average: 477 ms vibe total: 11290, average: 217 ms 50 different files (excluded 2 of the biggest ones): curl total: 20892, average: 417 ms vibe total: 11368, average: 227 ms (Looks like `std.net.curl.get` doesn't like if file is bigger than ~1mb.) Is vibe.d's API really that fast? Or am I doing something wrong? How fast was the network connection in that case? Could it make a difference if keep-alive connections are used or not? Were the requests done in parallel or in sequence? I certainly wouldn't expect curl to be slower for a simple sequential transfer of a single file, but who knows. https://gist.github.com/sigod/c78c61ac6118fa9fda26 I'm getting something like this: HTTPS: curl total: 23401, average: 458ms vibe total: 12136, average: 237ms HTTP: curl total: 5577, average: 278ms vibe total: 4268, average: 213ms Windows 7 x86, dmd 2.070.0
Re: Ddb needs a maintainer
On Sun, 14 Feb 2016 12:48:49 +0100, Jacob Carlborg wrote: > On 2016-02-14 00:32, Dicebot wrote: > >> Ideally ddb should be built on top of ddbc wrapping it into >> fiber-friendly async API but I don't know if this is possible with ddbc >> design. > > It looks like libpg has support for asynchronous calls [1] but ddbc does > not use them. Also, although libpg provides asynchronous calls I'm not > sure if that automatically means it will be compatible with the IO model > used by vibe. If you have asynchronous calls that you can poll, you can make it work with vibe.d, albeit awkwardly. (Start request, poll+yield, return when there's a result.) If you only have synchronous calls, you'd have to introduce IO threads and synchronization. It's awkward to make things compatible with vibe.d and Phobos IO. The APIs are rather dissimilar, so you can't just, for instance, have different imports under a version() block.
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 17:30:33 UTC, Kai Nacke wrote: Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Don't miss to check if your preferred system is supported by this release. We also have a Win64 compiler and PREVIEW of a Win32 compiler available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org Regards, Kai Congrats! Awesome that Win32 received work. The Windows versions worked out of the box this time.
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 17:30:33 UTC, Kai Nacke wrote: Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Regards, Kai congrats! what is actually the difference on wheter i build with LLVM 3.5 or 3.8? in other words, what influence does the ldc version have?
Re: LDC 0.17.0 has been released!
On Sunday, 14 February 2016 at 20:55:40 UTC, Dicebot wrote: On 02/14/2016 07:30 PM, Kai Nacke wrote: As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org https://www.archlinux.org/packages/community/x86_64/ldc https://www.archlinux.org/packages/community/i686/ldc Thanks!
Re: DigitalWhip
On Sunday, 14 February 2016 at 18:07:00 UTC, artemalive wrote: Thanks. Good suggestion. I'll check if the version information can be retrieved automatically for all compilers. If that's the case then version information will be added soon. I would simply print the output of "--version" for all compilers. But version information will help with archiving/sharing results. Exactly.
Re: DigitalWhip
On Sunday, 14 February 2016 at 19:29:54 UTC, Vladimir Panteleev wrote: I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits. But nobody would write a render-engine in Go. Most likely you would write it for GPU support and certainly use SIMD heavily. That's what current engines do. So if it is a benchmark, then it makes perfect sense to use the same feature set for all languages. But optimization should be set to the highest possible, including whole program optimization where available. It's a benchmark...
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:31:37 UTC, artemalive wrote: From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". We (LDC team) should clarify this description. In D2, -release does not disable bounds-checking for @safe code anymore. -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;) I'm not convinced that it makes for a good comparison to use different optimization settings for one of the compilers… — David
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. I agree - but not for all situations. Sometimes it's fine to let programs crash, if performance is important, and the environment is configured to handle that gracefully, or where there is no risk of data loss, such as video games. I think that in the context of a render farm, disabling bounds checking is completely reasonable. Bugs will manifest as crashes or rendering artifacts, and there is no risk of code execution exploits.
Re: DigitalWhip
On Sunday, 14 February 2016 at 18:12:03 UTC, David Nadlinger wrote: On Sunday, 14 February 2016 at 17:31:37 UTC, artemalive wrote: From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". We (LDC team) should clarify this description. In D2, -release does not disable bounds-checking for @safe code anymore. -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;) I'm not convinced that it makes for a good comparison to use different optimization settings for one of the compilers… — David Sure, we need the same optimization for all compilers if there is direct correspondence. Your pull request has been merged.
Re: Ddb needs a maintainer
On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote: On 2016-02-14 12:48, Jacob Carlborg wrote: It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example. Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you? yes, it is for sure ok for me. It can be a good start. I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it.
Re: Ddb needs a maintainer
my five cents on that topic... @Eugene: From my point of view, it would be great if you could bring in all your ideas, wishes, changes, additions and new stuff into vibe_d and help to grow and extend it and make it more usable... Don't get me wrong, I thinks it's great if developers have various choices in general to pick from, but especially in Dlang "core tools" some of the existing stuff needs more contributors/help... like vibe_d, dub (both from Sönke & team) dfmt, ... You and Sönke share the same native language (German) and also the same time zone (Munich/Berlin)... and as it seems also the same interest in "Web stuff/Frameworks", right? It shouldn't be that difficult for you guys to alighn and team-up to build an even better "Dlang Web tools/Framework development team"... My native language is Russian, but my German is anyway better than my English, it's true :) Yes, I actually understand your point. I thought about it already and it could be really more productive. I think I have to look in vibe more closely. Maybe I'll just look into open issues on github, maybe I'll be able to find a few easy issues, I could try to fix - it could be the best way for me to get know vibe.d internally better.
LDC 0.17.0 has been released!
Hi everyone, LDC 0.17.0, the LLVM-based D compiler, is available for download! This release is based on the 2.068.2 frontend and standard library and supports LLVM 3.5-3.8. Don't miss to check if your preferred system is supported by this release. We also have a Win64 compiler and PREVIEW of a Win32 compiler available! As usual, you can find links to the changelog and the binary packages over at digitalmars.D.ldc: http://forum.dlang.org/post/cqgwucbznngoiesvb...@forum.dlang.org Regards, Kai
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote: Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. If you do, then you should use bounds checks in C++ too. (STL container.at(index) )
Re: DigitalWhip
On Saturday, 13 February 2016 at 19:26:39 UTC, artemalive wrote: On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote: Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it) These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2. What I meant to say is that the framework should output the compiler version, instead of "READY". At least for the D compilers, the performance depends so much on which version is used, that the output is unusable without version numbers, I feel.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:43:01 UTC, Ola Fosheim Grøstad wrote: On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote: Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. If you do, then you should use bounds checks in C++ too. (STL container.at(index) ) Thanks, I'll take this into account. At the moment I don't think bounds checking will be enabled. I believe that real world usage when you have a render farm is to have the fastest code possible, because any performance penalty is too costly. When new rendering algorithm is developed sometimes we run infinite rendering with all debug/logic check enabled to find the bugs. There could be even dedicated computer for this. But for production when thousands of cores do the same ray processing the fastest code is needed.
Re: DigitalWhip
On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Hi Artem, On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: https://github.com/artemalive/DigitalWhip Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test: --- Compiler relative times: clang 1.00 gcc 1.02 ldc 1.07 dmd 2.07 --- — David Hi David, I use -release option. It seems no need to disable bounds check explicitly. From ldc output: "-release - Disables asserts, invariants, contracts and boundscheck". -singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;)
Re: DigitalWhip
On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote: On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. Specific parts of the code might disable it via `.ptr`, but the command line switch is dangerous and I can't recommend anyone to use it... ever. We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C, but we'll be the ones laughing when the C program crashes with yet another buffer overrun or when it's milliseconds in execution time lead to days of debug time and a multi-million dollar business loss when an unchecked pointer leads to a security breech. Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before. Nevertheless, I have to admit I'm still on the dark side. Benchmark has some algorithms related to raytracing techniques and in this area I can't resist temptation to max performance at any cost.
Re: DigitalWhip
On Sunday, 14 February 2016 at 17:49:10 UTC, Johan Engelen wrote: On Saturday, 13 February 2016 at 19:26:39 UTC, artemalive wrote: On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote: Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it) These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2. What I meant to say is that the framework should output the compiler version, instead of "READY". At least for the D compilers, the performance depends so much on which version is used, that the output is unusable without version numbers, I feel. Thanks. Good suggestion. I'll check if the version information can be retrieved automatically for all compilers. If that's the case then version information will be added soon. The thing I don't want to do is to ask user manually to specify compiler version in config.py, since it's easy to forget to updated it and also I like to keep config.py as simple as possible. At the moment DigitalWhip is just for personal usage, the user knows which compilers are installed. But version information will help with archiving/sharing results.
Re: Ddb needs a maintainer
On 2016-02-14 00:32, Dicebot wrote: Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly async API but I don't know if this is possible with ddbc design. It looks like libpg has support for asynchronous calls [1] but ddbc does not use them. Also, although libpg provides asynchronous calls I'm not sure if that automatically means it will be compatible with the IO model used by vibe. It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. I like that ddb is completely written in D and doesn't depend on any C libraries. It's also compatible with the IO model of vibe. Ideally a database library would consist separate projects for the different database drivers. These would be fully usable on their own. The database library would build a database independent layer on top of the drivers. Everything should be compatible with the IO model of vibe. I would go with ddb and mysql-native for the drivers. [1] http://www.postgresql.org/docs/current/static/libpq-async.html -- /Jacob Carlborg
Re: Release vibe.d 0.7.27
Am 11.02.2016 um 00:24 schrieb sigod: Did some benchmarks between `std.net.curl.get` and `vibe.http.client.requestHTTP`. Only GET requests. 100 requests, ~1.4mb file: curl total: 131304, average: 1 sec and 313 ms vibe total: 21975, average: 219 ms 52 different files: curl total: 24851, average: 477 ms vibe total: 11290, average: 217 ms 50 different files (excluded 2 of the biggest ones): curl total: 20892, average: 417 ms vibe total: 11368, average: 227 ms (Looks like `std.net.curl.get` doesn't like if file is bigger than ~1mb.) Is vibe.d's API really that fast? Or am I doing something wrong? How fast was the network connection in that case? Could it make a difference if keep-alive connections are used or not? Were the requests done in parallel or in sequence? I certainly wouldn't expect curl to be slower for a simple sequential transfer of a single file, but who knows.
