anon (anon.delete@this.anon.com) on January 14, 2014 8:32 pm wrote:
> Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 14, 2014 6:56 pm wrote:
> > Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 11, 2014 3:47 am wrote:
> > > Nicolas Capens (nicolas.capens.delete@this.gmail.com) on January 11, 2014 12:24 am wrote:
> > > > And knowing how much an L1 access cost in power, that doesn't make sense unless they have
> > > > 'something' to make it cheap for very locally reused data. I call that something an L0 cache.
> > >
> > > This is an argument that really works against your thesis: memory accesses cost power, you suggest
> > > adding another dual-ported structure that needs to be wired to the L1, to the instruction fetch
> > > logic, reorder buffer, LSU and to the store-queue. That 'something' sits squarely in the middle
> > > of one of some of the most timing-critical paths in a processor and will be continuously burning
> > > power whether you use it or not. How do you possibly thing that's going to save power?
> >
> > Because every L0 hit saves you from accessing the L1 cache,
> > and it's tiny and power efficient in comparison.
> > It shares many similarity with a line buffer,
>
> It shares almost nothing with an L1 line buffer except they are caches of data.

That, and being small and power efficient, is all I need it to be. I wasn't talking about implementation details, just the overall properties. If a line buffer, which sits between the L1 and LSU, is well worth it, why would moving it lower and serving hits on symbolic addresses not be worth it?

> > and they are 20x more power efficient than an L1
>
> So how much more power efficient is an L0 cache than an L1 + line buffer,
> I wonder? How much more complex and less power efficient than a register file
> with a much more versatile and simpler register cache in front of it?

The advantage of the symbolically indexed L0 cache over a line buffer would be that you don't have to compute a virtual and physical address. How much power that saves exactly I don't know, but I can't imagine the ~20 bit compares on reads and ~9 bit compares on writes to consume more power than GPR accesses for the base and index register, computing the virtual address, performing a TLB lookup for the physical address, doing tag lookups, and comparing tags to the physical address.

> access:
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.128.7665&rep=rep1&type=pdf
> >
> > Also note that you could access the L0 cache and L1 cache in parallel, and abort the L1 access on an
> > L0 hit. This way the timings on the L1 access are not altered at all, if that's what concerned you.
>
> At the cost of more power, of course. The power and complexity of managing the L0, and consideration for better
> alternatives seem to always be waved away; while the conjectured advantages seem to be taken as best case.

I'm not waving anything away. It's just that as far as I can tell the power cost of managing the L0 cache would be extremely small; basically just a few narrow comparators. I find it hard to believe an even better alternative would exist. But feel free to present them.

> There is really no good evidence for this L0 cache. Any handwaved advantage
> of it can easily be balanced with a handwaved disadvantage. I can't see why
> there is any point in continuing to talk about it without more data.

Of course there's no evidence of an L0 cache. We're speculating about a brand new architecture. Nobody knows exactly what innovations it will feature. CPU and GPU manufacturers surprise us all the time, and they're not going to present the details on their future architectures early on.