You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is becoming increasingly common in high-performance computing to hear assertions that CS education programs need to integrate concurrency and parallelism patterns throughout the curriculum, including even the intro courses.
There is perhaps some merit to these assertions; imagine how much easier parallel computing would be if students learned from the very beginning how to identify and express dependency-free computation. Some argue that this mode of programming is actually more intuitive ("perform action X on every element in this collection" is often inherently dependency-free) and that we lose something by forcing everyone to learn a procedural paradigm first, linearizing the computation unnecessarily.
However, it's unclear how best to integrate concurrency into a language like Less-Java without overly complicating the language or introducing major safety issues. Perhaps it could mean adding something similar to futures, which are already implemented in Java and thus could be relatively easy to add to Less-Java. Perhaps it could involve adding annotations that the compiler converts to threaded code, like OpenMP. Or maybe it's adding new language keywords like spawn / sync in Cilk. This is open future work.
The text was updated successfully, but these errors were encountered:
It is becoming increasingly common in high-performance computing to hear assertions that CS education programs need to integrate concurrency and parallelism patterns throughout the curriculum, including even the intro courses.
There is perhaps some merit to these assertions; imagine how much easier parallel computing would be if students learned from the very beginning how to identify and express dependency-free computation. Some argue that this mode of programming is actually more intuitive ("perform action X on every element in this collection" is often inherently dependency-free) and that we lose something by forcing everyone to learn a procedural paradigm first, linearizing the computation unnecessarily.
However, it's unclear how best to integrate concurrency into a language like Less-Java without overly complicating the language or introducing major safety issues. Perhaps it could mean adding something similar to futures, which are already implemented in Java and thus could be relatively easy to add to Less-Java. Perhaps it could involve adding annotations that the compiler converts to threaded code, like OpenMP. Or maybe it's adding new language keywords like
spawn
/sync
in Cilk. This is open future work.The text was updated successfully, but these errors were encountered: