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
