search

chapel-lang / chapel

a Productive Parallel Programming Language
https://chapel-lang.org
Other
1.78k stars 419 forks source link

Support Windows OS #12453

Open ben-albrecht opened 5 years ago

ben-albrecht commented 5 years ago

This issue serves as a place to discuss and document what it would take to support Chapel on Windows. I will update this description with more info as needed.

Challenges

Note: This is unrelated to Windows subsystem for Linux (WSL) and Cygwin, which already support Chapel.

bradcray commented 5 years ago

Traditionally, one of the foremost challenges has been that the Chapel compiler relies on nix style commands to build and link the generated code. Though it ought to be possible to use various nix emulator packages and command-line tools to get around this, in the attempts I've made in the past, I was never able to get them working before giving up / timing out.

After that, the likely next challenge will be lack of native POSIX threads, requiring either some third-party technology to fill that gap or for a native Windows threads port of the tasking runtime to be undertaken.

ghenriks commented 5 years ago

I believe clang/llvm work natively on Windows so perhaps that might offer a solution that would work for Chapel.

pclausen commented 4 years ago

I landed here because I was trying to figure out if Chapel is supported by windows, which I guess it is not yet.

I think the Chapel language is very interesting, but the lack of support of windows is unfortunately a NOGO for me to even consider to use the language professionally. I personally like nix systems, and HPC is definitely dominated by them. However, businesses are mostly using windows 10 as primary work station and thus for me an essential platform to have a reasonable performance on as well as nix for a commercial application.

bradcray commented 4 years ago

Thanks for your comment @pclausen. As you hopefully saw in the OP, Chapel can be used on Windows 10 systems via Windows Subsystem for Linux (WSL) / Linux bash shell. However, the level of interest in a native Windows port hasn't reached the point that it's made it onto my team's list of priorities, unfortunately. And meanwhile, we haven't found anyone in the open-source community interested in leading the effort to create a native Windows port of Chapel (needless to say, anyone reading this who might be interested in doing so, please let us know).

MarcTCruz commented 2 years ago

Thanks for your comment @pclausen. As you hopefully saw in the OP, Chapel can be used on Windows 10 systems via Windows Subsystem for Linux (WSL) / Linux bash shell. However, the level of interest in a native Windows port hasn't reached the point that it's made it onto my team's list of priorities, unfortunately. And meanwhile, we haven't found anyone in the open-source community interested in leading the effort to create a native Windows port of Chapel (needless to say, anyone reading this who might be interested in doing so, please let us know).

How about using cpp std::thread instead of posix and forget about supporting different OS threads at all?

bradcray commented 2 years ago

How about using cpp std::thread instead of posix and forget about supporting different OS threads at all?

Hi @MarcTCruz : That's an interesting idea, where we could even consider adding support for a new tasking option in our runtime that was built in terms of std::thread rather than POSIX threads. One (minor) challenge to doing so is that, today, our runtime is almost exclusively C rather than C++ code, but I think that's surmountable. I'd personally need to read up more on C++ threads to see what semantics they provide to have a better sense of how good of a match they'd be for us or not.

Note that our preferred tasking option currently is qthreads (a lightweight threading package from Sandia) which, to my knowledge, doesn't have the ability to be run over any threads other than pthreads, so while using std::thread could provide an alternate portability option, we likely wouldn't retire support for POSIX thread-based options altogether (unless C++ could compete with Qthreads, which... would surprise me, albeit pleasantly).

Aeva commented 5 months ago

@mppf requested I share a comment here following a discussion on Mastodon about whether Chapel would be a good fit for a game engine project I'm developing in my spare time to prove out novel real time rendering techniques (I've been considering rewriting the C++ internals in another language for several reasons that are unimportant for this post). Chapel's emphasis on concurrency is attractive, as my project involves a significant amount of parallel rendering work on the CPU in addition to ordinary concurrent game tasks. However, it is unlikely that I will be selecting Chapel, and mppf requested a share feedback as to why, so here it is:

Mppf mentioned off hand that there is no native Windows support, and that one would typically run it through WSL or Cygwin, to which I replied that unfortunately would be a show stopper for me. There are a few reasons why that is a non starter for a game project. The first being that I'm skeptical that it's possible to distribute WSL applications on Steam. The second being that it would be excessively difficult to port the engine or any games written in it to Xbox. The third problem is that generally a tool only being available through Cygwin or MinGW or WSL is very often a reliable red flag of neglect for the platform indicating that one is unfortunately likely to find many more problems with use that are a low priority for the maintainers.

Anyways, as Chapel's emphasis is clearly very focused on scientific and academic superb computing, I won't take it personally if game development is seen a very distant priority for the language's development, but I hope this feedback is useful nevertheless.

bradcray commented 5 months ago

Thanks for the feedback @Aeva. I'm giving a talk at Microsoft tomorrow, and one of the things I'll be curious to explore is whether there's any appetite there for helping develop native Windows support for Chapel.