6 ms·

First of all, linking to pthreads and hoping for the best is a really dumb idea in Hare. However, the standard library could be forked (or a new one written) wh

First of all, linking to pthreads and hoping for the best is a really dumb idea in Hare. However, the standard library could be forked (or a new one written) which provides good threads support, and Vulcan is one such standard library implementation, as discussed in the article. With respect to this paper, it's interesting but mainly considers a C audience and makes many assumptions which do not apply to Hare. For instance, the kind of optimizations discussed in section 4.1 are prohibited by the Hare specification. So too for section 4.2, and much of the remainder of the paper deals with optimizations of this nature. Hare's approach is specifically to eschew many of these kinds of optimizations, such that the program you write is very similar to the program that runs, even at the cost of performance. The programmer is expected to optimize their program in many cases, rather than expecting the compiler to do it -- at a great potential cost to correctness and debuggability. Anyway, this was an interesting read, thanks for sharing!

pwdisswordfish9 4y ago
Do I have it right that a Hare compiler is supposed to emit barriers around every single memory access? Because it’s not just the compiler that can reorder writes, but the underlying CPU as well, which means the compiler has to be aware of concurrency during code generation if concurrency is to behave with any predictability. Which is the point of the article: concurrency cannot be provided as a pure library facility without any participation from the compiler. The language has to define which concurrent memory accesses are valid and how they interact. Otherwise you’re at the mercy of however the platform decides to flush caches that day. I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role.
- ddevault 4y ago
  No, Hare does not emit barriers around every memory access, but the programmer can add them where they want -- and there are no tricky compiler optimizations which will bite them in the ass when they do like this paper describes. > I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role. This was not nice.

pwdisswordfish9 4y ago

Do I have it right that a Hare compiler is supposed to emit barriers around every single memory access? Because it’s not just the compiler that can reorder writes, but the underlying CPU as well, which means the compiler has to be aware of concurrency during code generation if concurrency is to behave with any predictability. Which is the point of the article: concurrency cannot be provided as a pure library facility without any participation from the compiler. The language has to define which concurrent memory accesses are valid and how they interact. Otherwise you’re at the mercy of however the platform decides to flush caches that day. I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role.

ddevault 4y ago
No, Hare does not emit barriers around every memory access, but the programmer can add them where they want -- and there are no tricky compiler optimizations which will bite them in the ass when they do like this paper describes. > I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role. This was not nice.