Hacker News Reader

Comment by JoeAltmaier | Hacker News Reader

This is about large-calculation parallelism. It covers bus architectures and language primitives.

There's another whole parallel (multi-threaded) conversation that's not about raw compute speed, but about latency. Does your app keep running when somebody holds a mouse button down? Does the API stay live when data is being crunched? Does your service handle hundreds or thousands of client requests serially or in parallel?

Those problems have completely different solutions from those addressed in the OP. The language-primitive approach doesn't begin to touch the issues involved.

View on HN

That's not what I see. The book delves into the coordination of shared resources in a shared space (like RAM). This could take the form of task parallelism for speedup, or more likely in this case, task parallelism for concurrency and resource sharing. Since there's so little discussion in the book of issues related to speedup (task decomposition or resource allocation or load balancing), I'm inclined to think it's of most use to someone building a shared memory RDBMS or the like, where semaphores and locks are critical to avoidance of bugs and data corruption.

Those things are of course at bottom of any multi-task discussion. But they are so far below the actionable layer for service designers as to be moot. For that we need to talk about transactional data, about restartable processes, about context and state and where its kept, from a language and data structure point of view.

Joe, we normally call that concurrency, not parallelism.

Language primitives do help there as well: we do both types of computations at Graphistry, and for the concurrency side, use promises, FRP, and occasionally, processes.

That's really helpful. Do you have any suggestions on how to learn more about the latter?

I wish I did. I've spent a lifetime coming up with solutions including languages, app environments and service models that abstract away the difficulties. There exist such models now (didn't 15 years ago) that do some of the work, but they're always designed around some particular problem (clustering and provisioning for instance) and do only part of the job.

The whole job, eg for a service model, includes RAS stuff like failing over and restarting client requests transparently, WITHOUT requiring the service code itself to deal with any of that. I guess Ehrlang and kin are the most recent take on that, meaning an app environment that completely abstracts the parallelism and fault recovery.

If you mean Erlang, please note it’s been released in 1986, and made open-source in 1998. The underlying actor model was introduced by Carl Hewitt et al in 1973.

http://worrydream.com/refs/Hewitt-ActorModel.pdf

Reply on news.ycombinator.com