Request for comments: std.d.lexer

[Dmitry Olshansky]

08-Feb-2013 23:25, Jonathan M Davis пишет:
> On Friday, February 08, 2013 14:29:20 Dmitry Olshansky wrote:
>> If target is random access range just use offset throughout. It's
>> basically becomes base + offset vs base + pointer i.e. non-issue
>
>> If not then pointer argument no longer applies and you can just as well
>> use separate counter on per popFront. It'd not that costly in this case
>> and flexibility tramps other concerns with forward ranges in any case.
>
> I don't know exactly how costly it ends up being (and certainly, poor design
> choices in other areas could dwarf that cost), but it does incur extra
> overhead throughout the lexing process.
 > In most code, it wouldn't be a big
 > deal, but the lexer is trying to be lightning fast, so every extra 
bit like
 > that is going to add up and slow it down.

I suspect it *might* require extra register for base depending on 
smartness of the compiler, extra register in turn could rise the cost.

The key to speed here however is not in using raw pointers, assembly 
and/or SIMD. FWIW if there is only a single base pointer + offsets 
compiler can assume no pointer aliasing and optimize things better.

The discussion becomes purely rhetorical unless some hard data is 
actually presented and not based on DMD's optimizer, please.

> But you really don't have any choice
> if you don't even have random access.

Agreed.

 > Regardless, my point is that accepting
 > generic ranges rather than pointers complicates things somewhat and 
does incur
 > at least a slight performance penalty.
 >

Complication - yes, slight performance cost is what I doubt it in RA 
case. Seems like a compiler/optimizer issue.

For one I used to write cycles with naked pointers in C to get better 
performance out of crappy compilers. I won't ever do it today as it 
would get worse performance in addition to being less readable (I've 
checked at least on VC++ about a year ago, compiler rewrites these 
index-based loops better, YMMV).


-- 
Dmitry Olshansky