Re: D-wrappers BLAKE3 wrapping C library libblake3
On Tuesday, 19 March 2024 at 15:38:40 UTC, Ben Jones wrote: On Tuesday, 19 March 2024 at 08:40:37 UTC, Per Nordlöw wrote: On Tuesday, 19 March 2024 at 08:35:55 UTC, Per Nordlöw wrote: I just added a D implementation to dmd (https://github.com/dlang/dmd/blob/master/compiler/src/dmd/common/blake3.d) which doesn't support streaming, so is probably somewhat simpler/smaller, in case that's useful Use, that's the reason why added blake3-d. The function, testVector in DMD can be made static, btw.
Re: D-wrappers BLAKE3 wrapping C library libblake3
On Tuesday, 19 March 2024 at 08:35:55 UTC, Per Nordlöw wrote: - Compliant with std.digest. - Current compiles C libraries directly for maximum performance. - Might need some adjustments with compiler flags. See https://code.dlang.org/packages/blake3-d. Please see details on the building of the wrapped C library using cmake and make. Probably needs some TLC for platform-independence. I just realized that dub doesn't work with git submodules. Shall I include a git clone in the provisioning script or simply copy (vendor) BLAKE3/c into the repo for now?
D-wrappers BLAKE3 wrapping C library libblake3
- Compliant with std.digest. - Current compiles C libraries directly for maximum performance. - Might need some adjustments with compiler flags. See https://code.dlang.org/packages/blake3-d. Please see details on the building of the wrapped C library using cmake and make. Probably needs some TLC for platform-independence.
Re: valgrind 3.21.0 supports D demangling
On Thursday, 1 June 2023 at 13:01:44 UTC, user456 wrote: In case some would still pipe valgrind in ddemangle, be aware that this is not required anymore. Since [version 3.21.0], valgrind supports D demangling out of the box. [version 3.21.0]: https://valgrind.org/docs/manual/dist.news.html Awesome.
Re: text based file formats
On Wednesday, 21 December 2022 at 04:19:46 UTC, 9il wrote: It has already been replaced with [mir.csv](https://github.com/libmir/mir-ion/blob/master/source/mir/csv.d). Mir is faster, SIMD accelerated, and supports numbers and timestamp recognition. Great work. Will this module be extracted into a separate package?
Re: text based file formats
On Sunday, 18 December 2022 at 15:56:38 UTC, Robert Schadek wrote: So stop talking, and start creating PR's. For the project admin stuff, this will use github. There are milestones for the five formats, so please start creating the issues you want/can work on and start typing. If I were you I would join forces with Ilya and work on getting the mir libraries doing text-parsing integrated into Phobos.
Re: GCC 12.2 Released (D v2.100.1)
On Thursday, 8 September 2022 at 07:36:02 UTC, Iain Buclaw wrote: https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa I guess I can for wait 22.10 aswell: https://launchpad.net/ubuntu/+source/gcc-12/12.2.0-2ubuntu1 Thanks!
Re: GCC 12.2 Released (D v2.100.1)
On Friday, 19 August 2022 at 11:36:09 UTC, Iain Buclaw wrote: GCC version 12.2 has been released. Thanks again, Ian. What are the options for installing GDC 12.2 on Ubuntu 22.04? GCC PPA or build from source?
Re: GCC 12.1 Released (D v2.100-rc.1)
On Friday, 6 May 2022 at 11:57:47 UTC, Iain Buclaw wrote: I am proud to announce another major GCC release, 12.1. Thank you, Ian!
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. To try this out do I build gcc with only the D language frontend enabled?
Re: GDC has just landed v2.098.0-beta.1 into GCC
On Tuesday, 30 November 2021 at 19:37:34 UTC, Iain Buclaw wrote: Hi, The latest version of the D language has [now landed](https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5fee5ec362f7a243f459e6378fd49dfc89dc9fb5) in GCC. Wonderful!
Re: mir.complex
On Friday, 20 August 2021 at 17:02:33 UTC, 9il wrote: There are few reasons. The main one is that linking bugs caused by a compiler mangling/generation bugs makes std.complex unusable for us. Initially I have updated all packages with std.complex, however it failed to link in a private project. Why wasn't fixing the linking bugs considered an alternative to forking std.complex? What are the other remaining reasons for not using std.complex?
Re: LDC 1.26.0
On Wednesday, 28 April 2021 at 15:30:58 UTC, kinke wrote: Glad to announce LDC 1.26: Awesome! Finally, we can get rid of those darn Nullable.get deprecation messages.
Re: LDC 1.26.0-beta1
On Saturday, 10 April 2021 at 20:50:08 UTC, kinke wrote: https://github.com/ldc-developers/ldc/releases/tag/v1.26.0-beta1 Thanks.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 18 March 2021 at 12:21:46 UTC, Mike Parker wrote:
I actually don't agree with that. I'll be discussion the
solution in the next article:
if(!GC.inFinalizer) {
...
}
It's perfectly fine to perform GC operations in destructors
when they aren't invoked by the GC.
Could we at least add some guard in the GC that notifies the user
of the reason for getting an exception, preferrably including a
source position, when trying to allocate in a destructor run
during finalization? Not getting an explanation has stolen hours
of my development time on several occasion. And likely happen in
the future for other users aswell potentially making them abandon
D for other languages.
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ Btw, what is the motive behind D's GC not being able to correctly handle GC allocations in class destructors. Is it by design or because of limitations in D's current GC implementation? And how does this relate to exception-throwing destructors in other managed languages such as C# and Go; are they forbidden or allowed and safe thanks to a more resilient GC?
Re: On the D Blog--Symphony of Destruction: Structs, Classes, and the GC
On Thursday, 4 March 2021 at 13:54:48 UTC, Mike Parker wrote: The blog: https://dlang.org/blog/2021/03/04/symphony-of-destruction-structs-classes-and-the-gc-part-one/ Reminds me of longing for an (optional) compiler warning or, even better, a deprecation when - destructors of GC-managed objects that perform any operation that can potentially result in a GC allocation request and /or - allocating structs on the GC heap that have destructors . In the mean time a good rule of thumb is to qualify all class destructors as @nogc. I suggest you add this advice to the article, Mike. Thanks!
Re: styx, a programming languange written in D, is on the bootstrap path
On Friday, 15 January 2021 at 19:18:09 UTC, Basile B. wrote: - DotExpression aliases (they have been proposed to DMD this summer when I worked "under cover" as Nils.) Can you give examples of what a DotExpression alias is?
Re: LDC 1.25.0-beta1
On Saturday, 9 January 2021 at 11:48:46 UTC, kinke wrote: Glad to announce the first beta for LDC 1.25 - some highlights: Great work!
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 6 January 2021 at 09:21:53 UTC, Mike Parker wrote: https://github.com/dlang/DIPs/blob/c06ce7f144b3dabf363d1896ddcd31a2a6b7c969/DIPs/DIP1039.md A bit off topic: Would Kenji Hara still have been an active Dlang community member if his solution to DIP-1039 hadn't been reverted.
Re: dmdcache
On Saturday, 25 April 2020 at 12:30:17 UTC, John Colvin wrote: But how does this differ from just using make? make doesn't support total-dependency-content-digest keying of cached artifacts similar to what, for instance, Bazel does.
Re: Beta 2.095.0
On Tuesday, 29 December 2020 at 00:17:59 UTC, Mathias LANG wrote: Yes please! And thanks for paying attention to the changelog, it matters a lot! Done: https://github.com/dlang/dlang.org/pull/2926
Re: Beta 2.095.0
On Sunday, 20 December 2020 at 13:21:46 UTC, Martin Nowak wrote: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html Feature https://dlang.org/changelog/2.095.0.html#better-vtemplates was already added at https://dlang.org/changelog/2.094.0.html#better-vtemplates Shall I fix?
Automatic demangling of symbols in Emacs buffers
The Emacs mode `demangle-mode` [1] can now be used, typically in `compilation-minor-mode`, to demangle symbols in Emacs buffers, either via `c++filt` or via `ddemangle`. The demangling executable also just became configurable via [2] by customizing the variable `demangle-languages`. [1] https://github.com/liblit/demangle-mode [2] https://github.com/liblit/demangle-mode/pull/8#issuecomment-699525497
Re: Beta 2.094.0
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote: http://dlang.org/changelog/2.094.0.html Possible spell fix in Changelog. Shouldn't "However, this didn't really capture the intended meaning of in: _the_ be applied on input parameters." be "However, this didn't really capture the intended meaning of in: _to_ be applied on input parameters." ?
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 13:09:55 UTC, Per Nordlöw wrote: Where can I update the changelog to include this? https://github.com/dlang/dmd/pull/11732
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 16:54:49 UTC, Per Nordlöw wrote: I agree, this is unfortunate. Did you read Andreis comment at the bottom for the Bugzilla issue? Here https://issues.dlang.org/show_bug.cgi?id=14835#c10
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 14:05:04 UTC, Paul Backus wrote: Is there? Issue 14835 was reported in 2015. If nobody's been able to come up with an improvement in 5 years, what are the odds that this year will be the one that lets us finally crack it? I agree, this is unfortunate. Did you read Andreis comment at the bottom for the Bugzilla issue? Genuine question, by the way. If it's just an issue of "nobody's had time to work on it," then there may be nothing to worry about. I guess I need to look at the code in dmd. I'm guessing it's a long function with lots of state as Walter alluded to in a DConf talk.
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus wrote: How many improvements does this warning have to block before we decide its value for the language is net-negative? There's also the option of improving the diagnostic of unreachable code.
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 13:03:29 UTC, Paul Backus wrote: On Saturday, 12 September 2020 at 11:43:03 UTC, MoonlightSentinel wrote: Currently looking into enabling it by default but it showed an interesting side effect. The frontend Attribute would be nice. Then such tagged exceptions can be searched for and maybe fixed later.
Re: Beta 2.094.0
On Friday, 11 September 2020 at 13:44:02 UTC, Guillaume Piolat wrote: This is an absolutely fantastic release! Thanks to all. - faster DMD Is this solely thanks to using ldc as host compiler? What are the flags passed to ldc when building dmd? Profile guided optimization?
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 11:43:41 UTC, Per Nordlöw wrote: I forgot too add the new formatting of -vtemplates to the changelog. Where can I update the changelog to include this?
Re: Beta 2.094.0
On Saturday, 12 September 2020 at 11:03:09 UTC, Per Nordlöw wrote: I forgot too add the new formatting of -vtemplates to the changelog. https://github.com/dlang/dmd/pull/11463
Re: Beta 2.094.0
On Friday, 11 September 2020 at 07:48:00 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.094.0 release, ♥ to the 49 contributors. I forgot too add the new formatting of -vtemplates to the changelog. Shall I?
Re: Turn output of -vtemplates into compiler-messages and show template instances
On Thursday, 3 September 2020 at 13:20:32 UTC, jmh530 wrote: People also might find it useful to filter for just one template (and show all the instances). I proposed that feature as, say, `vtemplates=list-instances:Template1,Template2,...` . Just complain a bit and I'll get momentum to add that too ;)
Turn output of -vtemplates into compiler-messages and show template instances
D just got a better formatting of existing template usage sorted by descending unique instantiation count via the flag `-vtemplates`. Each template that has a least one instantiation is now printed using standard compiler diagnostics formatting for easy navigation to the point of its declaration. Additionally, a new feature is to instead of `-vtemplates` use `-vtemplates=list-instances` . Then the location(s) for each instance of each instantiated template is printed along with information telling whether the instantiation was implicit or explicit. A good example of the behavior can be found in the test file [2] [1] https://github.com/dlang/dmd/pull/11463 [2] https://github.com/nordlow/dmd/blob/6b69ff7f0676314953344b5c920d960c023b3134/test/compilable/vtemplates_list.d
Re: Type-safer usage of diagnostics outputting in dmd
On Tuesday, 1 September 2020 at 22:14:11 UTC, Per Nordlöw wrote: when the compiler supports it (from dmd version 2.092 and The host compiler supports it (from dmd version 2.092), that is.
Type-safer usage of diagnostics outputting in dmd
The diagnostics functions in `dmd.errors` are now qualified [1] with the, by Walter, recently added pragma(printf) when the compiler supports it (from dmd version 2.092 and upwards). In other words, a mismatch between the format part and the argument part in a call to either of - error(const ref Loc loc, const(char)* format, ...) - warning(const ref Loc loc, const(char)* format, ...) - message(const ref Loc loc, const(char)* format, ...) - deprecation(const ref Loc loc, const(char)* format, ...) - ... will now issue a warning. [1] https://github.com/dlang/dmd/pull/11638
Re: Visual D 1.0.1 released
On Sunday, 23 August 2020 at 07:33:01 UTC, Rainer Schuetze wrote: The most important part of the update is that the semantic engine is now based on the latest compiler release 2.093.1. - Does the engine have a feature list? - Is the engine relatively independent of Windows? - Does engine integrate with language server (in a platform independent way)? - Are there any plans for cross-platform (Linux) support? I'm dying to get a semantic engine that supports code navigation to (and completion of) overloaded functions at their call site including UFCS-calls. DCD doesn't support these two features.
Re: Release of std.io v0.3.0
On Tuesday, 28 July 2020 at 18:23:45 UTC, Steven Schveighoffer wrote: On 7/28/20 10:08 AM, Per Nordlöw wrote: Be free to copy what you like from https://github.com/nordlow/phobos-next/blob/master/src/nxt/zio.d Thanks. I actually have zip support in iopipe (it requires buffering anyway): http://schveiguy.github.io/iopipe/iopipe/zip.html std.io is very low level -- it does not buffer, but instead provides a base framework on which to build higher level i/o abstractions. -Steve Note that this is for range-based decoding of gzip, bzip2 files. With blocked decoding underneath.
Re: Release of std.io v0.3.0
On Sunday, 26 July 2020 at 17:09:07 UTC, Steven Schveighoffer wrote: -Steve [1] https://code.dlang.org/packages/io [2] https://martinnowak.github.io/io/std/io/driver.html [3] https://martinnowak.github.io/io/std/io/file/File.this.html Thanks. Be free to copy what you like from https://github.com/nordlow/phobos-next/blob/master/src/nxt/zio.d
Re: DConf Online 2020 (Soft Announcement)
On Friday, 17 July 2020 at 14:56:06 UTC, aberba wrote: On Friday, 17 July 2020 at 11:55:14 UTC, Mike Parker wrote: DConf Online 2020 is on! https://dconf.org/2020/online/index.html [...] Very exited about this. Me too
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 23:36:58 UTC, IGotD- wrote: On Thursday, 16 July 2020 at 15:56:45 UTC, Per Nordlöw wrote: D's compiler `dmd` is still far ahead of all its competition especially when it comes to default build (standard compilation) performance. I don't think this comparison is fair as dmd is far behind when it comes to code generation compared to the competitors. What should be included are benchmarks done with LDC as well. Since you already have the D code, adding LDC should be pretty easy. Both dmd and ldc have superior check stage (lexical, syntactic and semantic analysis) because of a language designed in conjunction with the needs and limitations of a compiler. One key-property of such a design is that the D language is design to be a so called, single-pass language. The compiler dmd is superior because of a super-fast but less qualitative code generation giving outstanding productivity incremental development. At that stage in the development cycle fast builds is much more important that optimized machine code. The machine code generated by dmd in this stage is sufficiently fast for the needs of the developer trying to be productive in this stage. That is by design, not by accident. I suggest you ask Walter Bright if you want more details around his design. The compiler ldc is about 10x slower than dmd for the debug stage because of the larger overhead of the LLVM-backend and is often preferred when doing release builds.
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 18:27:54 UTC, jmh530 wrote: How are the functions generated? I see something about function-depth, but it might be good to have an example in the readme. This is, of course, a very contrived benchmark but I had to pick something to get me started and I'll happily receive suggestions on how to improve the benchmarking-relevance of the generated code.
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 18:27:54 UTC, jmh530 wrote: How are the functions generated? I see something about function-depth, but it might be good to have an example in the readme. Added here https://github.com/nordlow/compiler-benchmark#sample-generated-code
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 18:27:54 UTC, jmh530 wrote: How are the functions generated? I see something about function-depth, but it might be good to have an example in the readme. Ah, I'll add that. Thanks
Updated compiler-benchmark
I've updated https://github.com/nordlow/compiler-benchmark with - source variants with templated function variants for languages having generics - stdout-printing in Markdown (used in README.md) - benchmarks for the languages Zig and V ## Conclusions (from sample run shown below) D's compiler `dmd` is still far ahead of all its competition especially when it comes to default build (standard compilation) performance. The performance of both GCC and Clang gets significanly worse with each new release (currently 8, 9, 10 in the table below). The generic C++ and D versions compiles about 1.5 to 2 times slower whereas the generic Rust version interestingly is processed 2-3 times faster than the non-generic version.
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 15:56:45 UTC, Per Nordlöw wrote: The generic C++ and D versions compiles about 1.5 to 2 times slower With DMD, that is.
Re: From the D Blog: A Pattern for Head-mutable Structures
On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote: Simen Kjærås outlines an approach to supporting head-mutable types in D without the need for compiler or language changes. The blog: https://dlang.org/blog/2020/06/25/a-pattern-for-head-mutable-structures/ Reddit: https://www.reddit.com/r/programming/comments/hfkq5e/a_pattern_for_headmutable_structures_in_d/ I've also submitted it to HN (please use the search box): https://news.ycombinator.com/newest What's so problematic about adding compiler support for implicit cast to head mutable for range-style structs?
Re: From the D Blog: A Pattern for Head-mutable Structures
On Thursday, 25 June 2020 at 11:55:14 UTC, Mike Parker wrote: Simen Kjærås outlines an approach to supporting head-mutable types in D without the need for compiler or language changes. The blog: https://dlang.org/blog/2020/06/25/a-pattern-for-head-mutable-structures/ This is a brilliant potential improvement to D that's gonna make it even more usable especially for newcomers. What about adding and using headMutable in Phobos ranges?
Re: Beta 2.090.0
On Tuesday, 24 December 2019 at 05:59:35 UTC, Soulsbane wrote: dub test doesn't run the actual program only unittests are far as I can tell. Correct, but that is from 2.090 the behaviour of dub run --build=unittest aswell. This seems strange to me. I would like to see a new built-in build target in dub, say dub run --build=unittest-debug , that mimics the behaviour of dub run --build=unittest prior to 2.090.
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 23:05:20 UTC, Steven Schveighoffer wrote: extern(C) __gshared string[] rt_options = [ "testmode=run-main"]; There are far more people who run unittests as a separate step from running their application. If unittests pass, then there's no distinguishable output from a build without unittests. I can totally imagine accidentally shipping code with unittests in it without intending to. Thanks. So what is now the difference between dub run --build=unittest and dub test ?
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.090.0.html As usual please report any bugs at https://issues.dlang.org -Martin I've gotten very used to running my app via dub run --compiler=dmd --build=unittest in order to, with short iterations, run tests and the application at the same time. Changing this behaviour via https://dlang.org/changelog/2.090.0.html#unittest-default is, to me, an usually disruptive change. I tried changing to dub run --compiler=dmd --build=unittest -- --DRT-testmode=run-main but it still doesn't run the application after the unittests are run. Have I missed something or is this a known problem with dub? If so, do I have any alternative to brute-forcing the problem with dub run --compiler=dmd --build=unittest dub run --compiler=dmd --build=debug which, for me, doubles my development iteration time.
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 21 October 2019 at 12:12:56 UTC, Per Nordlöw wrote: Is it prepackaged on Ubuntu? Do you mean the package golang-go?
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 21 October 2019 at 11:59:15 UTC, Márcio Martins wrote: That's google reference implementation. Sort of like `DMD`, should be faster, but generating less optimal code. Is it prepackaged on Ubuntu?
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 21 October 2019 at 11:27:05 UTC, Per Nordlöw wrote: On Monday, 21 October 2019 at 11:07:14 UTC, Márcio Martins wrote: Any reason why you left Go's `gc` out? Note that I just changed `-c` to `-S` in the call go `gccgo` in `benchmark` to skip assmembly phase.
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 21 October 2019 at 11:07:14 UTC, Márcio Martins wrote: Any reason why you left Go's `gc` out? What do you mean by `gc`? Is `gc` a checker or checker flag to some compiler? Can't find any relevant hits for hit the web.
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Saturday, 16 March 2019 at 21:23:18 UTC, Per Nordlöw wrote: https://github.com/nordlow/compiler-benchmark Just added support for V (vlang.io), Zig and Julia.
Re: Ownership and Borrowing in D
On Saturday, 20 July 2019 at 21:56:50 UTC, Walter Bright wrote: We're likely going to add a move constructor, too. And deprecate opPostMove?
Re: LDC 1.16.0-beta1
On Thursday, 9 May 2019 at 21:14:02 UTC, kinke wrote: Glad to announce the first beta for LDC 1.16; mainly just an upgrade to D 2.086.0. Thanks!
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:33:52 UTC, Laeeth Isharc wrote: Sorry about that. It was supposed to be streaming to YouTube, but it fell through the cracks. We are looking into it now. Great.
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:21:33 UTC, Thomas Brix Larsen wrote: I had to click Audio Connection -> Computer to get audio. Where did you find those menus?
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Tuesday, 19 March 2019 at 10:10:28 UTC, Seb wrote: Well, you don't really need a script: git clone https://github.com/dlang/dmd HOST_DMD=ldmd2 make -f posix.mak -j10 Additionally, you can add `ENABLE_RELEASE=1` to create a fully optimized release binary. Thanks!
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Monday, 18 March 2019 at 12:33:12 UTC, Seb wrote: [1] https://github.com/dlang/installer Does this include a script for building dmd with ldc or this not yet possible?
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Sunday, 17 March 2019 at 09:17:06 UTC, Jacob Carlborg wrote: It would be interesting to measure D's speed with DMD compiled with LDC as the host D compiler. I thought that already is the case...
Compiler benchmarker for D, C, C++, Go, Rust with more to come
After reading https://forum.dlang.org/thread/nlhybmioaoxkydicm...@forum.dlang.org it's about time I announce my little Python snippet that exercises the compilation speed of D and other languages with a superficial test program generator at https://github.com/nordlow/compiler-benchmark Run as ./benchmark.py This generates a single source file for each supported language, currently D, C, C++, Go and Rust, containing 50k number of trivial functions that from the main function are called and reduced to a single integer which is returned at the end of main. The benchmark then measures the time it takes for each compiler to run semantic analysis on the source file (excluding output of any object files). My only question is: How is it possible for Rust be to 50x slower than D in this test!!!??? Am I calling rustc in the wrong way? Especially taking into account the amount of time (and money) that has been put into making Rust fast(er). Through fancy caching of IR-files and more. I very much welcome PRs that add more languages. Output on Ubuntu 18.04 system is Code-generation: Generating generated/c/foo.c took 0.073 seconds (C) Generating generated/c++/foo.c++ took 0.073 seconds (C++) Generating generated/d/foo.d took 0.076 seconds (D) Generating generated/rust/foo.rs took 0.076 seconds (Rust) Generating generated/zig/foo.zig took 0.077 seconds (Zig) Generating generated/go/foo.go took 0.074 seconds (Go) Clang: - Checking of generated/c/foo.c took 1.373 seconds (using "/usr/bin/clang-7") - Checking of generated/c++/foo.c++ took 1.345 seconds (using "/usr/bin/clang++-7") GCC: - Checking of generated/c/foo.c took 0.385 seconds (using "/usr/bin/gcc-5") - Checking of generated/c++/foo.c++ took 0.675 seconds (using "/usr/bin/g++-5") - Checking of generated/c/foo.c took 0.551 seconds (using "/usr/bin/gcc-6") - Checking of generated/c/foo.c took 0.518 seconds (using "/usr/bin/gcc-7") - Checking of generated/c++/foo.c++ took 1.294 seconds (using "/usr/bin/g++-7") - Checking of generated/c/foo.c took 0.527 seconds (using "/usr/bin/gcc-8") - Checking of generated/c++/foo.c++ took 1.363 seconds (using "/usr/bin/g++-8") D: - Checking of generated/d/foo.d took 0.403 seconds (using "/usr/bin/dmd") - Checking of generated/d/foo.d took 0.352 seconds (using "/home/per/.local/ldc2-1.15.0-beta1-linux-x86_64/bin/ldmd2") Go: - Checking of generated/go/foo.go took 1.716 seconds (using "/usr/bin/gccgo") Rust: - Checking of generated/rust/foo.rs took 17.828 seconds (using "/home/per/.cargo/bin/rustc") Zig: Speedups: - D to gcc-8: 1.50 - D to g++-8: 3.88 - D to Clang: 3.90 - D to Clang++: 3.83 - D to Go: 4.88 - D to Rust: 50.71
Re: LDC 1.15.0-beta1
On Tuesday, 12 March 2019 at 20:15:30 UTC, kinke wrote: As usual, v1.15.0 final will be based on the first DMD point release (2.085.1), so just make sure your fixes end up in DMD's stable branches before the tag, as done in this case. Wonderful!
Re: LDC 1.15.0-beta1
On Saturday, 9 March 2019 at 22:08:27 UTC, Dennis wrote: Yes, gimme those assertion failure messages! I hope the fix for using it with attributes (https://github.com/dlang/druntime/pull/2479) gets merged in time for the stable release of LDC 1.15. https://github.com/dlang/druntime/pull/2479 was just merged! Can we please merge this into LDC 1.15?!
Re: Release D 2.085.0
On Monday, 4 March 2019 at 07:58:09 UTC, Rainer Schuetze wrote: These objects would still have to be scanned, so there is not much that could be saved with respect to performance. Ok, thanks.
Re: Release D 2.085.0
On Sunday, 3 March 2019 at 21:51:30 UTC, Per Nordlöw wrote: that don't have a destructor (hasElaborateDestructor being true Correction: that don't have a destructor (hasElaborateDestructor being FALSE
Re: Beta 2.085.0
On Sunday, 17 February 2019 at 12:34:12 UTC, Per Nordlöw wrote: What's not found in the changelog is an optimization sweeping large allocations that is inspired by your report https://forum.dlang.org/thread/zrouxhbkssrncyinh...@forum.dlang.org: https://github.com/dlang/druntime/pull/2430 Thank you! Made a comment about size types, regarding why 24 bytes wasn't included in the size set, @rainers ? https://github.com/dlang/druntime/pull/2384#issuecomment-464488155
Re: Beta 2.085.0
On Sunday, 17 February 2019 at 07:49:24 UTC, Rainer Schuetze wrote: It is listed as "Bugzilla 19455: GC wastes too much memory". What's not found in the changelog is an optimization sweeping large allocations that is inspired by your report https://forum.dlang.org/thread/zrouxhbkssrncyinh...@forum.dlang.org: https://github.com/dlang/druntime/pull/2430 Thank you!
Re: Beta 2.085.0
On Saturday, 16 February 2019 at 15:06:51 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.085.0 release, ♥ to the 49 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.085.0.html I can't find any mentioning of Rainer Schützes work on memory reductions of the GC for non-power-of-two sizes. Was it reverted? Thanks for all the work!
Re: Hunt framework 2.0.0 released
On Tuesday, 29 January 2019 at 10:00:22 UTC, zoujiaqing wrote: The HuntLabs team is happy to announce the release of Hunt Framework 2.0. Is there an online comparison describing the differences between Hunt and Vibe.d? I'm mainly interested in - fast incremental compilation, - high run-time performance and - expressiveness In other words, how to most easily get the job done with the least amount of code.
Re: DLS (D Language Server) v0.20
On Friday, 28 December 2018 at 22:52:40 UTC, Laurent Tréguier wrote: I haven't looked into Emacs yet, maybe I'll do that in the coming days. [1] https://github.com/emacs-lsp/lsp-mode [2] https://github.com/joaotavora/eglot Thanks!
Re: DLS (D Language Server) v0.20
On Friday, 28 December 2018 at 11:14:01 UTC, Laurent Tréguier wrote: Hello, and merry Christmas! (a bit late, but whatever) https://forum.dlang.org/post/jytsaamhiglkmeixx...@forum.dlang.org [2] https://github.com/d-language-server/dls [3] https://github.com/Pure-D/serve-d Nice! Great work! How does DLS compare to the features of DCD? I'm using DCD through my beloved Emacs. Is there a more powerful Emacs+DLS-solution ready for use?
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html Great work!
Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted
On Thursday, 8 November 2018 at 02:36:21 UTC, test wrote: Thanks to all for the hard work. Look forward DIP1016 to be approved. Agreed!
Re: Beta 2.082.1
On Thursday, 11 October 2018 at 12:19:56 UTC, Martin Nowak wrote: https://dlang.slack.com/archives/C4DN1H6LA/p1536909712000100 for more info. I'm about to rebuild the nightlies infrastructure based on a buildkite worker, so that release binary building becomes somewhat more transparent (and reliable). The new nightlies binaries will be uploaded to downloads.dlang.org/nightlies just as all the other binaries. Nice.
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 23:56:56 UTC, Walter Bright wrote: On 9/11/2018 8:08 AM, RazvanN wrote: [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 Thank you, RazvanN! I very much agree!
Re: expectations 0.1.0
On Sunday, 2 September 2018 at 06:59:20 UTC, Paul Backus wrote: expectations is an error-handling library that lets you bundle exceptions together with return values. It is based on Rust's Result [1] and C++'s proposed std::expected. [2] If you're not familiar with those, Andrei's NDC Oslo talk, "Expect the Expected" [3], explains the advantages of this approach to error handling in considerable detail. Incidentally, I've already proposed `Expected` into Phobos std.experimental.typecons here https://github.com/dlang/phobos/pull/6686 Is it ok if I try to merge your effort into this pull request?
Re: DCD 0.9.11 & D-Scanner 0.5.10
On Sunday, 2 September 2018 at 04:52:22 UTC, Basile B. wrote: Both compatible with syntax changes coming with 2.082. https://github.com/dlang-community/DCD/releases/tag/v0.9.11 https://github.com/dlang-community/D-Scanner/releases/tag/v0.5.10 Great! Professional.
Re: Hunt framework 1.0.0 released
On Tuesday, 5 June 2018 at 07:25:33 UTC, Brian wrote: We are pleased to announce an official version of hunt 1.0 , How is Hunt different from Vibe?
Re: LDC 1.10.0 beta
On Sunday, 13 May 2018 at 18:12:51 UTC, kinke wrote: * Based on D 2.080.0. Great!
Re: sumtype 0.3.0
On Sunday, 6 May 2018 at 19:18:02 UTC, Paul Backus wrote: SumType is a generic sum type for modern D. It is meant as an alternative to `std.variant.Algebraic`. Features: - Pattern matching, including support for structural matching (*) - Self-referential types, using `This` - Works with `pure`, `@safe`, `@nogc`, and `immutable` (*) - Zero runtime overhead compared to hand-written C - No heap allocation - Does not rely on runtime type information (`TypeInfo`) (*) Starred features (*) are those that are missing from `Algebraic`. Code examples are available in the documentation (linked below). New in this release: - The list of types allowed in a sum type is now public - Implicit qualifier conversions are now allowed in pattern matching - Better code examples in the documentation This library is a work in progress. If you have a use case you'd like to see supported, or an API you'd like to see implemented, please get in touch! Documentation: https://pbackus.github.io/sumtype/sumtype.html DUB: https://code.dlang.org/packages/sumtype Github: https://github.com/pbackus/sumtype Nice. I've written something similar in LightAlgebraic at https://github.com/nordlow/phobos-next/blob/master/src/vary.d#L30 which is also significantly faster than `std.typecons.Algebraic`. Has the same features as SumType except for - Self-referential types, using `This` and - pattern matching Note that the `memoryPacked` flag being `true` hasn't been thoroughly tested. Your're free to copy an ideas or features in `LightAlgebraic` into `SumType`.
Re: DConf 2018 Livestream
On Wednesday, 2 May 2018 at 07:13:21 UTC, Mike Parker wrote: For those of you unable to join us in Munich, you can watch the fun online via the following link: https://www.youtube.com/user/hlmceventsgmbh I can't find Andrei's talk this morning. Was it lost?
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Friday, 6 April 2018 at 12:26:36 UTC, Mike Parker wrote: Congratulations to Zach Tollen and everyone who worked on DIP 1009. It took a painful amount of time to get it through the process, but it had finally come out of the other side with an approval. The proposal itself was approved early on, but it needed quite a bit of revision to get to an acceptable final draft. The DIP in its final form: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1009.md Great work. Great syntax.
Re: dpldocs now has cross-package search (experimental)
On Saturday, 10 March 2018 at 00:09:18 UTC, Adam D. Ruppe wrote: Looking for http libs? Behold: http://search.dpldocs.info/?q=http Nice!
Re: flycheck-dmd-dub v0.12 - Emacs on-the-fly syntax checking for D
On Thursday, 8 February 2018 at 17:05:32 UTC, Atila Neves wrote: This new release fixes bugs and speeds up opening files by using `--nodeps --skip-registry=all` if the dependent packages have already been downloaded. Thanks!
Re: LDC 1.6.0-beta1
On Sunday, 12 November 2017 at 15:57:19 UTC, kinke wrote:
Hi everyone,
on behalf of the LDC team, I'm glad to announce the first beta
for LDC 1.6. The highlights of this version in a nutshell:
* Based on D 2.076.1.
* Experimental support for dynamic codegen at runtime ('manual
JIT').
* Many std.math functions are now CTFE-able.
Full release log and downloads:
https://github.com/ldc-developers/ldc/releases/tag/v1.6.0-beta1
Thanks to all contributors!
Wow, that's fast!
I'm looking forward to discussions concerning the new feature:
dynamic codegen at runtime
Are there any plans on also using LLVMs jit for run-time
generative (meta) programming?
Re: LDC 1.5.0-beta1
On Sunday, 22 October 2017 at 09:34:56 UTC, kinke wrote: Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.5.0-beta1 Thanks to everybody contributing! Thanks!
Re: Unit Testing in Action
On Saturday, 21 October 2017 at 22:50:51 UTC, Walter Bright wrote: What's happening here is each of the operands of || are considered to be separate statements as far as coverage analysis goes. It becomes clearer if it is reformatted as: 1|x = 2; 1|if (x == 1 || 1|x == 2) or: 3|x = 2; if (x == 1 || x == 2) What about (adding a flag) making coverage operate at the expression level instead? Meaning that each coverage result would be associated with a column offset and length aswell as the line number. Of course the program would run much slower...
Re: DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack
On Friday, 20 October 2017 at 20:41:24 UTC, Nordlöw wrote: https://github.com/ldc-developers/ldc/commits/dcompute or rather https://github.com/libmir/dcompute
DCompute target: Intel to Introduce New CPU-FPGA Hybrid Chip Supported by Acceleration Stack
https://www.allaboutcircuits.com/news/intel-to-introduce-new-cpu-fpga-hybrid-chip-supported-by-acceleration-stack/ is yet another motivation to keep up the great work put into DCompute at https://github.com/ldc-developers/ldc/commits/dcompute ! Ever since I first tried programming in VHDL and realized that it, at that time, was far too unproductive for my taste, I've been waiting for the software and FPGA programming models to unite... What kinds of simplifications (over OpenCL) can and will DCompute offer in this regard?
Re: Netflix opensources its first D library: Vectorflow
On Tuesday, 8 August 2017 at 18:51:26 UTC, Nordlöw wrote: To clarify here's an incomplete snippet that should clarify: auto add(A, B)(A a, B b) should be auto add(A, B)(auto ref A a, auto ref B b)
Re: [OT] LLVM 5.0 released - LDC mentioned in release notes
On Thursday, 7 September 2017 at 19:26:51 UTC, Kai Nacke wrote: LLVM 5.0 has been released! See the release notes here: http://releases.llvm.org/5.0.0/docs/ReleaseNotes.html Downloads: http://releases.llvm.org/download.html#5.0.0 Great work, Kai! Are there any new code-generation features in LLVM 5.0 that LDC will make use of?
Re: Netflix opensources its first D library: Vectorflow
On Tuesday, 8 August 2017 at 18:40:08 UTC, Nordlöw wrote:
On Thursday, 3 August 2017 at 04:40:05 UTC, Matt wrote:
Also note, one of the main advantages of Eigen is the whole
lazy evaluation of expressions for compound operations.
I haven't dug in the source, but it's my understanding it's
done through a lot of compile time C++ template hacking
Note that D provides
__traits(isRef, Symbol)
To clarify here's an incomplete snippet that should clarify:
auto add(A, B)(A a, B b)
if (isSomeArithmeticType!A &&
isSomeArithmeticType!B)
{
static if (__traits(isRef, a) &&
__traits(isRef, b)) // both `a` and `b` are l-values
{
return a + b; // fully eager evaluation
}
else static if (__traits(isRef, a)) // `b` is an r-value
{
// `b` can incremented by `a` and returned by move (reused)
}
else static if (__traits(isRef, b)) // `a` is an r-value
{
// `a` can incremented by `b` and returned by move (reused)
}
else // both `a` and `b` are r-values
{
return Add(a,b); // delay evaluation
}
}
Re: Netflix opensources its first D library: Vectorflow
On Thursday, 3 August 2017 at 04:40:05 UTC, Matt wrote: Also note, one of the main advantages of Eigen is the whole lazy evaluation of expressions for compound operations. I haven't dug in the source, but it's my understanding it's done through a lot of compile time C++ template hacking Note that D provides __traits(isRef, Symbol) which can be used to convenient implement lazy-evaluated expressions with free functions. Note that it cannot currently be used to check whether `this` was passed as an l-value or r-value which prevents the C++-expression-template-pattern from being used in operator overloading. For details see: https://issues.dlang.org/show_bug.cgi?id=17734
Re: DCD 0.9.0 released
On Monday, 3 July 2017 at 08:30:52 UTC, Basile@dlang-community wrote: I'm glad to announce that the dlang-community has released DCD 0.9.0[1] Nice. Are there any plans on adding any (limited) kind of auto-completion of UFCS-calls?
Re: Lubeck: Hight Level Linear Algebra for Dlang
On Thursday, 15 June 2017 at 14:23:29 UTC, jmh530 wrote: mir.ndslice.slice has CanonicalMatrix/ContinguousMatrix, and similar versions for vectors and tensors and all the algorithms that operate on ranges in mir seem to work fine with them. Ilya has expressed his intention in the past for higher level abstractions on mir, including operator overloading. I brought up the operator overloading issue on the gradient descent thread: https://forum.dlang.org/post/ohjsuphzuapaxktgw...@forum.dlang.org Thanks.
