Skip to content
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

Merged
merged 1 commit into from
Jun 14, 2017
Merged

Conversation

ararslan
Copy link
Member

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.

@ararslan ararslan added building Build system, or building Julia or its dependencies docs This change adds or pertains to documentation labels Jun 10, 2017
@ararslan ararslan requested a review from tkelman June 10, 2017 02:29
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) | | |
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Contributor

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...

Copy link
Member Author

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?

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member

@Sacha0 Sacha0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm! :)

@maleadt
Copy link
Member

maleadt commented Jun 12, 2017

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.

@tkelman
Copy link
Contributor

tkelman commented Jun 12, 2017

I don't think accelerators are appropriate for this section.

@ararslan
Copy link
Member Author

Is there a minimum version of the Linux kernel we claim to support, and if so is it worth mentioning here?

@tkelman
Copy link
Contributor

tkelman commented Jun 12, 2017

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

@ararslan
Copy link
Member Author

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?

@ViralBShah
Copy link
Member

ViralBShah commented Jun 12, 2017

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.

@tkelman
Copy link
Contributor

tkelman commented Jun 12, 2017

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.
Copy link
Member

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.

Copy link
Member Author

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.)

@maleadt
Copy link
Member

maleadt commented Jun 12, 2017

@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.

@tkelman
Copy link
Contributor

tkelman commented Jun 12, 2017

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.

@ararslan ararslan force-pushed the aa/platforms branch 2 times, most recently from 6b03e01 to d6cf81e Compare June 12, 2017 20:40
@ararslan
Copy link
Member Author

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 |
Copy link
Member Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ARM v8 seems clearer

Copy link
Member Author

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!

Copy link
Contributor

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like Yichao is calling it ARM v8 (or rather armv8-a) here, in his PR to add it to the downloads page.

@ararslan
Copy link
Member Author

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!

@ararslan ararslan merged commit 6facbe3 into master Jun 14, 2017
@ararslan ararslan deleted the aa/platforms branch June 14, 2017 19:19
@ViralBShah
Copy link
Member

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.

@ararslan
Copy link
Member Author

Yes, we should definitely have prominent mention of GPU support. Perhaps a dedicated section of the README and/or the documentation?

@tkelman
Copy link
Contributor

tkelman commented Jun 14, 2017

Better for the documentation, it's not entirely topical for this repo's readme.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
building Build system, or building Julia or its dependencies docs This change adds or pertains to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants