The Silently Shifting Semicolon [pdf]
cs.ucla.edu
cs.ucla.edu
The alternative, if it is genuinely more expensive to implement SC guarantees in hardware, is that we simply stop teaching people that "A;B" means A is executed and then B. Maybe there really should be an exception saying "but nobody is allowed to look at any intermediate states, unless explicitly allowed". We could also just teach the full meaning of it from the start, it can't be that difficult. Their argument seems to be that non-SC is much less convenient, which I agree with.
On a scale from plenty-real to not-real-at-all, how real are the hardware performance limitations exactly?
The paper reports overhead numbers from existing research. For instance, see Figure 18 in http://arxiv.org/abs/1312.1411, which shows the cost of SC for memcached - 1% on x86 and 3% on ARM.
This overhead is primarily due to the cost of fences on existing hardware. What we (not so cheekily) say is this is likely to get better as hardware platforms provide better implementations for fences.
> The paper reports overhead numbers from existing research. For instance, see Figure 18 in http://arxiv.org/abs/1312.1411, which shows the cost of SC for memcached - 1% on x86 and 3% on ARM.
But that's the bit I don't find nearly convincing enough. You say (p.5) that you're going to "rebut these arguments" that "SC is too expensive", but the main figure of 1%/3% is from a non-standard research-level static analysis tool that, if I read that paper correctly, works on codes up to 10k LOC and takes a few minutes to run, producing the 1%/3% figure. Can that really be generalised? I'm not quite sure. The other tools in comparison did much worse, which I think may be closer to what one would get in practice. So I think that's not a good rebuttal: if you consider the tools actually available SC may well be too expensive.
I'm not saying you're wrong, just that I don't think you've proven your case very clearly. I was kind of expecting a much clearer rebuttal than I found, sorry about the snark.
It is important to realize that the overhead numbers are not huge, like 5x or 20x, to simply write SC off.
As we say in the paper, these overheads, however small they might be, will be unacceptable for low-level libraries written in C/C++ programs. The main argument of the paper was that these overheads are acceptable for "safe" languages like Java/C# which anyway add other (useful) overheads such as garbage collection, bounds checking etc. to help out the programmer.
Even for C/C++, it will still make sense to have SC by default - the programmer is responsible for explicitly turning off SC semantics in parts of the code where the inserted fences hurts performance. This is a much better tradeoff - safe by default and performance by choice.
> there are no data races
No, we take locks or use other memory fence primitives. You introduced Alice to multithreaded programming without teaching her about locks?
Can someone link to a good introduction to the problem? I just wasn't able to completely understand it from the examples in the linked article.
And vola! I mean voila
This article is from 2015, not from 1998.
The incorrect 1998 was derived automatically by HN from the ACM classification in the pdf it seems.
Here the authors show that most common compiler optimizations are JMM incompatible.