search

carbon-language / carbon-lang

Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)
https://github.com/carbon-language/carbon-lang/blob/trunk/README.md
Other
32.27k stars 1.47k forks source link

Parallel Processing #1474

Open paspro opened 2 years ago

paspro commented 2 years ago

I would argue that if one decides to create a new programming language in today's world it should be designed with parallel processing as part of the language grammar and not with the use of some library, even if this is part of the standard library.

A new language with expressions to specify parallel loops, multiple threads, coarrays etc without OpenMP, MPI, OpenACC, CUDA, OpenCL and the rest is more important for the C++ programming community which is interested in having high performance code on modern hardware rather than a somewhat easier to use syntax and safe structures which a typical C++ programmer already achieves following the latest C++ standard in combination with a disciplined style of programming.

Are there any plans for adding parallel programming features in the language syntax itself?

srihari39 commented 2 years ago

Good one @paspro . Parallel programming is essential for the efficiency of modern hardware. Well, I've been using C++ for a while, and I understand the concern over including parallelism as a part of the language grammar. The thread support again varies from OS to OS. Chapel is one such programming language which is highly focussed on the parallelism aspect. We can look into that and take some breaking implementations, it being an open source project itself. Implementation details apart,

I would suggest a keyword identifier for using parallel loops/ multiple threads safely. In that way we can use both the normal and parallel loops at our wish without unnecessary employing either parallel/sequential on all the things. This way, if implemented, the keyword itself takes care of the OS and regarding implementation. This saves a ton of time for the developers for sure.

chandlerc commented 2 years ago

I think everyone is generally interested in these directions, but a) I think folks have so far been a bit prioritizing some of the foundations needed for interop, and b) just limited in bandwidth to pick up and explore this.

If folks are interested in beginning exploring this space, we can leave this issue open to track it, but otherwise it may make sense to close it as "not yet, but definitely interested if/when folks start working on this direction in the future".

srihari39 commented 2 years ago

Yeah, that should work.

nadiasvertex commented 2 years ago

@chandlerc How would you suggest we go about exploring it? Simply suggesting a design specification? Or something else?

geoffromer commented 2 years ago

@chandlerc How would you suggest we go about exploring it? Simply suggesting a design specification? Or something else?

You might want to start with a Discord discussion and/or an informal design in a Google Doc (but please use the shared Drive and the doc template as described in CONTRIBUTING.md), because it's a little harder to have collaborative discussions on a pull request.

github-actions[bot] commented 1 year ago

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.