-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Improve the platform support section of the README #22319
Conversation
README.md
Outdated
| macOS 10.8+ | x86-64 (64-bit) | ✓ | ✓ | | ||
| Windows 7+ | x86-64 (64-bit) | ✓ | ✓ | | ||
| | i686 (32-bit) | ✓ | ✓ | | ||
| FreeBSD 11.0+ | x86-64 (64-bit) | | | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
guess ci is waiting on it to stay green for long enough to turn #20585 on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you mean. In this case I just rebase and rebuild master then run tests on my FreeBSD laptop regularly. IIRC Yichao does something similar for AArch64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In #20585 @iblis17 is offering to run freebsd CI on a buildbot instance run by him, basically as soon as it's passing and we turn on a webhook, we should see it on PR's
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right. I'm not sure what you mean by "CI is waiting on it to stay green long enough." I believe that builtbot uses system libraries, which will bypass the stuff I did to get it building from scratch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm referring to the tests passing and staying that way
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We actually do have binary for aarch64, just needs to put it up JuliaLang/www_old.julialang.org#581
We also regularly run tests on arm/aarch64 and ppc64, though not through CI and not on all commits...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@yuyichao Would you suggest I add something to that effect in the text here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are power tests running? I wouldn't call it "regular" if you mean only when someone logs into a power machine and does it manually
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They all in on the new buildog.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ararslan @tkelman I checked #21917, reconfigured my buildbot to build from scratch and now it passed on one of my worker (https://julia.iblis.cnmc.tw/#/builders/1/builds/1460) !
(now, I'm configuring the second worker. It's a 10-years-old machine, hope it can help.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! :)
Mention NVPTX, like Rust does, with a link to CUDAnative? Quite a different level of support though (no proper stdlib, not even the entire language is supported), so I wouldn't add it to the main roster. |
I don't think accelerators are appropriate for this section. |
Is there a minimum version of the Linux kernel we claim to support, and if so is it worth mentioning here? |
I think we still nominally support the kernel and glibc versions that centos 5 used but we'll probably be updating the minimum to centos 6 now that 5 is eol |
Looks like CentOS 5 is based on version 2.6.18 of the Linux kernel and CentOS 6 is 2.6.32. Is it worth putting one of those in there? |
I disagree @tkelman. Accelerators are quite appropriate and even relevant here. We already run on on NVPTX and KNL. You may need to follow additional instructions, but I think it is a great idea to mention these. |
If it's supported as a compiler target / library instead of a totally different platform of how you build the host julia, that's not what this section is about. We wouldn't mention ParallelAccelerator here, I don't think we should mention CudaNative. A GPU is not an operating system, it's kind of an architecture but given the limitations of the kind of code that can run, it's a stretch to call it supported in/by the readme of this repo. You don't need to use a different Julia than usual to run CudaNative even - I think it still requires a source build (simply because there's LLVM shim code that hasn't been upstreamed here, which could make binaries work without too much difficulty) but otherwise unmodified. KNL is x86_64 but with an extended instruction set, and we don't mention every single variety or generation of x86_64 in this section either. |
README.md
Outdated
|
||
All systems marked with ✓ for CI are tested using continuous integration for every commit. | ||
Systems with ✓ for binaries have official binaries available on the [downloads](https://julialang.org/downloads) page. | ||
The systems listed here with neither CI nor official binaries are known to build and work, but ongoing support for those platforms is dependent on community efforts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a "Supported", "Basic support" or "Community support" column for these? It looks weird to list platforms without any ticked cell.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rust handles this via what they call "tiers," i.e. ascending numbered levels of support. (Though I think everything they list has some level of official support.)
@tkelman Agreed, it's a whole different type/level of "support", but that's partially because of our compiler's flexibility. Traditionally, GPU support is a full-fledged target in the compiler (eg. clang), generating appropriate host glue code along with emitting device code, so I figured it might be good to have a pointer towards our external support for people expecting it to be a part of Julia core. |
Does anyone expect that? As a note on a detailed platform breakdown page I could see mentioning the ptx target, but not on the main readme here alongside operating systems you'd want to be installing or building julia on. Rust doesn't mention ptx anywhere on their main repo readme. |
6b03e01
to
d6cf81e
Compare
I'll avoid adding GPU stuff to this section for now. We can always mention that elsewhere, like in the documentation. Are there any further comments? |
README.md
Outdated
| | i686 (32-bit) | ✓ | ✓ | Official | | ||
| | PowerPC (64-bit) | | ✓ | Official | | ||
| | ARM v7 (32-bit) | | ✓ | Official | | ||
| | AArch64 (64-bit) | | ✓ | Official | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it preferable to refer to this as AArch64 or ARM v8? cc @yuyichao
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ARM v8 seems clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I'll go with that. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's called aarch64 most places I've seen it referred to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there have been no requests for changes to the existing content, just suggestions for further additions (which have been met with some disagreement), I'm going to go ahead and merge this. We can figure out where to add GPU stuff and what to say about it in a different PR. Thanks for your help and feedback, everyone! |
I think it is really cool that we support PTX as a backend, and we should talk about it more prominently. It is much more meaningful for us being in hpc rather than Rust. |
Yes, we should definitely have prominent mention of GPU support. Perhaps a dedicated section of the README and/or the documentation? |
Better for the documentation, it's not entirely topical for this repo's readme. |
I noticed recently that Rust has a very nice page on their platform coverage: https://forge.rust-lang.org/platform-support.html. Ours in comparison is a little sparse. This PR cleans up the section of the README where we talk about the platforms we support and makes it look a little bit spiffier.
Note: I've skipped CI but
make check-whitespace
was run locally and passed.