597099 - TM: analyze speedup from auto-balancing the GETELEM PIC table

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Chris Leary [:cdleary] (not checking bugmail)]

Per be's points in bug 596026 comment 16.

"""
But update just fills the PIC, there's no self-organization on a scan hit, and
once full you're stuck with possibly irrelevant cache "lines".

Better to wrap around and use MRU. You'd fill at the cursor and start scanning
just after it, wrapping around and skipping (initially) free entries.

Don't tune for SS too much and declare victory. We have a chance with this kind
of approach to do better than non-self-organizing branch exits (trace trees),
we should exploit it.
"""

dmandelin did the legwork for JM and found that balancing the PICs had no observable speedup, but since the PIC tables from bug 596026 live in the D$ we may be able to avoid some of the I$ invalidation overheads associated with patching up inline code.

Comment 1

[Brendan Eich [:brendan]]

And again, dmandelin's legwork was IIRC focused on PICs as used for more predictable ops, and focused on SS (and V8 benchmarks? No matter).

The for (i in o) { ... o[i] ... } case is not a tradictional PIC case, as each iteration accesses a different (but predictable) property. It's nice that SS happens to use small objects repeatedly, but we are moving beyond tuning for SS.

In this light, benchmarks based on more real-world for-in workloads would be good.

/be

Comment 2

[David Mandelin [:dmandelin]]

IMO the getelem PIC is basically a quick-fix for SunSpider, with unknown utility elsewhere. I'm not sure we need to worry about it until we find a program in the wild where it does something unusual.

I agree that 

    for (i in o) { ... o[i] ... }

is the likely case, and so carefully engineering this to go fast seems like a good idea for the web, although it doesn't seem pressing to me.

Comment 3

[Brendan Eich [:brendan]]

Sure, this is not a pressing bug.

The PIC hammer is good for many nails, but not all. We should be precise about when not, and work on better methods. Room for innovation here (Andreas saw large for-in loops in an SVG map thingie).

/be

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Still a valid non-TM bug?

Comment 5

[Chris Leary [:cdleary] (not checking bugmail)]

No, since dmandelin's work in JM is the one that still holds. If we decide to investigate balancing ICs in IonMonkey it will get a new bug.