Larrabee delayed to 2011 ?
- Thread starter rpg.314
- Start date
Snooping will always fuck things up ... software managed directories is the way to go, not hardware managed ones.
Roll it into the page handling perhaps?
Last edited by a moderator:
This is the scenario where caches shine. Frequent reads and infrequent writes.
The problem is when cache coherency is used for IPC. Producers writing to queues causing invalidate traffic, subsequent consumer requests then cause queries for the line. That's a lot of wasted traffic to just get a few bytes from core 0 to core 1.
The solution is either explicit message queues or virtual channels in the memory system. Both require more hardware support.
Cheers
My understanding is that a cacheline in a cpu (since they are r/w there) can only be owned by one core. If many cores read the same data, then there will be a lot of traffic just to push stuff around.
As for amount of hw support, it seems from that ppt that sw managed cache coherency costs less hw than present day caches.
In this scenario caches shine, hw cache-coherency doesn't.
In the sw managed world, that page could be marked as readonly and then could be shared safely across many cores without the coherency traffic.
IIRC it's something like 8GFLOPS.
Actually it's even worse. ASCI Red achieved more than 1TFLOPs in LINPACK (solving dense matrix in DP). It's would be even faster doing DGEMM
Of course there won't be any copying around. Each core would have a copy of the cacheline. The cacheline would have the state "Shared" (Read up on cache coherence protocol).
If there is a write to the cacheline, an cacheline invalidate is broadcast.
Cheers
Last edited by a moderator:
Jawed
Legend
Really
that sounds way too low to even be worth demonstrating 
Looking at the video again I have a feeling the scale goes up to 100GFLOPs, so 80 sounds reasonable. There's two things being shown QCD and FEM_CANT. If they're running concurrently, each using half of Larrabee, then ~160 GFLOPS might be it.
Jawed
Not exactly what I meant. I meant that you could maintain a per page subscriber list, it might trap if the list isn't cached in the hardware TLB at the moment but it need not trap on every write.
I was thinking along the same line, but only automatic.
To support single producer/multiple consumer semantics in the cache apparatus, I'd add a new cache line state, where a write doesn't immidately cause an invalidate broadcast. Instead communication is deferred until the programmer chooses to "push" the line (or regular LRU replacement ejects the line).
Instead of an invalidate broadcast, the cacheline itself is broadcast. Use automatic directories to only push the line to the actual consumers. All the consumers would hold the cache line in the Shared state.
The automatic directory/snoop filter is used to implicitly implement the subscriber list.
Cheers
So I guess nVidia was right to call it a bunch of powerpoint slides
Fry: "Words. Nothing but sweet, sweet words that turn into bitter orange wax in my ears."
Sorry couldn't help myself.