Re: phobosx.signal ready
You can get free certificates from StartSSL. Thanks, that's actually cool :-) Unfortunately it does not work for my dyndns domain. (I can't register vhios.dyndns.org, only dyndns.org would be accepted)
Re: Emacs D Mode version 2.0.6 released
Walter, On Tue, 2013-07-23 at 14:59 -0700, Walter Bright wrote: On 7/22/2013 3:39 AM, Russel Winder wrote: The title says it all really. Need linky! Did John Colvin's reply suffice? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Article: Increasing the D Compiler Speed by Over 75%
Vote up! http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ https://news.ycombinator.com/item?id=6103883 Andrei
Re: Article: Increasing the D Compiler Speed by Over 75%
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ Where is the 75% value coming from? Regarding the hashing, maybe a different hashing scheme, like Python dicts hashing could be better. Regarding Don's problems with memory used by dmd, is it a good idea to add a compilation switch like -cgc that switches on a garbage collector for the compiler (disabled on default)? Bye, bearophile
Re: Article: Increasing the D Compiler Speed by Over 75%
On 7/25/2013 11:21 AM, bearophile wrote: Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ Where is the 75% value coming from? Not sure what you mean. Numbers at the end of the article. Regarding the hashing, maybe a different hashing scheme, like Python dicts hashing could be better. It's not the hashing that's slow. It's the lookup that is. Regarding Don's problems with memory used by dmd, is it a good idea to add a compilation switch like -cgc that switches on a garbage collector for the compiler (disabled on default)? It might be.
Re: Article: Increasing the D Compiler Speed by Over 75%
The biggest compile time killer in my experience is actually running out of memory and hitting the swap. My work app used to compile in about 8 seconds (on Linux btw). Then we added more and more stuff and it went up to about 20 seconds. It uses a fair amount of CTFE and template stuff, looping over almost every function in the program to generate code. Annoying... but then we added a little bit more and it skyrocketed to about 90 seconds to compile! That's unbearable. The cause was the build machine had run out of physical memory at the peak of the compile process, and started furiously swapping to disk. I fixed it by convincing them to buy more RAM, and now we're back to ~15 second compiles, but at some point the compiler will have to address this. I know donc has a dmd fork where he's doing a lot of work, completely re-engineering CTFE, so it is coming, but that will probably be the next speed increase, and we could be looking at as much as 5x in cases like mine! BTW apparently a dmd built with Microsoft's compile does the nasty in about 11 seconds rather than 30 for the std.algorithm build - comparable to the linux version with gcc. I really like dmc too, but a 3x speed increase is really significant for something that's relatively easy to do.
Re: Article: Increasing the D Compiler Speed by Over 75%
On 7/25/2013 11:30 AM, Adam D. Ruppe wrote: The biggest compile time killer in my experience is actually running out of memory and hitting the swap. My work app used to compile in about 8 seconds (on Linux btw). Then we added more and more stuff and it went up to about 20 seconds. It uses a fair amount of CTFE and template stuff, looping over almost every function in the program to generate code. Annoying... but then we added a little bit more and it skyrocketed to about 90 seconds to compile! That's unbearable. The cause was the build machine had run out of physical memory at the peak of the compile process, and started furiously swapping to disk. I fixed it by convincing them to buy more RAM, and now we're back to ~15 second compiles, but at some point the compiler will have to address this. I know donc has a dmd fork where he's doing a lot of work, completely re-engineering CTFE, so it is coming, but that will probably be the next speed increase, and we could be looking at as much as 5x in cases like mine! I know the memory consumption is a problem, but it's much harder to fix. BTW apparently a dmd built with Microsoft's compile does the nasty in about 11 seconds rather than 30 for the std.algorithm build - comparable to the linux version with gcc. I really like dmc too, but a 3x speed increase is really significant for something that's relatively easy to do. An interesting project would be to research the specific cause of the difference.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Thursday, 25 July 2013 at 19:07:02 UTC, Walter Bright wrote: On 7/25/2013 11:30 AM, Adam D. Ruppe wrote: The biggest compile time killer in my experience is actually running out of memory and hitting the swap. My work app used to compile in about 8 seconds (on Linux btw). Then we added more and more stuff and it went up to about 20 seconds. It uses a fair amount of CTFE and template stuff, looping over almost every function in the program to generate code. Annoying... but then we added a little bit more and it skyrocketed to about 90 seconds to compile! That's unbearable. The cause was the build machine had run out of physical memory at the peak of the compile process, and started furiously swapping to disk. I fixed it by convincing them to buy more RAM, and now we're back to ~15 second compiles, but at some point the compiler will have to address this. I know donc has a dmd fork where he's doing a lot of work, completely re-engineering CTFE, so it is coming, but that will probably be the next speed increase, and we could be looking at as much as 5x in cases like mine! I know the memory consumption is a problem, but it's much harder to fix. Obstacks are a popular approach in compilers. Allocation is the simple pointer-bump, so it should maintain the new speed. Deallocation can be done blockwise. Works great, if you know the lifetime of the objects.
Re: Article: Increasing the D Compiler Speed by Over 75%
On 7/25/2013 12:26 PM, qznc wrote: if you know the lifetime of the objects. Aye, there's the rub! And woe to you if you get that wrong.
Re: Article: Increasing the D Compiler Speed by Over 75%
Walter Bright: It's not the hashing that's slow. It's the lookup that is. By different hashing scheme I meant different strategies in resolving hash collisions, likes double hashing, internal hashing, cuckoo hashing, and so on and on. Maybe one of such alternative strategies is more fit for the needs of dmd compilation. (I think that currently the Python dicts are using a hashing strategy different from the built-in dictionaries of D. The Python style of hashing was implemented in D some months ago, but I don't remember what happened to that project later). Bye, bearophile
Re: Article: Increasing the D Compiler Speed by Over 75%
On Thu, Jul 25, 2013 at 2:25 PM, Walter Bright newshou...@digitalmars.comwrote: On 7/25/2013 11:21 AM, bearophile wrote: Andrei Alexandrescu: http://www.reddit.com/r/**programming/comments/1j1i30/** increasing_the_d_compiler_**speed_by_over_75/http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ Where is the 75% value coming from? Not sure what you mean. Numbers at the end of the article. 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.) Regarding the hashing, maybe a different hashing scheme, like Python dicts hashing could be better. It's not the hashing that's slow. It's the lookup that is. Regarding Don's problems with memory used by dmd, is it a good idea to add a compilation switch like -cgc that switches on a garbage collector for the compiler (disabled on default)? It might be.
Re: Article: Increasing the D Compiler Speed by Over 75%
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. A reduction in time would be the reciprocal of that.
Re: Article: Increasing the D Compiler Speed by Over 75%
On Thursday, July 25, 2013 14:25:20 Walter Bright wrote: Also, computing the hash is done exactly once, in the lexer. Thereafter, all identifiers are known only by their handles, which are (not coincidentally) the pointer to the identifier, and by its very nature is unique. I've always thought that that was a neat trick. But you seem to have quite a few of those in the compiler that you've come up with or learned about over the years. We're definitely benefiting from your experience. - Jonathan M Davis
Re: Article: Increasing the D Compiler Speed by Over 75%
On 7/25/2013 3:54 PM, Vladimir Panteleev wrote: Like string interning? Exactly.
echo: -n, the next installment
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
Re: Increasing D Compiler Speed by Over 75%
On Thu, 25 Jul 2013 20:04:10 +0200 Brad Anderson e...@gnuk.net wrote: On Thursday, 25 July 2013 at 18:03:22 UTC, Walter Bright wrote: http://www.reddit.com/r/programming/comments/1j1i30/increasing_the_d_compiler_speed_by_over_75/ I propose we always refer to compiling as doing the nasty from this moment forward. Yea, that's just absolutely classic :)
Re: Article: Increasing the D Compiler Speed by Over 75%
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).
Re: Article: Increasing the D Compiler Speed by Over 75%
In IT speed is time. Weight, volume and size are bytes. Kilo- is 1024. And other non-SI weird stuff.
Re: Article: Increasing the D Compiler Speed by Over 75%
In IT speed is time. That's probably because IT folks are loose with units. Though pedantism is ok.
