Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 22:21:40 UTC, welkam wrote: 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? Please keep chatter on the announce forum to a minimum. Vim is not the only editor capable of limiting searches to whole words. Sublime Text and Visual Studio Code can do this too, as can probably many others.
Re: Backend nearly entirely converted to D
On Thursday, 8 November 2018 at 08:40:37 UTC, Joakim wrote: [...] 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 [...] I think we'll see even more of a gain if the D files in the backend are built all at once. Interesting!
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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
Re: Backend nearly entirely converted to D
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.
Re: Backend nearly entirely converted to D
On Tue, Nov 06, 2018 at 02:12:02PM -0800, Walter Bright via Digitalmars-d-announce 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! > > 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! Awesome news! > 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. What sort of refactoring are we looking at? Any low-hanging fruit here that we non-compiler-experts can chip away at? > 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. Finally! T -- Do not reason with the unreasonable; you lose by definition.
