I had a comment on the previous lecture where not being able to reason about how the program runs prevents programmers from making optimizations based on their algorithm. I guess the last part of this slide justifies that comment.
But the interesting thing is that why did these two different domain-specific languages made completely opposite choices? Come to think of it, there could be an optimal choice however they both appear to be running on a very similar set of data.
Elias
It still seems really funky to me that the programmer needs to choose the scheduling policy and consistency guarantee, and a wrong choice can actually impact the correctness. While I understand that this may be necessary to achieve really optimal speedup, it seems incredibly dangerous - this is going to cause people who aren't experts in the system to make mistakes which are very difficult to find. I'd say that this fails the requirement that a domain specific language be simple to use - this is the epitome of NOT novice-friendly.
Maybe this just means that when the domain is graph algorithms, simplicity of interface is difficult (or impossible) to achieve.
lament
@Elias To be fair, what is the target audience of the language? If a language is geared for use in, say, a cluster with 1000 workers, then it would seems silly to think that any group with such resources would not have the sufficient knowledge.
Further, thinking of how to schedule "work" does not seem like anything new. You have to think of how you want to uncover vertices when deciding between DFS v.s. BFS, for example. If I understand things correctly, here we decide when to look at a vertex based on the schedule policy, and this schedule policy crosses the abstraction-implementation boarder a bit.
solovoy
In training Graphical Models in Machine Learning, different schedules of updating nodes may mean different training algorithms. So, I think this aims to give researchers more flexibility of experimenting different "algorithms".
I had a comment on the previous lecture where not being able to reason about how the program runs prevents programmers from making optimizations based on their algorithm. I guess the last part of this slide justifies that comment.
But the interesting thing is that why did these two different domain-specific languages made completely opposite choices? Come to think of it, there could be an optimal choice however they both appear to be running on a very similar set of data.
It still seems really funky to me that the programmer needs to choose the scheduling policy and consistency guarantee, and a wrong choice can actually impact the correctness. While I understand that this may be necessary to achieve really optimal speedup, it seems incredibly dangerous - this is going to cause people who aren't experts in the system to make mistakes which are very difficult to find. I'd say that this fails the requirement that a domain specific language be simple to use - this is the epitome of NOT novice-friendly.
Maybe this just means that when the domain is graph algorithms, simplicity of interface is difficult (or impossible) to achieve.
@Elias To be fair, what is the target audience of the language? If a language is geared for use in, say, a cluster with 1000 workers, then it would seems silly to think that any group with such resources would not have the sufficient knowledge.
Further, thinking of how to schedule "work" does not seem like anything new. You have to think of how you want to uncover vertices when deciding between DFS v.s. BFS, for example. If I understand things correctly, here we decide when to look at a vertex based on the schedule policy, and this schedule policy crosses the abstraction-implementation boarder a bit.
In training Graphical Models in Machine Learning, different schedules of updating nodes may mean different training algorithms. So, I think this aims to give researchers more flexibility of experimenting different "algorithms".