3 ms·
This felt like enough of a "devil is in the details" case that I needed to read the original rather than a summary. Clicked through to the paper, to be greeted
by jsnell 9y ago
This felt like enough of a "devil is in the details" case that I needed to read the original rather than a summary. Clicked through to the paper, to be greeted by an ACM paywall. Blech. But wait, what's this... "article made available by the morning paper", with a tooltip "special arrangement betwen ACM and blog.acolyer.com". So that's cool, I guess :)
One odd bit about the design seemed to be that the responses were allocated on a per-socket rather than per-core basis. The paper implies (but doesn't seem to state outright) that this is done to pack as much data as possible to each store buffer. Does that sound right?
- naasking 9y ago> This felt like enough of a "devil is in the details" case that I needed to read the original rather than a summary. Seriously, I was very surprised that delegation+combining i slower than ffwd's delegation alone. I definitely want to see those details.
- jeriksson 9y agoCombining is a type of delegation, where threads alternate taking on the role of the "server" in a conventional client-server delegation scheme.
- naasking 9y agoRight, but my point was that combining appears to be slower than delegation alone. Perhaps it's due to cache effects, since new servers are unlikely to have the right data in cache, where a dedicated thread will almost certainly have the most commonly accessed addresses in cache.
- uluyol 9y agoI don't have a problem accessing the paper if I click on the title here: https://www.sigops.org/sosp/sosp17/program.html https://www.sigops.org/sosp/sosp17/program.html
- jeriksson 9y ago(author here) Yes, there are multiple responses in each cache line, reducing interconnect bandwidth requirements, and conserving precious store buffer resources on the server core.