On 8/2/2013 6:16 AM, Dmitry Olshansky wrote:
31-Jul-2013 22:20, Walter Bright пишет:
On 7/31/2013 8:26 AM, Dmitry Olshansky wrote:
Ouch... to boot it's always aligned by word size, so
key % sizeof(size_t) == 0
...
rendering lower 2-3 bits useless, that would make straight slice lower
bits
approach rather weak :)
Yeah, I realized that, too. Gotta shift it right 3 or 4 bits.
And that helped a bit... Anyhow after doing a bit more pervasive integer hash
power of 2 tables stand up to their promise.
The pull that reaps the minor speed benefit over the original (~2% speed gain!):
https://github.com/D-Programming-Language/dmd/pull/2436
2% is worth taking.
Not bad given that _aaGetRValue takes only a fraction of time itself.
I failed to see much of any improvement on Win32 though, allocations are
dominating the picture.
And sharing the joy of having a nice sampling profiler, here is what AMD
CodeAnalyst have to say (top X functions by CPU clocks not halted).
Original DMD:
Function CPU clocks DC accesses DC misses
RTLHeap::Alloc 49410 520 3624
Obj::ledata 10300 1308 3166
Obj::fltused 6464 3218 6
cgcs_term 4018 1328 626
TemplateInstance::semantic 3362 2396 26
Obj::byte 3212 506 692
vsprintf 3030 3060 2
ScopeDsymbol::search 2780 1592 244
_pformat 2506 2772 16
_aaGetRvalue 2134 806 304
memmove 1904 1084 28
strlen 1804 486 36
malloc 1282 786 40
Parameter::foreach 1240 778 34
StringTable::search 952 220 42
MD5Final 918 318
Variation of DMD with pow-2 tables:
Function CPU clocks DC accesses DC misses
RTLHeap::Alloc 51638 552 3538
Obj::ledata 9936 1346 3290
Obj::fltused 7392 2948 6
cgcs_term 3892 1292 638
TemplateInstance::semantic 3724 2346 20
Obj::byte 3280 548 676
vsprintf 3056 3006 4
ScopeDsymbol::search 2648 1706 220
_pformat 2560 2718 26
memcpy 2014 1122 46
strlen 1694 494 32
_aaGetRvalue 1588 658 278
Parameter::foreach 1266 658 38
malloc 1198 758 44
StringTable::search 970 214 24
MD5Final 866 274 2
This underlies the point that DMC RTL allocator is the biggest speed detractor.
It is "followed" by ledata (could it be due to linear search inside?) and
surprisingly the tiny Obj::fltused is draining lots of cycles (is it called that
often?).
It's not fltused() that is taking up time, it is the static function following
it. The sampling profiler you're using is unaware of non-global function names.
