Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 10:30 PM Vladimir Panteleev via Digitalmars-d-announce wrote: > > On Thursday, 8 November 2018 at 06:08:20 UTC, Vladimir Panteleev > wrote: > > It was definitely about 4 seconds not too long ago, a few years > > at most. > > No, it's still 4 seconds. > > digger --offline --config-file=/dev/null -j auto -c > local.cache=none build 7.31s user 1.51s system 203% cpu 4.340 > total > > > It does seem to take more time now; I wonder why. > > If it takes longer, then it's probably because it's being built > in one CPU core, or in the release build. https://youtu.be/msWuRlD3zy0 DMD only builds with one core, since it builds altogether. And all builds are release builds... what good is a debug build? DMD is unbelievably slow in debug. If it wasn't already slow enough... if I try and build with a debug build, it takes closer to 5 minutes. I suspect one part of the problem is that DMD used to be built with a C compiler, and now it's built with DMD... it really should be built with LDC at least?
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:41:58 UTC, Manu wrote: On Wed, Nov 7, 2018 at 10:30 PM Joakim via Digitalmars-d-announce wrote: On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: > On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via > Digitalmars-d-announce > wrote: >> [...] > > "Indeed, a clean build of DMD itself (about 170’000 lines of > D and 120’000 lines of C/C++) takes no longer than 4 seconds > to build on a rather average developer machine." > > ...what!? DMD takes me... (compiling) ... 1 minute 40 > seconds to build! And because DMD does all-files-at-once > compilation, rather than separate compilation for each > source file, whenever you change just one line in one file, > you incur that entire build time, every time, because it > can't just rebuild the one source file that changed. You > also can't do multi-processor builds with all-in-one build > strategies. > > 4 seconds? That's just untrue. D is actually kinda slow > these days... In my experience it's slower than modern C++ > compilers by quite a lot. It sounds like you're not using "a rather average developer machine" then, as there's no way DMD should be that slow to build on a core i5 or better: https://forum.dlang.org/post/rqukhkpxcvgiefrdc...@forum.dlang.org I'm on an i7 with 8 threads and plenty of ram... although threads are useless, since DMD only uses one ;) Running Windows XP? ;) That does sound like Windows though, as I do remember being surprised how long dmd took to build on Win7 when I tried it 8-9 years back. I still don't think the toolchain should be _that_ much slower than linux though. Btw, the extra cores are _not_ useless for the DMD backend, which has always used separate compilation, whether written in C++ or D.
Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 10:30 PM Joakim via Digitalmars-d-announce wrote: > > On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: > > On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via > > Digitalmars-d-announce > > wrote: > >> [...] > > > > "Indeed, a clean build of DMD itself (about 170’000 lines of D > > and 120’000 lines of C/C++) takes no longer than 4 seconds to > > build on a rather average developer machine." > > > > ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds > > to build! And because DMD does all-files-at-once compilation, > > rather than separate compilation for each source file, whenever > > you change just one line in one file, you incur that entire > > build time, every time, because it can't just rebuild the one > > source file that changed. You also can't do multi-processor > > builds with all-in-one build strategies. > > > > 4 seconds? That's just untrue. D is actually kinda slow these > > days... In my experience it's slower than modern C++ compilers > > by quite a lot. > > It sounds like you're not using "a rather average developer > machine" then, as there's no way DMD should be that slow to build > on a core i5 or better: > > https://forum.dlang.org/post/rqukhkpxcvgiefrdc...@forum.dlang.org I'm on an i7 with 8 threads and plenty of ram... although threads are useless, since DMD only uses one ;)
Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 10:10 PM Vladimir Panteleev via Digitalmars-d-announce wrote: > > On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: > > ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds > > to build! And because DMD does all-files-at-once compilation, > > rather than separate compilation for each source file, whenever > > you change just one line in one file, you incur that entire > > build time, every time, because it can't just rebuild the one > > source file that changed. You also can't do multi-processor > > builds with all-in-one build strategies. > > > > 4 seconds? That's just untrue. D is actually kinda slow these > > days... In my experience it's slower than modern C++ compilers > > by quite a lot. > > It was definitely about 4 seconds not too long ago, a few years > at most. > > It does seem to take more time now; I wonder why. 100 seconds is a lot more than 4... 25x even, that's a pretty big productivity decline ;)
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via Digitalmars-d-announce wrote: [...] "Indeed, a clean build of DMD itself (about 170’000 lines of D and 120’000 lines of C/C++) takes no longer than 4 seconds to build on a rather average developer machine." ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! And because DMD does all-files-at-once compilation, rather than separate compilation for each source file, whenever you change just one line in one file, you incur that entire build time, every time, because it can't just rebuild the one source file that changed. You also can't do multi-processor builds with all-in-one build strategies. 4 seconds? That's just untrue. D is actually kinda slow these days... In my experience it's slower than modern C++ compilers by quite a lot. It sounds like you're not using "a rather average developer machine" then, as there's no way DMD should be that slow to build on a core i5 or better: https://forum.dlang.org/post/rqukhkpxcvgiefrdc...@forum.dlang.org
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 06:08:20 UTC, Vladimir Panteleev wrote: It was definitely about 4 seconds not too long ago, a few years at most. No, it's still 4 seconds. digger --offline --config-file=/dev/null -j auto -c local.cache=none build 7.31s user 1.51s system 203% cpu 4.340 total It does seem to take more time now; I wonder why. If it takes longer, then it's probably because it's being built in one CPU core, or in the release build.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 04:16:44 UTC, Manu wrote: ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! And because DMD does all-files-at-once compilation, rather than separate compilation for each source file, whenever you change just one line in one file, you incur that entire build time, every time, because it can't just rebuild the one source file that changed. You also can't do multi-processor builds with all-in-one build strategies. 4 seconds? That's just untrue. D is actually kinda slow these days... In my experience it's slower than modern C++ compilers by quite a lot. It was definitely about 4 seconds not too long ago, a few years at most. It does seem to take more time now; I wonder why.
Re: Profiling DMD's Compilation Time with dmdprof
On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via Digitalmars-d-announce wrote: > > This is a tool + article I wrote in February, but never got > around to finishing / publishing until today. > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > Hopefully someone will find it useful. "Indeed, a clean build of DMD itself (about 170’000 lines of D and 120’000 lines of C/C++) takes no longer than 4 seconds to build on a rather average developer machine." ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! And because DMD does all-files-at-once compilation, rather than separate compilation for each source file, whenever you change just one line in one file, you incur that entire build time, every time, because it can't just rebuild the one source file that changed. You also can't do multi-processor builds with all-in-one build strategies. 4 seconds? That's just untrue. D is actually kinda slow these days... In my experience it's slower than modern C++ compilers by quite a lot.
Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 8:18 PM Manu wrote: > > On Wed, Nov 7, 2018 at 8:16 PM Manu wrote: > > > > On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via > > Digitalmars-d-announce wrote: > > > > > > This is a tool + article I wrote in February, but never got > > > around to finishing / publishing until today. > > > > > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > > > > > Hopefully someone will find it useful. > > > > "Indeed, a clean build of DMD itself (about 170’000 lines of D and > > 120’000 lines of C/C++) takes no longer than 4 seconds to build on a > > rather average developer machine." > > > > ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! > > And because DMD does all-files-at-once compilation, rather than > > separate compilation for each source file, whenever you change just > > one line in one file, you incur that entire build time, every time, > > because it can't just rebuild the one source file that changed. You > > also can't do multi-processor builds with all-in-one build strategies. > > > > 4 seconds? That's just untrue. D is actually kinda slow these days... > > In my experience it's slower than modern C++ compilers by quite a lot. > > Also, in my experience, DMD seems to build a LOT slower now that it's > in D than it used to when it was C++. Oh, and also, nice work Vladimir! This is awesome! :)
Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 8:16 PM Manu wrote: > > On Tue, Nov 6, 2018 at 10:05 AM Vladimir Panteleev via > Digitalmars-d-announce wrote: > > > > This is a tool + article I wrote in February, but never got > > around to finishing / publishing until today. > > > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > > > Hopefully someone will find it useful. > > "Indeed, a clean build of DMD itself (about 170’000 lines of D and > 120’000 lines of C/C++) takes no longer than 4 seconds to build on a > rather average developer machine." > > ...what!? DMD takes me... (compiling) ... 1 minute 40 seconds to build! > And because DMD does all-files-at-once compilation, rather than > separate compilation for each source file, whenever you change just > one line in one file, you incur that entire build time, every time, > because it can't just rebuild the one source file that changed. You > also can't do multi-processor builds with all-in-one build strategies. > > 4 seconds? That's just untrue. D is actually kinda slow these days... > In my experience it's slower than modern C++ compilers by quite a lot. Also, in my experience, DMD seems to build a LOT slower now that it's in D than it used to when it was C++.
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, 08 Nov 2018 14:35:29 +1300, rikki cattermole wrote: > Its a symptom of a larger set of problems. The frontend is not quite > ready to have the GC turned on full time. > > Based upon my testing, that little memory leak prevents pretty much > *all* memory allocated by the GC to not be collected. I don't know why, > but for some reason it pins it. Mind you, my testing could have been > flawed, and needs more eyes on it *shrug*. In the short term, that means turning on the GC won't do much, but it at least probably won't hurt. In the long term, that bug might be covering up crashes and memory corruption, so turning it on by default is not a great idea.
Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted
On Wednesday, November 7, 2018 6:54:54 PM MST Mike Parker via Digitalmars-d- announce wrote: > I'm happy to announce that Walter and Andrei have rendered their > verdict on DIP 1014. They were in agreement on two points: they > don't like it, but they know we need it. Given that there are no > other alternative proposals and that they could see no > alternative themselves, they decided to accept this DIP without > modification. I think that that probably sums the situation up pretty nicely. The fact that we need something like this is just plain ugly, and if it starts getting used frequently, there's definitely a problem, but there are use cases, where it's going to be invaluable. - Jonathan M Davis
Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted
On Thursday, 8 November 2018 at 01:54:54 UTC, Mike Parker wrote: I'm happy to announce that Walter and Andrei have rendered their verdict on DIP 1014. They were in agreement on two points: they don't like it, but they know we need it. Given that there are no other alternative proposals and that they could see no alternative themselves, they decided to accept this DIP without modification. Thanks to Shachar Shemesh for pushing the DIP through to the end of the process and for his patience throughout. And congratulations on obtaining a successful result. Thanks to all for the hard work. Look forward DIP1016 to be approved.
DIP 1014--Hooking D's struct move semantics--Has Been Accepted
I'm happy to announce that Walter and Andrei have rendered their verdict on DIP 1014. They were in agreement on two points: they don't like it, but they know we need it. Given that there are no other alternative proposals and that they could see no alternative themselves, they decided to accept this DIP without modification. Thanks to Shachar Shemesh for pushing the DIP through to the end of the process and for his patience throughout. And congratulations on obtaining a successful result. I'll be getting the DIP queue moving again in short order. Walter and Andrei are currently considering DIP 1015 [2] and I expect to be able to announce their decision regarding it sooner than normal. I'll be launching the Final Review round for Manu's DIP 1016 [3] in the coming days. And given the approval of this DIP and a sense of urgency underlying the need to fix the flaws of postblit, the next DIP to move out of Draft Review will be Razvan's Copy Constructor proposal [4]. Immediately after that, I'll start pushing the older DIPs into Community Review back-to-back, without pause. [1] https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1014.md [2] https://github.com/dlang/DIPs/blob/8b7650bf491bf6c1c12e994ca7947f031b4480a6/DIPs/DIP1015.md [3] https://github.com/dlang/DIPs/blob/8b7650bf491bf6c1c12e994ca7947f031b4480a6/DIPs/DIP1016.md [4] https://github.com/dlang/DIPs/pull/129
Re: Profiling DMD's Compilation Time with dmdprof
On 08/11/2018 4:17 AM, Neia Neutuladh wrote: On Thu, 08 Nov 2018 01:49:49 +1300, rikki cattermole wrote: On 08/11/2018 1:46 AM, Patrick Schluter wrote: Now that the compiler is completely in D, wouldn't it be a good idea to activate the GC in the compiler. I know that it requires some care for bootstrapping the compiler when there are dependencies to the D runtime, but the compiler would be an excellent example of the advantage of the GC (i.e. dumb fast allocations as long as there's memory, collection when no memory left which is miles away better than to get OOM-killed). No, that would be a bad idea currently. https://issues.dlang.org/show_bug.cgi?id=18811 That issue describes a memory leak. A memory leak of half a megabyte per full compiler invocation on a small file should still result in a lot of code being compilable on low-end machines that currently isn't. Its a symptom of a larger set of problems. The frontend is not quite ready to have the GC turned on full time. Based upon my testing, that little memory leak prevents pretty much *all* memory allocated by the GC to not be collected. I don't know why, but for some reason it pins it. Mind you, my testing could have been flawed, and needs more eyes on it *shrug*.
Re: xlsxd: A Excel xlsx writer
On Wed, Nov 07, 2018 at 04:58:46PM +, Robert Schadek via Digitalmars-d-announce wrote: > On Wednesday, 7 November 2018 at 16:49:58 UTC, H. S. Teoh wrote: > > > > Is there support for reading xlsx files too? > > > > No, Pull Requests are welcome Ah, unfortunately I have no experience working with xlsx or with libxlsx. I was hoping for read access in D so that I can write a simple utility to extract data from xlsx files. Maybe next time. T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Re: Backend nearly entirely converted to D
Slides and video link: http://nwcpp.org/october-2018.html On 11/7/2018 2:08 PM, H. S. Teoh wrote: I don't speak for the compiler devs, but IMO, one-letter variables are OK if they are local, and cover a relatively small scope. Java-style verbosity IMO makes code *harder* to read because the verbosity gets in your face, crowding out the more interesting (and important) larger picture of code structure. As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope: local variable names ought to be concise, but global variables ought to be verbose (both to avoid identifier collision when a larger amount of code is concerned, and also to serve as a convenient visual indication that yes it's a global). Yes, exactly.
Re: Backend nearly entirely converted to D
On Wed, Nov 07, 2018 at 09:49:41PM +, welkam via Digitalmars-d-announce wrote: [...] > One of biggest and needless hurdle I face in reading DMD code is > single letter variable name. If I change one letter variable names to > more descriptive ones would that patch be welcomed or considered > needless change? I don't speak for the compiler devs, but IMO, one-letter variables are OK if they are local, and cover a relatively small scope. Java-style verbosity IMO makes code *harder* to read because the verbosity gets in your face, crowding out the more interesting (and important) larger picture of code structure. As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope: local variable names ought to be concise, but global variables ought to be verbose (both to avoid identifier collision when a larger amount of code is concerned, and also to serve as a convenient visual indication that yes it's a global). T -- An imaginary friend squared is a real enemy.
Re: Backend nearly entirely converted to D
On 11/7/2018 1:49 PM, welkam wrote: One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change? Sorry, it would not be welcome. Single letter names are appropriate for locally defined symbols. There's also an informal naming convention for them, changing the names would disrupt that. Shuffling code around without a very strong reason is also not looked upon favorably. Basically anything that vacuously creates large diffs.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 00:01:13 UTC, Walter Bright wrote: On 11/6/2018 3:00 PM, H. S. Teoh wrote: What sort of refactoring are we looking at? Any low-hanging fruit here that we non-compiler-experts can chip away at? Simply going with foreach loops is a nice improvement. Thas sounds like a job that I can do. At this moment I am reading DMD source code starting from main() because when I tried to understand part of something I wanted to change it felt that to understand something you basically need to understand a third of compiler. One of biggest and needless hurdle I face in reading DMD code is single letter variable name. If I change one letter variable names to more descriptive ones would that patch be welcomed or considered needless change?
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote: I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D What did you compared is whether clang or DMD compiles code faster not whether D code compiles faster than C++. To check that you should compile both C++ and D with the same backend.
Re: xlsxd: A Excel xlsx writer
On Wednesday, 7 November 2018 at 16:41:39 UTC, Robert Schadek wrote: https://code.dlang.org/packages/xlsxd [snip] You folks at Kaleidic keep doing great things.
Re: xlsxd: A Excel xlsx writer
On Wednesday, 7 November 2018 at 16:49:58 UTC, H. S. Teoh wrote: Is there support for reading xlsx files too? No, Pull Requests are welcome
Re: xlsxd: A Excel xlsx writer
On Wed, Nov 07, 2018 at 04:41:39PM +, Robert Schadek via
Digitalmars-d-announce wrote:
> https://code.dlang.org/packages/xlsxd
>
> Announcing xlsxd a OO wrapper for the C library libxlsxwriter [1].
>
> Run:
>
> import libxlsxd;
> auto workbook = newWorkbook("demo.xlsx");
> auto worksheet = workbook.addWorksheet("a_worksheet");
> worksheet.write(0, 0, "Hello to Excel from D");
>
>
> and you have created a Excel spreadsheet in the xlsx format with name
> demo.xlsx
> that contains the string "Hello to Excel from D" in row 0, column 0.
>
> [1] https://github.com/jmcnamara/libxlsxwriter
Is there support for reading xlsx files too?
T
--
Старый друг лучше новых двух.
xlsxd: A Excel xlsx writer
https://code.dlang.org/packages/xlsxd
Announcing xlsxd a OO wrapper for the C library libxlsxwriter [1].
Run:
import libxlsxd;
auto workbook = newWorkbook("demo.xlsx");
auto worksheet = workbook.addWorksheet("a_worksheet");
worksheet.write(0, 0, "Hello to Excel from D");
and you have created a Excel spreadsheet in the xlsx format with
name demo.xlsx
that contains the string "Hello to Excel from D" in row 0, column
0.
[1] https://github.com/jmcnamara/libxlsxwriter
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote:
[snip]
"Hello, MrHaltingProblem here!
We obviously need a @noloops attribute. My co-workers are
constantly writing buggy loops with wrong loop conditions so I
NEED the extra protection. You're asking for a justification?
Trust me, any decent programmer knows the importance of this.
You are just too stubborn to see all the bugs that the lack of
this attribute causes. Asking for real world examples?
```
class Plane {
void doLandingProcedure() {
// lots of code
while (1) {} // OOPS!
// lots of code
}
}
```
There! Now let's discuss the benefit of such a feature in D."
This doesn't look like a compelling argument, so D programmers
would probably suggest making more use of ranges instead.
I get what you're saying here, but just to play devil's advocate,
this feature could be added broadly to D without breaking any
code. In particular, the @disable attribute could be extended to
1) take some input, in this case a keyword (foreach, while, goto,
etc) but potentially also symbols (I'm thinking mainly function
names here), and 2) @disable's behavior could be extended so that
it works with like the protection attributes in terms of being
able to use it as in @disable(keyword) { } or @disable(keyword):.
For a start, something like @nogc and @nothrow are really just a
special cases of @disable(GC) and @disable(Exception), or
something.
Also, the idea could be improved if there was some easy way to
combine multiple attributes (there might be, but I don't know off
the top of my head).
Where I'm coming from is that these attributes aren't really
based on any primitives. They are rather ad hoc. For instance,
even this proposal would need additional work to enable @safe and
pure to be based on primitives. What if someone wanted to make
@disable(template) and have that enforced throughout their code?
What if the decision not to include textual macros in D were
instead set up as a default for @disable(textual_macros)?
Re: LDC 1.13.0-beta1
On Wednesday, 7 November 2018 at 13:23:59 UTC, Jacob Carlborg wrote: Are there any plans on updating the bundled Dub version? It has a regression that was fixed in 1.12.0. I upgraded it one day after releasing beta1, as I sadly forgot to check for a newer dub version before publishing. I.e., the CI builds already feature dub v1.12.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 15:12:13 UTC, Dukc wrote: On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote: I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Because generally, LLVM compilers provide faster code, but compile slower than Digital Mars compilers AFAIK. So if you compile the D code with DMD but C code with LDC, the program will likely compile faster but execute slower as increasing portions are written in D, compared to using the same backend for both languages. I'm not sure if you benchmarked the time used to build DMD, or the time used by generated DMD to compile some other program. If it was the former, the "real" result is probably worse than your results. But if it was the latter, it is likely better. The former, if it wasn't clear. It's also possible something slowed down building the frontend in successive DMD versions, so ideally I'd only time building the backend for each DMD version, but I haven't looked into that.
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, 08 Nov 2018 01:49:49 +1300, rikki cattermole wrote: > On 08/11/2018 1:46 AM, Patrick Schluter wrote: >> Now that the compiler is completely in D, wouldn't it be a good idea to >> activate the GC in the compiler. I know that it requires some care for >> bootstrapping the compiler when there are dependencies to the D >> runtime, >> but the compiler would be an excellent example of the advantage of the >> GC (i.e. dumb fast allocations as long as there's memory, collection >> when no memory left which is miles away better than to get OOM-killed). > > No, that would be a bad idea currently. > > https://issues.dlang.org/show_bug.cgi?id=18811 That issue describes a memory leak. A memory leak of half a megabyte per full compiler invocation on a small file should still result in a lot of code being compilable on low-end machines that currently isn't.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 14:39:55 UTC, Joakim wrote: I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Because generally, LLVM compilers provide faster code, but compile slower than Digital Mars compilers AFAIK. So if you compile the D code with DMD but C code with LDC, the program will likely compile faster but execute slower as increasing portions are written in D, compared to using the same backend for both languages. I'm not sure if you benchmarked the time used to build DMD, or the time used by generated DMD to compile some other program. If it was the former, the "real" result is probably worse than your results. But if it was the latter, it is likely better.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 11:22:13 UTC, Dukc wrote: On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote: I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each: 2.081.2 - 11.5s 2.082.1 - 10.5s 2.083.0 - 9.9s master - 10.8s Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down Could this be because you used a LLVM compiler for the C code but a Mars compiler for D code? If one either uses DMC for C or LDC for D, perhaps the results will be better. I don't know why you think that would matter: I'm using the same compilers to build each DMD version and comparing the build times as the backend was translated to D. Maybe I'd get different results by using different compilers, but these are two fairly fast and commonly used compilers so they're worth checking with.
Re: LDC 1.13.0-beta1
On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient I'm late to the thank-you party, but yes, this is huge for me, too. I develop on Linux. For Windows binaries, I've run the DMD 32-bit toolchain in Wine because I've shied away from installing MSVS to create 64-bit Windows binaries. The LDC Win64 beta was a breeze to get working in Wine, looking forward to use it! -- Simon
Re: Backend nearly entirely converted to D
On 2018-11-06 23:12, Walter Bright wrote: The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions. Still need some of those for GDC and LDC. Until we have a tool that can automatically generate them. -- /Jacob Carlborg
Re: LDC 1.13.0-beta1
On 2018-11-02 22:04, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements for GDB. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 Thanks to all contributors! It's awesome to see that you have a version based on DMD 2.083.0 already. Are there any plans on updating the bundled Dub version? It has a regression that was fixed in 1.12.0. -- /Jacob Carlborg
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 7 November 2018 at 11:00:49 UTC, TheFirefighter
wrote:
Now. How many C++/Java/C# programmers are there?
Even if a `super private` attribute or something is introduced,
the semantics of private in D will not change. Your hypothetical
C# programmer who switches to D assuming identical visiblity
semantics to C# will still write that program that makes the
plane crash. Luckily Java programmers write one class per file
anyway.
On Wednesday, 7 November 2018 at 11:00:49 UTC, TheFirefighter
wrote:
First, nobody needs to explain the problems that type errors
create.
Any decent programmer should already be well aware of such
problems.
Look, you can keep making new accounts and restating that it's so
obvious you don't need to convince anyone, and that D programmers
are just stubborn. But it won't help advancing the discussion
like you want.
If you can't show that there are actual programmers writing
appropriately sized modules containg bugs simply because of the
lack of a class-private visibility level, then people don't want
to engineer a solution to a seemingly non-existant problem, write
and maintain the compiler code + specification for it, update
existing tutorials, editors and tools, inform existing users
about the change, and making the language more complex overall.
Imagine if I made a proposal like this:
"Hello, MrHaltingProblem here!
We obviously need a @noloops attribute. My co-workers are
constantly writing buggy loops with wrong loop conditions so I
NEED the extra protection. You're asking for a justification?
Trust me, any decent programmer knows the importance of this. You
are just too stubborn to see all the bugs that the lack of this
attribute causes. Asking for real world examples?
```
class Plane {
void doLandingProcedure() {
// lots of code
while (1) {} // OOPS!
// lots of code
}
}
```
There! Now let's discuss the benefit of such a feature in D."
This doesn't look like a compelling argument, so D programmers
would probably suggest making more use of ranges instead.
Re: Profiling DMD's Compilation Time with dmdprof
On 08/11/2018 1:46 AM, Patrick Schluter wrote: Now that the compiler is completely in D, wouldn't it be a good idea to activate the GC in the compiler. I know that it requires some care for bootstrapping the compiler when there are dependencies to the D runtime, but the compiler would be an excellent example of the advantage of the GC (i.e. dumb fast allocations as long as there's memory, collection when no memory left which is miles away better than to get OOM-killed). No, that would be a bad idea currently. https://issues.dlang.org/show_bug.cgi?id=18811
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 21:52:30 UTC, H. S. Teoh wrote: On Tue, Nov 06, 2018 at 07:44:41PM +, Atila Neves via Digitalmars-d-announce wrote: On Tuesday, 6 November 2018 at 18:00:22 UTC, Vladimir Panteleev wrote: > This is a tool + article I wrote in February, but never got > around to finishing / publishing until today. > > https://blog.thecybershadow.net/2018/02/07/dmdprof/ > > Hopefully someone will find it useful. Awesome, great work! I really really hate waiting for the compiler. OTOH, I really really hate that the compiler, in the name of faster compilation, eats up all available RAM and gets OOM-killed on a low memory system, so no amount of waiting will get me an executable. Now that the compiler is completely in D, wouldn't it be a good idea to activate the GC in the compiler. I know that it requires some care for bootstrapping the compiler when there are dependencies to the D runtime, but the compiler would be an excellent example of the advantage of the GC (i.e. dumb fast allocations as long as there's memory, collection when no memory left which is miles away better than to get OOM-killed).
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 08:31:21 UTC, Joakim wrote: I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each: 2.081.2 - 11.5s 2.082.1 - 10.5s 2.083.0 - 9.9s master - 10.8s Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down Could this be because you used a LLVM compiler for the C code but a Mars compiler for D code? If one either uses DMC for C or LDC for D, perhaps the results will be better.
Re: Blog post on fearless (library for @safe sharing)
On Wednesday, 7 November 2018 at 10:58:35 UTC, Atila Neves wrote: Definitely worth it. Nice to hear. And nice that you put it to use! I'm still unclear on the non-transitivity of scope and exactly what the consequences of this rule: 3. A scope variable cannot be initialized with the address of a scope variable. (If it did it would lose the scope attribute of the latter's contents.) I can neither undertand that. If you initialize a scope variable, it should be guaranteed to have a shorter lifetime than any pre-existing variable, so it should not be a problem to use pre-existing addresses (as I understand it).
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Monday, 5 November 2018 at 11:07:11 UTC, Mike Parker wrote:
So where are these teams of imperfect D programmers who are
plagued by accidental modifications of private class members?
Sociomantic? Funkwerk? Weka?
First, nobody needs to explain the problems that type errors
create.
Any decent programmer should already be well aware of such
problems.
Second, it's a matter of scale. How many D programmers are there?
The probability that someone will do something silly, like below,
will increase with scale. That's just how it is.
Now. How many C++/Java/C# programmers are there?
And, since the chance of error will increase with the number of
users (and also the number of lines) how many of them would find
that their compiler will happily compile the code below?
and the is answer: zero
no matter how many of them - it'll *always* be zero.
unless they do it in D.
--
module test;
class Firefighter
{
private void DoSomethingATraineeShouldNotDo() {}
}
class TraineeFirefighter : Firefighter {}
unittest
{
TraineeFirefighter joe = new TraineeFirefighter();
joe.DoSomethingATraineeShouldNotDo();
}
--
Re: Blog post on fearless (library for @safe sharing)
On Wednesday, 7 November 2018 at 10:16:43 UTC, Dukc wrote: On Tuesday, 6 November 2018 at 16:20:00 UTC, Atila Neves wrote: https://www.reddit.com/r/programming/comments/9uoak1/implementing_rusts_stdsyncmutex_in_d/ Good post. Since you have battle-tested DIP1000, I'm interested what you think about it. You mentioned that it's currently hard to understand, but what you think about the concept as whole? How useful it seems, and is it worth it? Definitely worth it. I think editing the DIP1000 document to make it reflect reality would be a good start. I kept using `scope` where I should have used `return` and that's really what confused me. I'm still unclear on the non-transitivity of scope and exactly what the consequences of this rule: 3. A scope variable cannot be initialized with the address of a scope variable. (If it did it would lose the scope attribute of the latter's contents.)
Re: Blog post on fearless (library for @safe sharing)
On Tuesday, 6 November 2018 at 16:20:00 UTC, Atila Neves wrote: https://www.reddit.com/r/programming/comments/9uoak1/implementing_rusts_stdsyncmutex_in_d/ Good post. Since you have battle-tested DIP1000, I'm interested what you think about it. You mentioned that it's currently hard to understand, but what you think about the concept as whole? How useful it seems, and is it worth it?
Re: Backend nearly entirely converted to D
On Tuesday, 6 November 2018 at 22:12:02 UTC, Walter Bright wrote: With the recent merging of the last of the big files machobj.d: https://github.com/dlang/dmd/pull/8911 I'm happy to say we're over the hump in converting the backend to D! Great! Although I wish it didn't have to be you mostly doing this grunt work. Remaining files are minor: tk.c, cgen.c, dt.c, fp.c, os.c, outbuf.c, sizecheck.c, strtold.c and mem.c. I'll probably leave a couple in C anyway - os.c and strtold.c. sizecheck.c will just go away upon completion. Thanks to everyone who helped out with this! Of course, the code remains as ugly as it was in C. It'll take time to bit by bit refactor it into idiomatic D. I just benchmarked building the last couple versions of DMD, when most of the backend was converted to D, by building them with the latest DMD 2.083.0 official release and clang 6.0 in a single-core linux/x64 VPS. Here are the times I got, best of 3 runs for each: 2.081.2 - 11.5s 2.082.1 - 10.5s 2.083.0 - 9.9s master - 10.8s Not quite the gains hoped for, particularly with those last large files you just converted to D seemingly slowing compilation down, but maybe it will get better with refactoring and when the entire backend is compiled at once, rather than the DMD separate compilation used now. The more immediate benefit is to get rid of all the parallel .h files, which were a constant source of bugs when they didn't match the .d versions. I was going to ask why you wouldn't need those headers for your C/C++ compiler, DMC, but it looks like you've translated that to mostly D already: https://github.com/DigitalMars/Compiler/tree/master/dm/src/dmc
