Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
1–10 of 12 posts
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#2I think there are two ways forward; larger L1 caches or split memory between cores, both have their problems.
To solve what this article argues about though, you can use my internet platform: https://github.com/tinspin/rupy
Java has excellent concurrency and non-blocking implementations.
Since it also has the only class-loader that is worth using, it's the only programming language you can use for server-side joint parallel future proof systems today.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#3The article says a lot about concurrent programming, but little about parallel programming.
The naming is misleading.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#4The article says a lot about concurrent programming, but little about parallel programming. The naming is misleading.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#5The article says a lot about concurrent programming, but little about parallel programming. The naming is misleading.
But a language that is concurrent and not parallel will usually (always? can't think of a counter-example) have a full memory barrier on a context switch, so the memory model is simple. I think that's why it's relevant to many parallel programming models, but not concurrent programming ones, and why the title is as it is.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#6The article says a lot about concurrent programming, but little about parallel programming. The naming is misleading.
The naming is not misleading, because the article says a lot about parallel processing.
It is talking about memory consistency models, for heaven's sake. If you have a uniprocessor, or any kind of concurrency without parallelism, it makes zero sense to talk about memory consistency models because you automatically have sequential consistency and don't have to think about it.
If you don't have a multiprocessor, you don't need to think about memory consistency models. If you have a multiprocessor without parallelism, that's your problem, not the author's.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#7The article says a lot about concurrent programming, but little about parallel programming. The naming is misleading.
The naming is not misleading, because the article says a lot about parallel processing. It is talking about memory consistency models, for heaven's sake. If you have a uniprocessor, or any kind of concurrency without parallelism, it makes zero sense to talk about memory consistency models because you automatically have sequential consistency and don't have to think about it. If you don't have a multiprocessor, you do…
Unfortunately because of compiler optimizations, memory models are important even on uniprocessors.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#8Earlier quoted context omitted.
The naming is not misleading, because the article says a lot about parallel processing. It is talking about memory consistency models, for heaven's sake. If you have a uniprocessor, or any kind of concurrency without parallelism, it makes zero sense to talk about memory consistency models because you automatically have sequential consistency and don't have to think about it. If you don't have a multiprocessor, you do…
Unfortunately because of compiler optimizations, memory models are important even on uniprocessors.
Sure, and the article discusses that. I was thinking at the instruction level. I tend to think of convincing the hardware to do what you want and convincing the compiler to do what you want separately as an effect of writing code before the languages had specified memory models.
EDIT: Though as I think about it I'm having a hard time thinking of a system in which those compiler optimizations are problematic on a uniprocessor system. It is definitely true that optimizations that are safe on a uniprocessor break on a multiprocessor, but I can't think of any systems that don't (effectively) have a memory barrier when switching between threads. SMT wouldn't see a problem because both threads are on the same processor.
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#9Since this is about parallel languages, why don't they say anything about Erlang and related languages?
Re: Memory Models: A Case for Rethinking Parallel Languages and Hardware (2010)
#10Since this is about parallel languages, why don't they say anything about Erlang and related languages?
Erlang has a trivial memory model, so it isn’t interesting in an article about the challenges of memory models.