Very impressive visualization! It'd be great if there could be a <del> legends table </del> (or even better, tooltips) explaining all these confusing acronyms...
EDIT: found doc. Still it would be great if the legends is nearby.
This looks interesting, but hard to grasp for those who's skill set doesn't overlap the technologies used in the demo. Could someone give a summary of what is going on here? Is this a showcase of standard C++ memory management, or of some custom system? What language are those model predicates written in?
A "memory model" and "memory management" are two different things.
Memory management normally conotes the process for allocation and reclamation of memory in a program.
A memory model defines where reads can get their information from in a program. In most contexts that is informally "the most recent write" in terms of wall clock time (i.e. sequential consistency).
In C++, C and Java, this is not necessarily how things are. For example in Java writes can be buffered preventing reads in other threads from seeing them right away. This means those reads will get a value from an "older" write (again wall clock time).
It's all really bad for reasoning about your program :(
> It's all really bad for reasoning about your program :(
True, but it's really good for performance in a lot of incredibly common cases, which is why it's a case of a tough tradeoff they had to make - rather than a malicious choice to just make our lives more difficult. :)
(An expert in this stuff would probably also wave their hands and say something about exotic and/or legacy hardware that those languages need and/or want to support.)
5 comments
[ 3.0 ms ] story [ 21.1 ms ] threadEDIT: found doc. Still it would be great if the legends is nearby.
Memory management normally conotes the process for allocation and reclamation of memory in a program.
A memory model defines where reads can get their information from in a program. In most contexts that is informally "the most recent write" in terms of wall clock time (i.e. sequential consistency).
In C++, C and Java, this is not necessarily how things are. For example in Java writes can be buffered preventing reads in other threads from seeing them right away. This means those reads will get a value from an "older" write (again wall clock time).
It's all really bad for reasoning about your program :(
True, but it's really good for performance in a lot of incredibly common cases, which is why it's a case of a tough tradeoff they had to make - rather than a malicious choice to just make our lives more difficult. :)
(An expert in this stuff would probably also wave their hands and say something about exotic and/or legacy hardware that those languages need and/or want to support.)
[0]: http://preshing.com/20121019/this-is-why-they-call-it-a-weak...