On 11/04/2012 07:55, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
>> The standard says they need not ignore them.
>>
>> I was thinking more about iterating over the contents. What in the
>> current code is an indirect function call inside of a loop becomes
>> mostly be inline functions in a C++ iterator style. The loop is now
>> fully graspable by the optimizer.
>
> That comes with its cost though, as we have hundreds of hashtables for
> various kinds of types, you'd get hundreds of different instantiations of
> the hash table code. hashtab.c is significantly more I-cache friendly
> than that.
Hmm, is that necessarily the case? GCC is big and I-caches are small; it
could well be the case that hashtab.c gets evicted very regularly from the
cache, and is only usually constant in it during the course of one individual
loop. It wouldn't be any more expensive to map in any one hashtab C++
specialisation vs. another, and they'd all individually be of the same scale
as the C hashtab.o code, so unless we have many nested loops that use one kind
of hashtab in the outer loop and a different one in the inner loop, we could
still end up pretty much where we started from in terms of I-cache usage.
I expect profiling would immediately show up whether the two approaches made
any significant difference or not, probably very visibly, but I wouldn't
dismiss doing the experiment out-of-hand. If the inlining improvements exceed
the extra cost of paging, switching to C++ would be justified.
cheers,
DaveK
