Re: Profiling DMD's Compilation Time with dmdprof
On 09/11/2018 00:12, kinke wrote: > On Thursday, 8 November 2018 at 20:19:47 UTC, Vladimir Panteleev wrote: >> Sounds like we're narrowing it down to the Visual Studio solution. > > Mildly interested, I gave DMD master a shot with my 5-years old i5-3550 > (@4 GHz) in VS 2017 (+ a recent Visual D beta): > > DMD v2.083.0-beta1 host compiler > --- > Win32-Debug: 12 secs > Win32-Release: 1m 58 secs > > LDC v1.13.0-beta1 host compiler > --- > Win32-Debug: 22 secs > Win32-Release: 1m 28 secs > Similar numbers for me too. Please note that the auto-tester shows similar values for release builds on all platforms, so I suspect very low numbers reported here are debug build timings. > DMD's `-inline` is known to be *slow*. Pedantically, it's not the inliner by itself, but the optimizer that cannot cope with large functions. With some improved inlining capabilities that got worse over time. Visual Studio only provides parallel compilation of projects out of the box, you have to add it yourself for your favorite language for parallelization within a project. Igor has done that for the msbuild integration of dmd and LDC (https://github.com/dlang/visuald/pull/94), but the PR has kind of stalled due to some undesirable side effects. Unfortunately, single file compilation is pretty slow, so there is not so much gain from switching from building per package to single file parallel compilation unless you have many cores.
Re: textattr library for text colors and attributes available in D
On Thursday, 8 November 2018 at 19:26:15 UTC, Bastiaan Veelo wrote: Cool, must remember this in case I need it one day. Do you have plans to add it to the dub registry? Don't know how. Can follow instructions if provided. Does DUB also allow multi-language libs one of which is D? Unfortunately my D usage isn't as much as I'd like it to be so haven't kept up so closely…
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter wrote: No it is not. You can keep saying there is, but it doesn't make it so. ... We don't seem to be on the same page here...do you misunderstand what I want? Fair enough, the exact thing you want is not possible. I understand that. It's also a fact that you can't have a value-type class. But just because you can't have a value type *class* doesn't mean you can't have a value-type aggregate: there is struct. The higher goal of encapsulating classes is possible by writing one per module and using package.d, it's just not possible with the restriction that multiple classes must be in the same file. Regarding the 'burden' to the D langauge, by providing the programmer with a tool to specify better encapsulation of code *within* the module: [quote] i.e. better encapsulation really is a good thing (although for many, it a lesson that needs to be learned). Walter considers the module the lowest level of encapsulation, while you consider the class to be that. Neither is proven to be better so far. To change the D language in that regard, you have to convince people that class-private is superior/important enough to warrant the language change. Unfortunately, the arguments given so far have not done that yet, since they mostly appeal to feeling, fear and 'the obvious' as mentioned earlier.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 8 November 2018 at 13:18:30 UTC, Dennis wrote: That sounds like "I just want there to be the option for aggregate value types... without using struct.". The question this raises is why the current solution is so problematic. I just want (for example) to be able to write a module, that contains a class, and also has non-member, non-friend functions. You simply cannot do that in a D module, as the class has no clothes - to extend the metaphor from my recent post. I refer you to Scott Meyers article about the benefits of having 'non-friend' non-member functions: How Non-Member Functions Improve Encapsulation (btw. people misread that title - it should be been "How Non-Friend, Non-Member..." http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197?pgno=1 Do you agree that language additions add a lot of weight? If yes, then it's simply the fact that people don't think your suggestion bears that weight because it's already possible to do what you want in another way. No it is not. You can keep saying there is, but it doesn't make it so. We don't seem to be on the same page here...do you misunderstand what I want? Fact: I cannot have a class in a module, and specify (so that the compiler can enforce it) that I want other code in the module to respect the specification of that class. It just cannot happen. Don't say it can. It can't. It's fact. As a result, one of my core guidelines are not applicable anymore, if I used D: " Don’t force together into a module things that will be used or maintained separately, and don’t separate things that will always be used and maintained together." Regarding the 'burden' to the D langauge, by providing the programmer with a tool to specify better encapsulation of code *within* the module: "I have become more and more convinced that the key to code reusability and scalability is encapsulation — having subsystems communicate through small, well-defined interfaces and letting them hide their own implementation details." - Walter Bright http://www.drdobbs.com/cpp/uniform-function-call-syntax/232700394?queryText=Scott%2BMeyers i.e. better encapsulation really is a good thing (although for many, it a lesson that needs to be learned).
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 20:19:47 UTC, Vladimir Panteleev wrote: Sounds like we're narrowing it down to the Visual Studio solution. Mildly interested, I gave DMD master a shot with my 5-years old i5-3550 (@4 GHz) in VS 2017 (+ a recent Visual D beta): DMD v2.083.0-beta1 host compiler --- Win32-Debug: 12 secs Win32-Release: 1m 58 secs LDC v1.13.0-beta1 host compiler --- Win32-Debug: 22 secs Win32-Release: 1m 28 secs DMD's `-inline` is known to be *slow*.
Re: Backend nearly entirely converted to D
On 11/8/2018 9:23 AM, welkam wrote:
And where can i read about naming convention? My guess its not documented
anywhere and would not be in foreseeable future or ever. Also are you sure you
are not talking about two letter variables like
sc for scope
fd for function declaration
td for template declaration
That is a naming convention. No, it's not documented. There's also `e` for
Expression. `i` for loop index. Etc.
What I want
to do is change variables like m. Try guessing what it is used for.
I don't need to guess. I look at its declaration a few lines up.
What I dont understand is that you are against changing variable names that
would improve code understandability
This is where we diverge:
Expression expression = new IntegerExp(loc, 1);
expression = expression.expressionSemantic(sc);
expression = resolveProperties(sc, expression);
is just exhausting compared with:
Expression e = new IntegerExp(loc, 1);
e = e.expressionSemantic(sc);
e = resolveProperties(sc, e);
but you are not against changing for loops
to foreach that add almost nothing to code readability and only look better.
Looking better is improving readability.
foreach (m; modules)
{
...
}
is much more readable than:
for (size_t i = 0; i < modules.dim; ++i)
{
Module m = modules[i];
...
}
and much less prone to typo bugs. The for loop also is dependent on abstraction
leak of modules[] being an array, whereas foreach only requires that the
abstraction be traverse-able.
What you dont know about me is that I worked as code reviewer/tester/merger at
PHP shop and know full well why you want pull requests the way you want. I also
know how much less easier it is to review simple changes like foreach loop
changes and simple variable renaming
It's great that you have valuable experience with this. Renaming variables,
however, is not what I'm looking for. What I am looking for is using D to fix
leaky abstractions, using const and pure, minimizing use of global mutable
state, reducing the amount of code one must learn to make useful changes,
reducing code duplication, minimizing the lifetime of variables, improving
performance, etc.
For some more thoughts on this, check out my recent presentation on it:
http://nwcpp.org/october-2018.html
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 18:52:02 UTC, H. S. Teoh wrote: length is getting ridiculous Having better editor support is nice but by "use better editor" you meant use vim dont you? And even if I switch to vim it wont solve my initial objection to one letter variable names. Its needless hurdles. Not to mention the next person new to this will likely have same problems like me. And the person after that etc. Which comes to my recurring thought when dealing with dmd. How the f@#k should I knew that? Documentation and instructions around D project is almost non existant. Does idea pit of success not apply to compiler? Human brain is good at finding patterns. Its also good at finding patters it wants to find where they dont exist. Your statement that humans have no problems in disambiguating language is completely false. Most people just ignore logical conflicts or lack of information needed to correctly understand what is being said. Most people dont put lots of effort in understanding what exactly is being said and humans are bad at conveying their thoughts trough words to begin with. Extreme case of this is all forms of religious believes. Here is a clip where people give definitions of God and none of them are the same https://youtu.be/HhRo9ABvef4 and here is one where J.P. at least tries to disambiguate words. https://youtu.be/q0O8Jw6grro When people talk about God first they cant tell precisely what they believe. Second they dont know precisely what others believe. And third it doesnt even matter as long as you make vaguely sounding sentences. Same extends to the rest of human interactions and humans would happily go without noticing that until they have to interact with computers where you have to define everything precisely. Your second idea that shorter words have less information is... just... What? English is not floating point where length dictates precision. In German maybe with one word created from combining multiple but not in English. Then you combined your both flawed ideas to produce paragraph where good and bad ideas are mixed together. No I did not strawman. I took Walters advice from NWCPP talk precisely to show a flow in it. If variable name lenght should be related to scope then changing scope should change variable name lenght. You on the other hand changed advice to binary advice. Either local and short or global and verbose NWCPP talk https://youtu.be/lbp6vwdnE0k?t=444 Code is read more often than written and should be optimized for that. One letter variable names are not descriptive enough. In short functions you can get away from paying mental price but in long ones you do not.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 20:19:47 UTC, Vladimir Panteleev wrote: On Thursday, 8 November 2018 at 19:07:32 UTC, Jacob Carlborg wrote: 21 seconds on a Windows 10 virtual machine compiling using the win32.mak file. Sounds like we're narrowing it down to the Visual Studio solution. Well, I'm just using win32.mak in a command prompt and it takes ~1m 40s to build DMD. It just seems to do nothing for most of that time.
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 19:07:32 UTC, Jacob Carlborg wrote: 21 seconds on a Windows 10 virtual machine compiling using the win32.mak file. Sounds like we're narrowing it down to the Visual Studio solution.
Re: textattr library for text colors and attributes available in D
On Thursday, 8 November 2018 at 13:37:08 UTC, Shriramana Sharma wrote: https://github.com/jamadagni/textattr/ textattr is a library and command-line tool that makes adding color and attributes to beautify the terminal output of your program easier by translating human-readable specs into ANSI escape codes. The library is available for C, C++, Python and D. C++ and Python use the C code for internal processing but the D code is a separate implementation for easy inclusion of textattr.d in a D compilation command without requiring any external linking. Copyright: Shriramana Sharma, 2018 License: BSD-2-Clause Cool, must remember this in case I need it one day. Do you have plans to add it to the dub registry?
Re: Profiling DMD's Compilation Time with dmdprof
On 2018-11-08 18:25, Jacob Carlborg wrote: This is my result on macOS: $ $ make -f posix.mak clean $ time make -f posix.mak -j 16 real 0m3.127s user 0m5.478s sys 0m1.686s 21 seconds on a Windows 10 virtual machine compiling using the win32.mak file. -- /Jacob Carlborg
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 18:48:05 UTC, Neia Neutuladh wrote: On Thu, 08 Nov 2018 18:38:55 +, welkam wrote: On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote: One keystroke (well ok, two keys because it's *) ;) https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png What sorcery is this? I need to know. I guess its vim but how does it highlight symbols? By default, when you search for something in vim, it highlights all matches (as well as moving the cursor to the next match). The '*' command is 'search for the word under the cursor'. "Near", not "under". But yup, key is "word", i.e. with a very concise keystroke you get a highlighted search for a (in that case) "\". If I were to search for just "m", I'd get the same soup as in welkam's first screenshot.
Re: Backend nearly entirely converted to D
On Thu, Nov 08, 2018 at 06:38:55PM +, welkam via Digitalmars-d-announce wrote: > On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote: > > > > One keystroke (well ok, two keys because it's *) ;) > > https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png > > > > What sorcery is this? I need to know. I guess its vim but how does it > highlight symbols? As I've said, it highlights symbols based on *word* match, not substring match, which apparently your editor does. The latter is flawed, and probably is what led you to your conclusions. I suggest looking for an editor with a better syntax highlighter / search function. T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.
Re: Backend nearly entirely converted to D
On Thu, Nov 08, 2018 at 05:50:20PM +, welkam via Digitalmars-d-announce wrote: > On Wednesday, 7 November 2018 at 22:08:36 UTC, 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. > > By saying more descriptive I should have clarified that I meant to > change them to 3-7 letter names. Small variable names are ok for small > functions like the one in attrib.d called void importAll(Scope* sc). > It has variable named sc and its clear where it is used. > > Now for all of you who think that one letter variables are ok here is > exercise. Go and open src/dmd/func.d with your favorite code editor. > Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC > long. Now find all uses of variable Dsymbol s. Did you found them all? > Are you sure? Yes. My editor knows to search for 's' delimited by word boundaries, so it would not match 's' in the middle of the word, but only 's' surrounded by non-alphabetic characters. > Ok now do the same for variable loc. See the difference? I see no difference. Moral: use a better editor. :-P > > 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. > > What editor do you use? Vim. And I don't even use syntax highlighting (because I find it visually distracting). > Here is the worst example to prove my point but its still sufficient. All > editors worth your time highlights the same text when selected and here is > example of one letter variable. > https://imgur.com/a/jjxCdmh > and tree letter variable > https://imgur.com/a/xOqbkmn Your syntax highlighter is broken. It should not match substrings, but only the entire word. Vim's search function does this (including the highlights, if I turned it on, but by default I leave it off). > where is all that crowding and loss of large picture you speak of? Its > the opposite. Code structure is more clear with longer variable names > than one letter. Your opinion is biased by using a flawed syntax highlighter / symbol search function. > > As Walter said in his recent talk, the length of variable names (or > > identifiers in general, really) should roughly correspond to their > > scope > > At best this is argument form authority. You said how thing should be > not why. For argument sake imagine situation where you need to expand > function. By your proposed rules you should rename local variables to > longer names. Thats ridiculous. Yes I watched that presentation and > fully disagree with Walter and know for sure he doesnt have sound > argument to support his position. [...] It's very simple. The human brain is very good at context-sensitive pattern matching, something which computers are rather poor at (well, at least, traditional algorithms that aren't neural-network based). Natural language, for example, is full of ambiguities, but in everyday speech we have no problems figuring out what is meant, because the context supplies the necessary information to disambiguate. Therefore, frequently-used words tend to be short (and tend to shorten over time), because it's not necessary to enunciate the full word or phrase to convey the meaning. Rarely-used words tend to be longer (and resist simplification over time) because context provides less information, and so the full word becomes necessary in order to minimize information loss. Function parameters and local variables are, by definition, restricted in scope, and therefore the context of the function provides enough information to disambiguate short names. And since local variables and parameters would tend to be used frequently, the brain prefers to simplify and shorten their identifiers. As a result, after acclimatizing, one begins to expect that short names correspond with local variables, and long names correspond with non-local variables. Going against this natural expectation (e.g., long names for locals, short names for globals) causes extra mental load to resolve the referents. Your counterargument of expanding a function and needing to rename local variables is a strawman. A function is a function, and local variables don't need to be renamed just because you added more code into it. (However, there *is* a point that when the function starts getting too long, it ought to be split into separate functions, otherwise it becomes harder to understand. On that point, I do agree with you that dmd's code could stand improvement, since 900-line functions are definitely far too long to keep the entire context in short-term memory, and so using short local identifiers begins to lose its benefits and increase its disadvantages.) T -- Many open minds should be closed for repairs. -- K5 user
Re: Backend nearly entirely converted to D
On Thu, 08 Nov 2018 18:38:55 +, welkam wrote: > On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote: >> >> One keystroke (well ok, two keys because it's *) ;) >> https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png >> >> > What sorcery is this? I need to know. I guess its vim but how does it > highlight symbols? By default, when you search for something in vim, it highlights all matches (as well as moving the cursor to the next match). The '*' command is 'search for the word under the cursor'. The rest is just basic syntax highlighting.
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 18:15:55 UTC, Stanislav Blinov wrote: One keystroke (well ok, two keys because it's *) ;) https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png What sorcery is this? I need to know. I guess its vim but how does it highlight symbols?
Re: Backend nearly entirely converted to D
On Thu, Nov 08, 2018 at 06:13:55PM +0100, Jacob Carlborg via Digitalmars-d-announce wrote: [...] > I guess we have very different ideas on what "small scope" is. For me > it means around 10 lines. Here's an example in the DMD code base, the > method for doing the semantic analyze on a call expression [1]. It's > 902 lines long and has a parameter called "exp". Another example, the > semantic analyze for an is expression [2], 310 lines long. It has a > parameter called "e". > > Someone familiar with the code base might know that the convention is > that a variable of a type inheriting from the Expression class is > usually called "e". Someone new to the code base will most likely not. > I cannot see how starting to call the variable "expression" or > "callExpression" would be disrupt. Currently when someone familiar > with the code base reads the code and sees a variable named "e" the > developer will think "hey, I know by convention that is usual an > expression". If the variable was renamed to "expression" then both the > one familiar and unfamiliar with the code base can immediately read > that this variable holds an expression. [...] A function parameter named 'expression' is far too long. I wouldn't go as far as calling it 'e', but maybe 'expr' is about as long as I would go. You're dealing with the code of a compiler, 'expr' should be blatantly obvious already that it means "expression". Spelling it out completely just clutters the code and makes it harder to read. T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel
Re: Backend nearly entirely converted to D
On Thu, 08 Nov 2018 18:13:55 +0100, Jacob Carlborg wrote: > I guess we have very different ideas on what "small scope" is. For me it > means around 10 lines. Here's an example in the DMD code base, the > method for doing the semantic analyze on a call expression [1]. It's 902 > lines long and has a parameter called "exp". Another example, the > semantic analyze for an is expression [2], 310 lines long. It has a > parameter called "e". I recall opening up the source code some years ago, encountering a long function, and seeing variables `e` and `e2` that were reused for *probably* different purposes but I honestly couldn't tell. Having them named `expression` and `expression2` would have saved me about five seconds total, which wouldn't have been particularly worthwhile. Giving them names that reflected how they were being used would have been quite helpful -- at the very least, it would have given a weak indication that they were not being reused for different purposes.
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, Nov 08, 2018 at 06:25:06PM +0100, Jacob Carlborg via Digitalmars-d-announce wrote: > On 2018-11-08 05:16, Manu wrote: > > > 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. > > This is my result on macOS: > > $ $ make -f posix.mak clean > $ time make -f posix.mak -j 16 > real 0m3.127s > user 0m5.478s > sys 0m1.686s [...] Result on Debian/Linux (amd64): real0m8.445s user0m11.088s sys 0m1.453s Slower than C++ compilers?! That's impossible. There must be something wrong with your setup, or else with your OS. Dmd is easily one of the fastest compilers I've ever used, even after the noticeable slowdown when we started bootstrapping from D. G++, for example, is at least an order of magnitude slower. On my system, anyway. YMMV obviously. (Of course, it depends on what D features you use... template-heavy and CTFE-heavy code tends to slow it down pretty badly. But still, it's pretty fast compared to g++.) T -- Who told you to swim in Crocodile Lake without life insurance??
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 17:50:20 UTC, welkam wrote: On Wednesday, 7 November 2018 at 22:08:36 UTC, H. S. Teoh wrote: Now for all of you who think that one letter variables are ok here is exercise. Go and open src/dmd/func.d with your favorite code editor. Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC long. Now find all uses of variable Dsymbol s. Did you found them all? Are you sure? Ok now do the same for variable loc. See the difference? If we were to look for an s of a specific type, it's not just the editor we would need, now would we? 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. What editor do you use? Here is the worst example to prove my point but its still sufficient. All editors worth your time highlights the same text when selected and here is example of one letter variable. https://imgur.com/a/jjxCdmh and tree letter variable https://imgur.com/a/xOqbkmn One keystroke (well ok, two keys because it's *) ;) https://dl.dropbox.com/s/mifou0ervwspx5i/vimhl.png where is all that crowding and loss of large picture you speak of? Its the opposite. Code structure is more clear with longer variable names than one letter. I don't think H.S. meant one letter vs. three. Java tends to be obtusely verbose. Wear down your fingers/eyes kind of verbose. As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope At best this is argument form authority. You said how thing should be not why. For argument sake imagine situation where you need to expand function. By your proposed rules you should rename local variables to longer names. Thats ridiculous. Yes I watched that presentation and fully disagree with Walter and know for sure he doesnt have sound argument to support his position. IMHO, one/two letters are fine so long as the variable's scope spans at most two pages. If scope is larger, name should be longer.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 22:08:36 UTC, 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. By saying more descriptive I should have clarified that I meant to change them to 3-7 letter names. Small variable names are ok for small functions like the one in attrib.d called void importAll(Scope* sc). It has variable named sc and its clear where it is used. Now for all of you who think that one letter variables are ok here is exercise. Go and open src/dmd/func.d with your favorite code editor. Find function FuncDeclaration resolveFuncCall(). Its around 170 LOC long. Now find all uses of variable Dsymbol s. Did you found them all? Are you sure? Ok now do the same for variable loc. See the difference? 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. What editor do you use? Here is the worst example to prove my point but its still sufficient. All editors worth your time highlights the same text when selected and here is example of one letter variable. https://imgur.com/a/jjxCdmh and tree letter variable https://imgur.com/a/xOqbkmn where is all that crowding and loss of large picture you speak of? Its the opposite. Code structure is more clear with longer variable names than one letter. As Walter said in his recent talk, the length of variable names (or identifiers in general, really) should roughly correspond to their scope At best this is argument form authority. You said how thing should be not why. For argument sake imagine situation where you need to expand function. By your proposed rules you should rename local variables to longer names. Thats ridiculous. Yes I watched that presentation and fully disagree with Walter and know for sure he doesnt have sound argument to support his position.
Re: Profiling DMD's Compilation Time with dmdprof
On 2018-11-08 05:16, Manu wrote: 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. This is my result on macOS: $ $ make -f posix.mak clean $ time make -f posix.mak -j 16 real0m3.127s user0m5.478s sys 0m1.686s -- /Jacob Carlborg
Re: Backend nearly entirely converted to D
On 2018-11-08 18:23, welkam wrote: but you are not against changing for loops to foreach that add almost nothing to code readability and only look better. Changing to a foreach loop definitely adds to readability and to be able to better understand the code. If you read the "foreach" keyword you know that to a 99% possibility the code that follows is a loop that will iterate a collection from start to end. If you read the keyword "for" you basically know nothing. It can mean iterating a collection, copy some random memory or whatever. -- /Jacob Carlborg
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 22:03:20 UTC, Walter Bright wrote: Single letter names are appropriate for locally defined symbols. There's also an informal naming convention for them, changing the names would disrupt that. And where can i read about naming convention? My guess its not documented anywhere and would not be in foreseeable future or ever. Also are you sure you are not talking about two letter variables like sc for scope fd for function declaration td for template declaration because I am not proposing to change them. They are 26 times better than one letter names and changing them would not bring significant benefit. What I want to do is change variables like m. Try guessing what it is used for. Hint it is used for different things. What I dont understand is that you are against changing variable names that would improve code understandability but you are not against changing for loops to foreach that add almost nothing to code readability and only look better. What you dont know about me is that I worked as code reviewer/tester/merger at PHP shop and know full well why you want pull requests the way you want. I also know how much less easier it is to review simple changes like foreach loop changes and simple variable renaming
Re: Backend nearly entirely converted to D
On 2018-11-07 23:58, Walter Bright wrote: 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. I guess we have very different ideas on what "small scope" is. For me it means around 10 lines. Here's an example in the DMD code base, the method for doing the semantic analyze on a call expression [1]. It's 902 lines long and has a parameter called "exp". Another example, the semantic analyze for an is expression [2], 310 lines long. It has a parameter called "e". Someone familiar with the code base might know that the convention is that a variable of a type inheriting from the Expression class is usually called "e". Someone new to the code base will most likely not. I cannot see how starting to call the variable "expression" or "callExpression" would be disrupt. Currently when someone familiar with the code base reads the code and sees a variable named "e" the developer will think "hey, I know by convention that is usual an expression". If the variable was renamed to "expression" then both the one familiar and unfamiliar with the code base can immediately read that this variable holds an expression. [1] https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L3812-L4713 [2] https://github.com/dlang/dmd/blob/c3dcc76327cdd1cebd9767d9ce738bcbc4db2beb/src/dmd/expressionsem.d#L4924-L5233 -- /Jacob Carlborg
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: 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 think the default posix.mak target is neither a debug nor a release build, meaning it is neither optimized nor has the additional asserts/invariants of a debug build. Not sure the Visual Studio solution has that, but perhaps it could be an acceptable middle ground. 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... Well, my latest test was against master, that even has parts of the backend apparently converted to D, so I'm not sure that's relevant.
Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted
On Thursday, 8 November 2018 at 03:04:06 UTC, Jonathan M Davis wrote: 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 This pull request is undoubtedly a major factor of Walter and Andrei approval of DIP 1014 https://github.com/dlang/druntime/pull/2310 Alex
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: 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? The problem definitely looks like is with your Windows. Perhaps it's caused by an antivirus software? For the record on my machine it's consistently below 4sec. See: https://asciinema.org/a/G5lLRPsLLMb5IaqPrmhZagop4
textattr library for text colors and attributes available in D
https://github.com/jamadagni/textattr/ textattr is a library and command-line tool that makes adding color and attributes to beautify the terminal output of your program easier by translating human-readable specs into ANSI escape codes. The library is available for C, C++, Python and D. C++ and Python use the C code for internal processing but the D code is a separate implementation for easy inclusion of textattr.d in a D compilation command without requiring any external linking. Copyright: Shriramana Sharma, 2018 License: BSD-2-Clause
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 8 November 2018 at 09:53:59 UTC, TheFireFighter wrote: well you could say the same about pointers. but..what happens when a large number of programmers start using pointers? I don't see the parallel between pointers and class-private. But my argument actually is less about bugs, or the potential for bugs (although that potential obviously exists). My argument is more about the 'untyped' nature of the D module. That's a shame, I think the bug-argument is the stronger one. Now, if you're one of those that object to the use of classes (and there are many in the D forums), then you would already be biased towards dismissing my argument, and don't mind at all if the class is subject to humiliation. I would prefer you refrain from the discussion, if such bias is going to be used to shutdown the argument. My guess, based on my experience, is that bad coders will seek the shortest path to something that works. So if they need to quickly access a class-private member in the module they're working on, they'll remove the private attribute. But I don't know, I'm biased like everyone. I haven't worked in the same setting as you. That's why I'm really interested in hearing your perspective. I don't have a strong opinion on the importance of visibility attributes within a module, so I'm interested in hearing strong arguments from you. But so far, your arguments boil down to: - Avoiding justification - "Obviously" "I don't have to explain this" "Any decent programmer knows this" - Appeal to fear - "Just wait for all the problems that come in the future!" - Appeal to feeling - "Classes are naked, humiliated, their private parts are violated. That's so clearly wrong." I don't find such arguments strong. If they were, you could also justify adding the @noloops attribute as I jokingly did in my previous post. Lets be clear. My argument (not my DIP - as there is none) is, that it can only strengthen D, if D allowed the programmer the option (just the option) to ensure that a class wasn't subjected to such humiliation, when there is other code in the module besides that class. That sounds like "I just want there to be the option for aggregate value types... without using struct.". The question this raises is why the current solution is so problematic. I do not understand the motivations of those that reject such an argument. Do you agree that language additions add a lot of weight? If yes, then it's simply the fact that people don't think your suggestion bears that weight because it's already possible to do what you want in another way.
Re: LDC 1.13.0-beta1
On 2018-11-07 16:45, kinke wrote: 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. Cool, thanks. -- /Jacob Carlborg
Re: Profiling DMD's Compilation Time with dmdprof
On Tuesday, 6 November 2018 at 19:01:58 UTC, H. S. Teoh wrote: It looks like it would be really useful one day when I try to tackle the dmd-on-lowmem-system problem again. Based on my profiling it seems that most memory is allocated in void importAll(Scope* sc) found in attrib.d . A person with more knowledge of DMD source could create new allocator for scope data and when its no longer needed just dealloc all. My intuition says that after IR is generated we no longer need scope information. Here is profile data for simple file. https://imgur.com/a/ROa6JNd
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: 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: 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. Everything on Windows is slower. I'm 99% sure the fault lies with NTFS. I worked on a cross platform framework back in the day, nearly all of the code was identical between Linux and Windows. On the same dual-boot machine the build was between one and two orders of magnitude slower on Windows. Again: same code, same machine, no VMs. _Anything_ that used the filesystem was significantly slower, including CMake. It got to the point that the devs that preferred to use Windows only ever used the unity build because incremental ones were too slow to bear. I'd love to know how long it takes to build clang on your machine.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 7 November 2018 at 13:15:03 UTC, Dennis wrote: 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. well you could say the same about pointers. but..what happens when a large number of programmers start using pointers? In the hands of few, it's not such a big issue. In the hands of the many, well.. we all know the result. Decades of bugs! Should we wait till the bugs start appearing? But my argument actually is less about bugs, or the potential for bugs (although that potential obviously exists). My argument is more about the 'untyped' nature of the D module. That is, a type (say a class) is 'naked' in a module, exposed for all (in that module) to see. It can be violated in any number of ways, by other code in the module. I mean that is just fact. It's not something I should need to continually point out. Some say that' fine. A class should be subjected to that humiliation. Other say, if you wan't to prevent that humiliation, then you can do it already - that is, you can clothe a class, in D, by 'walling it off' in it's *own* module. That immediately tells you something about the nature of the module. The module is essentially an untyped universe. It removes the clothes from the class, and allows it to be violated. On that basis, bugs (or the potential for them), becomes an immediate reality - and more so in the hands of the many, as opposed to the hands fo the few. Now, if you're one of those that object to the use of classes (and there are many in the D forums), then you would already be biased towards dismissing my argument, and don't mind at all if the class is subject to humiliation. I would prefer you refrain from the discussion, if such bias is going to be used to shutdown the argument. Because it just brings the tone of the discussion down to a level that nobody wants to participate in - likely it's goal in the first place. Lets be clear. My argument (not my DIP - as there is none) is, that it can only strengthen D, if D allowed the programmer the option (just the option) to ensure that a class wasn't subjected to such humiliation, when there is other code in the module besides that class. The major purpose of a class afterall (understood by most programmers), is to impose contraints on interactions with other objects (or other code), in order to enforce correctness and eliminate inconsistencies. It does this, by clothing itself, so that other types cannot operate directly on its naked representation. Yes, I know, you *can* clothe your class in D, but *only* if you wall it off in it's module. If you want 2 classes in your module, now you need to manage 2 classes across 2 different modules. That is an increase in complexity for the programmer. But you have no choice, because the very instance you put other code in that module, you remove that protective clothing. All I'm asking for, is the ability to have extra code in the module, without the module removing the clothes from my types. Is that really too much too ask? I do not understand the motivations of those that reject such an argument. (hopefully, the moderator will post this..you never know on these forums..peoples post are going missing, or show up in the wrong order, days laterwhat's going on?)
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, Nov 8, 2018 at 12:55 AM Joakim via Digitalmars-d-announce wrote: > > On Thursday, 8 November 2018 at 08:29:28 UTC, Manu wrote: > > On Thu, Nov 8, 2018 at 12:10 AM Joakim via > > Digitalmars-d-announce > > wrote: > >> > >> On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: > > > > I didn't configure the build infrastructure! > > Maybe you can? I have no experience with VS, but surely it has > some equivalent of ninja -j5? msbuild does parallel builds quite effectively. I expect it perceives a dependency between jobs which cause it to serialise. Maybe there's a legit dependency, or maybe the msbuild script has a problem? Either way, it's not acceptable. I would log this is maximum priority bug. (https://issues.dlang.org/show_bug.cgi?id=19377) > >> > 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? > >> > >> Could be part of the problem on Windows, dunno. > > > > Well... ffs... people need to care about this! >_< > > I agree that the official release of DMD for Windows should be > faster, and we should be building it with ldc... if that's the > problem. I think it's a combination of problems, and primary problem being criminal negligence!
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 08:29:28 UTC, Manu wrote: On Thu, Nov 8, 2018 at 12:10 AM Joakim via Digitalmars-d-announce wrote: On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: > 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 Lol, I saw that link and figured it was either some comedy video, like the Python ones Walter sometimes posts, or you were actually showing us how long it takes. Pretty funny to see the latter. It's not so funny when every one-line tweak burns 2 minutes of my life away. I was laughing that you actually proved your point with direct video evidence, obviously it's sad that it takes so long. > DMD only builds with one core, since it builds altogether. Yes, but your build time is unusually long even with one core. Are the D backend and frontend at least built in parallel to each other? That doesn't matter, you can clearly see the backend built in less than 2 seconds. The C/C++ files in the beginning are built very fast, but the D files in the backend appear to take much longer, kicking in at 1:18 of your video and then the next compilation step starts at 1:40. I suspect part of the problem is that your build is being done completely serially, even for separate compilation. I have no experience with VS, so I don't know why that is. It doesn't seem to be even doing that, though they're separate invocations of DMD. I didn't configure the build infrastructure! Maybe you can? I have no experience with VS, but surely it has some equivalent of ninja -j5? > 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? Could be part of the problem on Windows, dunno. Well... ffs... people need to care about this! >_< I agree that the official release of DMD for Windows should be faster, and we should be building it with ldc... if that's the problem.
Re: Backend nearly entirely converted to D
On Wednesday, 7 November 2018 at 21:40:58 UTC, welkam 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 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. I'm not making any general statements about whether C++ or D compiles faster, only pointing out that in a common setup of building dmd with clang and dmd on linux/x64, I didn't see much of a speed gain. However, I did mention that the frontend should be removed to really measure the backend conversion, so that's what I just did. I built the backends for DMD 2.080.1 through master in the same single-core VPS by slightly modifying src/posix.mak, only replacing the line "all: $G/dmd" with "all: $G/backend.a". Here are the results I got and how many D files were built in each backend: 2.080.1 - 1D 8.0s 2.081.2 - 4D 7.2s 2.082.1 - 27D 6.9s 2.083.0 - 45D 5.6s master d398d8c - 50D 4.3s So the frontend might have been obscuring things, as we see a clear win from moving the backend to D, with only about 10 C/C++ files left in the backend now and compilation time cut almost in half. I think we'll see even more of a gain if the D files in the backend are built all at once.
Re: xlsxd: A Excel xlsx writer
dpp and a handful of vim macros did most of the work
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, Nov 8, 2018 at 12:10 AM Walter Bright via Digitalmars-d-announce wrote: > > On 11/7/2018 11:41 PM, Manu wrote: > > I'm on an i7 with 8 threads and plenty of ram... although threads are > > useless, since DMD only uses one ;) > > So does every other compiler. > > To do a multicore build, you'll need to use a makefile that supports -j. Right. So...? Also, MSBuild is what people use on Windows... but same applies.
Re: Profiling DMD's Compilation Time with dmdprof
On Thu, Nov 8, 2018 at 12:10 AM Joakim via Digitalmars-d-announce wrote: > > On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: > > 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 > > Lol, I saw that link and figured it was either some comedy video, > like the Python ones Walter sometimes posts, or you were actually > showing us how long it takes. Pretty funny to see the latter. It's not so funny when every one-line tweak burns 2 minutes of my life away. > > DMD only builds with one core, since it builds altogether. > > Yes, but your build time is unusually long even with one core. > Are the D backend and frontend at least built in parallel to each > other? That doesn't matter, you can clearly see the backend built in less than 2 seconds. > It doesn't seem to be even doing that, though they're > separate invocations of DMD. I didn't configure the build infrastructure! > > 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? > > Could be part of the problem on Windows, dunno. Well... ffs... people need to care about this! >_<
Re: Profiling DMD's Compilation Time with dmdprof
On Thursday, 8 November 2018 at 07:54:56 UTC, Manu wrote: 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 Lol, I saw that link and figured it was either some comedy video, like the Python ones Walter sometimes posts, or you were actually showing us how long it takes. Pretty funny to see the latter. DMD only builds with one core, since it builds altogether. Yes, but your build time is unusually long even with one core. Are the D backend and frontend at least built in parallel to each other? It doesn't seem to be even doing that, though they're separate invocations of DMD. 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? Could be part of the problem on Windows, dunno.
Re: Profiling DMD's Compilation Time with dmdprof
On 11/7/2018 11:41 PM, Manu wrote: I'm on an i7 with 8 threads and plenty of ram... although threads are useless, since DMD only uses one ;) So does every other compiler. To do a multicore build, you'll need to use a makefile that supports -j.
Re: Profiling DMD's Compilation Time with dmdprof
On 11/7/2018 10:08 PM, Vladimir Panteleev wrote: It does seem to take more time now; I wonder why. That's easy. It's because nobody has profiled it for years. Another reason is the backend being in D now, it is being compiled with DMD rather than gcc/clang.
Re: Profiling DMD's Compilation Time with dmdprof
On Wed, Nov 7, 2018 at 11:55 PM Joakim via Digitalmars-d-announce wrote: > > 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. No, you're right, the backend builds in 2-3 seconds.
