3 ms·

Perhaps I am the one is over focused on distributed use. However, their are a lot of servers in the world ;) Also how do you classify work loads like physical

Perhaps I am the one is over focused on distributed use. However, their are a lot of servers in the world ;) Also how do you classify work loads like physical simulation that are one of the classic use cases for parallel processing but not embarrassingly parallel in that they need lots of communication between cores? Better tools for analyzing distributed computation would be cool. I think that we would have to think carefully about the kind of bugs to look for. Since data access/distribution is slow more thought tends to go into it (and there are systems in place for doing it well) but there are of course loads of other issues that show up.

_yosefk 13y ago
I think if the simulation is deterministic it's parallel, if it's OK with not being deterministic then it's concurrent; I'd fight to keep it parallel and not concurrent, but I don't know how hard it is, maybe in some cases you can't realistically win the battle. I very much think it's valuable to treat distributed, parallel systems specially and not just use concurrency-oriented tools - it's better to exploit determinism for automated debugging, it's just not my area at the moment - I work more on shared-memory systems. I was involved in some work with parallelizing on multiple boxes at process granularity, but it wasn't elaborate enough to go deeply into any of these issues.
- micro_cam 13y ago
  Things definitely get messy in scientific computing. It is common to have algorithms that are stochastic for other reasons. I'm working on a parallel random forest implementation at the moment...very little communication between threads is needed but the algorithm itself is stochastic (unless you seed your random number generators in a clever way i guess). (And I've use go's concurrency primitives and race tool for things like writing the forest to disk as trees are grown in parallel and compiling summary statistics). I do think that tools like the one you are writing are very useful and needed. I just have a bad habit of wanting everything to meet my needs.

_yosefk 13y ago

I think if the simulation is deterministic it's parallel, if it's OK with not being deterministic then it's concurrent; I'd fight to keep it parallel and not concurrent, but I don't know how hard it is, maybe in some cases you can't realistically win the battle. I very much think it's valuable to treat distributed, parallel systems specially and not just use concurrency-oriented tools - it's better to exploit determinism for automated debugging, it's just not my area at the moment - I work more on shared-memory systems. I was involved in some work with parallelizing on multiple boxes at process granularity, but it wasn't elaborate enough to go deeply into any of these issues.

micro_cam 13y ago
Things definitely get messy in scientific computing. It is common to have algorithms that are stochastic for other reasons. I'm working on a parallel random forest implementation at the moment...very little communication between threads is needed but the algorithm itself is stochastic (unless you seed your random number generators in a clever way i guess). (And I've use go's concurrency primitives and race tool for things like writing the forest to disk as trees are grown in parallel and compiling summary statistics). I do think that tools like the one you are writing are very useful and needed. I just have a bad habit of wanting everything to meet my needs.