Re: Article: Increasing the D Compiler Speed by Over 75%
Certainly you're technically correct about the 75% improvement in speed, but the units of speed for program execution is a little weird and unintuitive (Hz). I've not run across anyone who says "my program got faster! It went from 0.05 Hz to 0.08 Hz!". I think that's why people find it a little odd to talk about speed increase rather than time decrease. On Sat, Jul 27, 2013 at 8:12 PM, torhu wrote: > On 26.07.2013 01:15, Leandro Lucarella wrote: > >> Walter Bright, el 25 de July a las 14:27 me escribiste: >> >>> On 7/25/2013 11:49 AM, Dmitry S wrote: >>> >I am also confused by the numbers. What I see at the end of the article >>> is >>> >"21.56 seconds, and the latest development version does it in 12.19", >>> which is >>> >really a 43% improvement. (Which is really great too.) >>> >>> 21.56/12.19 is 1.77, i.e. a >75% improvement in speed. >>> >> >> This is certainly misleading, is very easy to be confused with a time >> reduction of 75%, which one would expect to be 1/4 of the original time. >> :) >> >> > A doubling of the speed would be 100%, just saying. >
Re: Article: Increasing the D Compiler Speed by Over 75%
On 26.07.2013 01:15, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: >I am also confused by the numbers. What I see at the end of the article is >"21.56 seconds, and the latest development version does it in 12.19", which is >really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a >75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) A doubling of the speed would be 100%, just saying.
Re: DScanner is ready for use
On Sun, 28 Jul 2013 00:27:34 +0200 "Brian Schott" wrote: > DScanner is a tool for analyzing D source code. It has the > following features: > > * Prints out a complete AST of a source file in XML format. > * Syntax checks code and prints warning/error messages > * Prints a listing of modules imported by a source file > * Syntax highlights code in HTML format > * Provides more meaningful "line of code" count than wc > * Counts tokens in a source file > > The lexer/parser/AST are located in the "std/d" directory in the > repository. These files should prove useful to anyone else > working on D tooling. > > https://github.com/Hackerpilot/Dscanner > > Aside: the D grammar that I reverse-engineered can be located > here: > https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html Sweet, I was *just* thinking about writing a D -> HTML syntax highlighter no more than about five minutes ago. Glad to see I won't have to :) I'll definitely be checking this out.
D script to list all non-versioned files in a git working copy
Summary: Git's "git status --ignored" is half-broken and therefore unreliable, and so are the "solutions" floating around the net. I've posted a short explanation/rant along with a script written in D which accomplishes the task correctly: http://semitwist.com/articles/article/view/do-not-use-git-status-ignored
Re: monarch dodra granted write access to phobos, druntime, and tools
On Saturday, July 27, 2013 12:35:40 monarch_dodra wrote: > On Monday, 22 July 2013 at 18:08:36 UTC, Andrei Alexandrescu > > wrote: > > Please join me in congratulating monarch dodra for his > > admission among our github committers. We're starting with > > phobos, druntime, and tools access, and if all goes well, we'll > > extend write rights to dmd also. > > > > > > Thanks, > > > > Andrei > > Hey! Sorry it took me 4 days to discover the D announce thread. I > must admit it wasn't one of the threads I looked over (although > this will change starting today, lots of interesting articles > here). > > In any case, thank you everyone for your support and kind words :) > > I don't think granting me dmd rights would be necessary, as I > don't really know how the compiler works, and I mostly only > contribute to phobos anyways (sometimes druntime). > > I may in the future try to contribute to dmd itself, but I > wouldn't ever pull anything in there myself anyways, so giving me > pull rights (at this point) would be mostly pointless. > > Well, here's to making D as best as it can be ^^ I wouldn't want dmd commit rights for the same reason. I tend to think that commit rights to dmd and those to the standard library should be separate things, as there's quite a difference between what kind of understanding is required to work on Phobos from what is required to work on dmd (though in most cases, someone with commit rights to dmd should probably have commit rights to the libraries). In any case, welcome aboard! - Jonathan M Davis
DScanner is ready for use
DScanner is a tool for analyzing D source code. It has the following features: * Prints out a complete AST of a source file in XML format. * Syntax checks code and prints warning/error messages * Prints a listing of modules imported by a source file * Syntax highlights code in HTML format * Provides more meaningful "line of code" count than wc * Counts tokens in a source file The lexer/parser/AST are located in the "std/d" directory in the repository. These files should prove useful to anyone else working on D tooling. https://github.com/Hackerpilot/Dscanner Aside: the D grammar that I reverse-engineered can be located here: https://rawgithub.com/Hackerpilot/DGrammar/master/grammar.html
Re: Article: Increasing the D Compiler Speed by Over 75%
Walter Bright, el 25 de July a las 18:33 me escribiste: > On 7/25/2013 4:15 PM, Leandro Lucarella wrote: > >Walter Bright, el 25 de July a las 14:27 me escribiste: > >>On 7/25/2013 11:49 AM, Dmitry S wrote: > >>>I am also confused by the numbers. What I see at the end of the article is > >>>"21.56 seconds, and the latest development version does it in 12.19", > >>>which is > >>>really a 43% improvement. (Which is really great too.) > >> > >>21.56/12.19 is 1.77, i.e. a >75% improvement in speed. > > > >This is certainly misleading, is very easy to be confused with a time > >reduction of 75%, which one would expect to be 1/4 of the original time. > >:) > > I don't think it's misleading at all. Speed is distance/time. A > change in speed (which is the title) is the reciprocal of a change > in time. > > For example, a doubling of speed (100% increase) is a halving of > time (50% reduction). I know is technically right, I'm just saying it can be easily confused for something else that looks much better than the actual (very good) reality, and in this case is misleading. If you say something that's technically correct but hard to understand, you are not communicating your message effectively. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- No existiría el sonido del mar si faltara en la vida oreja y caracol. -- Ricardo Vaporeso. Cosquín, 1908.
Re: Article: Increasing the D Compiler Speed by Over 75%
SomeDude, el 27 de July a las 20:27 me escribiste: > On Friday, 26 July 2013 at 00:08:21 UTC, Leandro Lucarella wrote: > >Walter Bright, el 25 de July a las 14:27 me escribiste: > >>On 7/25/2013 11:49 AM, Dmitry S wrote: > >>>I am also confused by the numbers. What I see at the end of > >>>the article is > >>>"21.56 seconds, and the latest development version does it in > >>>12.19", which is > >>>really a 43% improvement. (Which is really great too.) > >> > >>21.56/12.19 is 1.77, i.e. a >75% improvement in speed. > > > >This is certainly misleading, is very easy to be confused with a > >time > >reduction of 75%, which one would expect to be 1/4 of the original > >time. > >:) > > No, a division by 4 of the total time would be a 300% improvement in > speed. The article's title looks correct to me. Again, I never said is incorrect, I said is easily to read it incorrectly, which ends up sending a wrong message. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Wake from your sleep, the drying of your tears, Today we escape, we escape.
Re: I've started blog a little more about D.
On Sun, 21 Jul 2013 15:39:47 -0700 Walter Bright wrote: > On 7/21/2013 3:24 PM, Adam D. Ruppe wrote: > > This is why I prefer to use 'thou' when writing documentation. :-P > > I use "thou" when I'm issuing commandments to my subjects. Thou shalt not obey this commandment.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Friday, 26 July 2013 at 00:08:21 UTC, Leandro Lucarella wrote: Walter Bright, el 25 de July a las 14:27 me escribiste: On 7/25/2013 11:49 AM, Dmitry S wrote: >I am also confused by the numbers. What I see at the end of >the article is >"21.56 seconds, and the latest development version does it in >12.19", which is >really a 43% improvement. (Which is really great too.) 21.56/12.19 is 1.77, i.e. a >75% improvement in speed. This is certainly misleading, is very easy to be confused with a time reduction of 75%, which one would expect to be 1/4 of the original time. :) No, a division by 4 of the total time would be a 300% improvement in speed. The article's title looks correct to me.
Getting Started with the D Programming Language
http://www.gamedev.net/page/resources/_/technical/general-programming/getting-started-with-the-d-programming-language-r3306 By Mike "Aldacron" Parker
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 12:59:06 UTC, monarch_dodra wrote: On Saturday, 27 July 2013 at 12:19:44 UTC, John Colvin wrote: On Saturday, 27 July 2013 at 01:09:03 UTC, Jesse Phillips wrote: On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote: After a few weeks of not getting around to it, here's my second post: http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html BTW, std.getopt is a good way to parse arguments. Not sure if it is relevant to what you want to teach, but should generally be preferred over handwritten. I'm pretty sure it wouldn't work ideally for echo as the behaviour depends on the order of the arguments. getopt knows how to handle ordering, it's really just a matter of echo's argument parsing rules being different from classic getopt. For example, echo does not handle "--" argument (end of options mark), which means it is literally impossible for echo's first "string argument" to be "-n". So for example, while "echo -- -n" would print "-- -n", a getopt echo would print "-n". Arguably, this is better behavior, but if the goal is exact replication, then it's wrong :/ Also, this wouldn't work $ echo -E fdsa -n fdsa -n $ as getopt would parse the -n as an option. Exact replication is the name of the game here, as often in the real world one has to write to a spec that is subtly different to what library writers had in mind.
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 12:52:11 UTC, monarch_dodra wrote:
And here is the second comment I wanted to put:
When parsing the options, you use an if-else. I don't know if
its just me, but I find that using a switch is clearer (it's
what you do in your second example). It also introduces string
cases (illegal in C++), and labeled control statements.
The code becomes:
import std.stdio : writef, writeln;
void main(string[] args)
{
assert(args.length);
args = args[1 .. $];
bool writeNewline = true;
size_t i = 0;
myForeach: foreach(arg; args)
{
switch(arg)
{
case "-n":
writeNewline = false;
++i;
break;
default:
break myForeach;
}
}
args = args[i .. $];
writef("%-(%s %)", args);
if(writeNewline)
writeln();
}
PS: If I figure out how to comment on your blog, I'll paste the
comments there :)
thanks for the info on writef, I didn't realise it could do that.
About the switch statement: I didn't even know you could do that
with labels, I'd only ever used them for gotos. I'll consider
putting that in the next version.
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 12:19:44 UTC, John Colvin wrote: On Saturday, 27 July 2013 at 01:09:03 UTC, Jesse Phillips wrote: On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote: After a few weeks of not getting around to it, here's my second post: http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html BTW, std.getopt is a good way to parse arguments. Not sure if it is relevant to what you want to teach, but should generally be preferred over handwritten. I'm pretty sure it wouldn't work ideally for echo as the behaviour depends on the order of the arguments. getopt knows how to handle ordering, it's really just a matter of echo's argument parsing rules being different from classic getopt. For example, echo does not handle "--" argument (end of options mark), which means it is literally impossible for echo's first "string argument" to be "-n". So for example, while "echo -- -n" would print "-- -n", a getopt echo would print "-n". Arguably, this is better behavior, but if the goal is exact replication, then it's wrong :/
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 12:39:24 UTC, monarch_dodra wrote:
On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote:
After a few weeks of not getting around to it, here's my
second post:
http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html
I tried to post a comment on your blog, but I failed. Anyways,
I wanted to post:
And here is the second comment I wanted to put:
When parsing the options, you use an if-else. I don't know if its
just me, but I find that using a switch is clearer (it's what you
do in your second example). It also introduces string cases
(illegal in C++), and labeled control statements.
The code becomes:
import std.stdio : writef, writeln;
void main(string[] args)
{
assert(args.length);
args = args[1 .. $];
bool writeNewline = true;
size_t i = 0;
myForeach: foreach(arg; args)
{
switch(arg)
{
case "-n":
writeNewline = false;
++i;
break;
default:
break myForeach;
}
}
args = args[i .. $];
writef("%-(%s %)", args);
if(writeNewline)
writeln();
}
PS: If I figure out how to comment on your blog, I'll paste the
comments there :)
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 12:19:44 UTC, John Colvin wrote: I'm pretty sure it wouldn't work ideally for echo as the behaviour depends on the order of the arguments. It also has some odd little niggles -- e.g. it's not nice that with a short option you can have --t 5 and --t=5 but not -t 5 or -t=5 (according to docs you can only use -t5 ).
Re: echo: "-n", the next installment
On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote:
After a few weeks of not getting around to it, here's my second
post:
http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html
I tried to post a comment on your blog, but I failed. Anyways, I
wanted to post:
In regards to the whole "spaces only *between*" elements issue,
it is always good to know that writef knows how to print a range,
and knows how to add a "separator" tokens. This make it trivailly
easy to print a range of elements, adding tokens *only* between
each elements.
I know it's not necessarily what you want to teach, but it *is*
incredibly useful. Your first example becomes the trivial:
import std.stdio : writefln;
void main(string[] args)
{
assert(args.length);
args = args[1 .. $];
debug writefln("[%(%s, %)]", args);
else writefln("%-(%s %)", args);
}
when invoked with "a b c", it prints:
a b c
If compiled with "-debug" to boot, you can add extra "visual"
tokens to check there are no trailing symbols:
["a", "b", "c"]
See? Who needs a foreach, or a loop, or functional programming ;)
Re: echo: "-n", the next installment
On Saturday, 27 July 2013 at 01:09:03 UTC, Jesse Phillips wrote: On Friday, 26 July 2013 at 00:38:46 UTC, John Colvin wrote: After a few weeks of not getting around to it, here's my second post: http://foreach-hour-life.blogspot.co.uk/2013/07/the-first-corner-n-for-echo.html BTW, std.getopt is a good way to parse arguments. Not sure if it is relevant to what you want to teach, but should generally be preferred over handwritten. I'm pretty sure it wouldn't work ideally for echo as the behaviour depends on the order of the arguments.
Re: monarch dodra granted write access to phobos, druntime, and tools
On Tuesday, 23 July 2013 at 19:24:10 UTC, Andrei Alexandrescu wrote: I'm very surprised by your outlook. My perception is that the long queue of pending pull requests not being reviewed is the single most important bottleneck at this point in history in the path of D. By my estimates I think we'd improve the speed of D's development by at least one third if we solve this one issue. There's no other issue offering so much impact. I agree it's the major bottleneck but disagree slightly about the details. My recent experience has been that my Phobos pull requests get _reviewed_ quite quickly but then it may take quite some time to actually get merged. Confusion can be added because the reviewers don't always indicate explicit approval of the code, so the submitter can be sitting in limbo not knowing if the lack of merge is down to the code still being inadequate or just the reviewer not getting round to merging it yet. The latter kind of delay tends to result from the situation where the reviewer is waiting for the test suite to pass. Because there's no option to auto-merge on pass, and no alert to reviewers that a pull request has passed testing, it's easy to miss windows of opportunity to merge. This only has to happen a few times for the pull request to get stuck at the bottom of the test queue and for the delay in merging just to stretch. So, I'd propose that if possible the review process include a way for reviewers to explicitly indicate, "This pull request is provisionally approved subject to testing." Approved pull requests would go on a separate priority test queue with "first in, first out" policy. If the test suite passes, they're auto-merged, if it fails they are removed from the queue and must be re-approved. Ideally it should be possible to distinguish actual test failures from something going wrong with the test procedure itself (e.g. a test process not spawning correctly) and in the latter case keeping the pull request in the approved queue. Does this sound workable/useful?
Re: monarch dodra granted write access to phobos, druntime, and tools
On Monday, 22 July 2013 at 18:08:36 UTC, Andrei Alexandrescu wrote: Please join me in congratulating monarch dodra for his admission among our github committers. We're starting with phobos, druntime, and tools access, and if all goes well, we'll extend write rights to dmd also. Thanks, Andrei Hey! Sorry it took me 4 days to discover the D announce thread. I must admit it wasn't one of the threads I looked over (although this will change starting today, lots of interesting articles here). In any case, thank you everyone for your support and kind words :) I don't think granting me dmd rights would be necessary, as I don't really know how the compiler works, and I mostly only contribute to phobos anyways (sometimes druntime). I may in the future try to contribute to dmd itself, but I wouldn't ever pull anything in there myself anyways, so giving me pull rights (at this point) would be mostly pointless. Well, here's to making D as best as it can be ^^
