Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Silently Shifting Semicolon [pdf]

cs.ucla.edu

Post reply on HN
Print view View original

31–37 of 37 posts

Re: The Silently Shifting Semicolon [pdf]

#31

Post by madanMus »

acqq wrote: post #12
avandeursen wrote: post #9

Earlier quoted context omitted.

Yes, it is from the "Summit oN Advances in Programming Languages (SNAPL)", May 3-6, 2015. http://snapl.org/2015/

Then ignoring the existence of the weaker memory model of ARM (versus the stronger x86/x64) is even stranger. And even if x86/x64 models are stronger, they still need some fences and using them all the time would be too slow. So I still don't really understand the arguments of the article.

The article does not ignore architectures like ARM. You do need fences, but not all the time - the compiler can avoid fences in places where there is no danger of violating sequential consistency (e.g. on accesses to provably local objects).

Re: The Silently Shifting Semicolon [pdf]

#32

Post by madanMus »

dietrichepp wrote: post #14
xxxyy wrote: post #11

Earlier quoted context omitted.

To be precise, Alice quits programming because modern languages lack proper concurrency specification, and thus lack actual "Math" in this area. I can sympathize with that.

The concurrency behavior of Java/C++/etc is specified, it's just that the specification doesn't match the model given in the article. It follows a different mathematical model—that doesn't mean that it "lacks actual math".

But the math is currently broken for Java. See http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.112....

Here the authors show that most common compiler optimizations are JMM incompatible.

Re: The Silently Shifting Semicolon [pdf]

#33

Post by madanMus »

conistonwater wrote: post #18

Can somebody weigh in on their claims of performance differences? IIUC that's the strongest argument so far against sequential consistency by default, yet I'm not sure I understand their evidence. I haven't followed their references yet, but after reading their arguments I'm not sure just what the overhead is now, and what they expect it to be in the future (tbh, I would have expected them to be much clearer about th…

[I am one of the authors of the paper.]

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.

Re: The Silently Shifting Semicolon [pdf]

#35

Post by conistonwater »

madanMus wrote: post #33
conistonwater wrote: post #18

Can somebody weigh in on their claims of performance differences? IIUC that's the strongest argument so far against sequential consistency by default, yet I'm not sure I understand their evidence. I haven't followed their references yet, but after reading their arguments I'm not sure just what the overhead is now, and what they expect it to be in the future (tbh, I would have expected them to be much clearer about th…

[I am one of the authors of the paper.] 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…

Hi, thanks for replying.

> 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.

Re: The Silently Shifting Semicolon [pdf]

#36

Post by [deleted] »

madanMus wrote: post #33
conistonwater wrote: post #18

Can somebody weigh in on their claims of performance differences? IIUC that's the strongest argument so far against sequential consistency by default, yet I'm not sure I understand their evidence. I haven't followed their references yet, but after reading their arguments I'm not sure just what the overhead is now, and what they expect it to be in the future (tbh, I would have expected them to be much clearer about th…

[I am one of the authors of the paper.] 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…

[deleted]

Re: The Silently Shifting Semicolon [pdf]

#37

Post by madanMus »

conistonwater wrote: post #35
madanMus wrote: post #33

Earlier quoted context omitted.

[I am one of the authors of the paper.] 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…

Hi, thanks for replying. > 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 resea…

yes, you did read correctly. The 1-3% does assume a non-standard whole-program analysis. Something more practical on existing hardware will look more like the E numbers (for escape analysis): 17.5% on x86 and 6.8% on ARM. An even dumber analysis (H) adds up to 37.5% overhead on x86.

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.

Post reply on HN