Re: Want to help DMD bugfixing? Write a simple utility.
Regan Heath re...@netmail.co.nz wrote in message
news:op.vswbv8qj54x...@puck.auriga.bhead.co.uk...
On Wed, 23 Mar 2011 21:16:02 -, Jonathan M Davis jmdavisp...@gmx.com
wrote:
There are tasks for which you need to be able to lex and parse D code.
To 100% correctly remove unit tests would be one such task.
Is that last bit true? You definitely need to be able to lex it, but
instead of actually parsing it you just count { and } and remove
'unittest' plus { plus } plus everything in between right?
No, to do it 100% reliably, you do need lexing/parsing, and also the
semantics stage. Example:
string makeATest(string str)
{
return unit~test { ~str~ };
}
mixin(makeATest(q{
// Do tests
}));
Re: Want to help DMD bugfixing? Write a simple utility.
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.2700.1300915109.4748.digitalmars-d-le...@puremagic.com... On 3/23/11, Jonathan M Davis jmdavisp...@gmx.com wrote: That would require a full-blown D lexer and parser. - Jonathan M Davis Isn't DDMD written in D? I'm not sure about how finished it is though. Yes, but the lexer and parser in ddmd are not only GPL (which would be a problem for some stuff but not others - for something like Don's utility, it wouldn't be a problem), and more importantly, it is tied to the compiler code. It's not designed to be used by an arbitrary program. For that, you would need a lexer and parser which were designed with an API such that an arbitrary D program could use them. For instance, the lexer could produce a range of tokens to be processed, and a program which wants to use the lexer can then process that range. I don't know about the license issues, but I don't think the API is a big deal. I'm in the early stages of a DDMD-based project to compile D code down to Haxe, and all I really had to do was comment out the backend-related section at the end of main(), inject my AST-walking/processing functions into the AST classes (though, admittedly, there is 1.5 metric fuckton of these AST classes), and then add a little bit of code at the end of main() to launch my AST-traversal. The main() function could easily be converted to a non-main one. The only real difficultly is the fact that the AST isn't really documented, except for what little exists on one particular Wiki4D page (sorry, don't have the link ATM). Hmm, although, depending what you're doing with it, you may also want to hook DDMD's stdout/stderr output, or at least the error/warning functions.
Re: inline functions
On 2011-03-25 19:04, Caligo wrote:
T[3] data;
T dot(const ref Vector o){
return data[0] * o.data[0] + data[1] * o.data[1] + data[2] * o.data[2];
}
T LengthSquared_Fast(){ return data[0] * data[0] + data[1] * data[1] +
data[2] * data[2]; }
T LengthSquared_Slow(){ return dot(this); }
The faster LengthSquared() is twice as fast, and I've test with GDC
and DMD. Is it because the compilers don't inline-expand the dot()
function call? I need the performance, but the faster version is too
verbose.
It sure sounds like it didn't inline it. Did you compile with -inline? If you
didn't then it definitely won't inline it.
- Jonathan M Davis
Re: inline functions
On Fri, Mar 25, 2011 at 10:49 PM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On 2011-03-25 19:04, Caligo wrote:
T[3] data;
T dot(const ref Vector o){
return data[0] * o.data[0] + data[1] * o.data[1] + data[2] * o.data[2];
}
T LengthSquared_Fast(){ return data[0] * data[0] + data[1] * data[1] +
data[2] * data[2]; }
T LengthSquared_Slow(){ return dot(this); }
The faster LengthSquared() is twice as fast, and I've test with GDC
and DMD. Is it because the compilers don't inline-expand the dot()
function call? I need the performance, but the faster version is too
verbose.
It sure sounds like it didn't inline it. Did you compile with -inline? If you
didn't then it definitely won't inline it.
- Jonathan M Davis
I didn't know I had to supply GDC with -inline, so I did, and it did
not help. In fact, with the -inline option the performance gets worse
(for DMD and GDC), even for code that doesn't contain any function
calls. In any case, code compiled with DMD is always behind GDC when
it comes to performance.
Re: inline functions
On 2011-03-25 21:21, Caligo wrote:
On Fri, Mar 25, 2011 at 10:49 PM, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On 2011-03-25 19:04, Caligo wrote:
T[3] data;
T dot(const ref Vector o){
return data[0] * o.data[0] + data[1] * o.data[1] + data[2] *
o.data[2]; }
T LengthSquared_Fast(){ return data[0] * data[0] + data[1] * data[1] +
data[2] * data[2]; }
T LengthSquared_Slow(){ return dot(this); }
The faster LengthSquared() is twice as fast, and I've test with GDC
and DMD. Is it because the compilers don't inline-expand the dot()
function call? I need the performance, but the faster version is too
verbose.
It sure sounds like it didn't inline it. Did you compile with -inline? If
you didn't then it definitely won't inline it.
- Jonathan M Davis
I didn't know I had to supply GDC with -inline, so I did, and it did
not help. In fact, with the -inline option the performance gets worse
(for DMD and GDC), even for code that doesn't contain any function
calls. In any case, code compiled with DMD is always behind GDC when
it comes to performance.
I don't know what gdc does, but you have to use -inline with dmd if you want
it to inline anything. It also really doesn't make any sense at all that
inlining would harm performance. If that's the case, something weird is going
on. I don't see how inlining could _ever_ harm performance unless it just
makes the program's binary so big that _that_ harms performance. That isn't
very likely though. So, if using -inline is harming performance, then
something weird is definitely going on.
- Jonathan M Davis
