Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Build integrated Python package library #3144
Build integrated Python package library #3144
Changes from 18 commits
b1841bd
27dffcb
2958084
519a5b9
84b6804
ec4b3f4
1fc7878
8e66b4e
af176a6
e0c71cb
81e6773
4dac9f5
180c929
80318e0
1782aed
3013f4d
9d0614c
e567f33
d5fad62
dc5ef75
4fd05bc
8a23901
8f140dc
f654d91
2597549
db60d59
e274c8e
e4d2e3a
6acfd26
ee9f545
5d85aa1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Could you please comment on this from compatibility side? Why 1.2?
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.
This appears to be the
latestearliest stable version that contains all the required api's (and 2.x seems to have been a long experiment: https://www.extremetech.com/computing/309842-opencl-3-0-kicks-off-with-a-huge-step-backwards).But the library compiles without specifying the version (with a few extra messages), so we can remove this if you prefer.
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.
Thanks for the clarification! I'm afraid I have too little knowledge about OpenCL to take a responsibility for this change. I'd better leave it for your decision or more experienced in OpenCL maintainer.
I just want to make it possible that as many as possible users will be able to simply download our wheel and run LightGBM with GPU support.
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.
Yes, including the 1.2 guard when you compile the headers prevents you from inadvertently including a call to a 2.x function, which would limit the library to newer implementations. OpenCL versions are backward compatible, so a 2.x implementation can run a 1.2 application/library. (See item 3 here for example: http://developer.amd.com/wordpress/media/2013/12/AMD_APP_SDK_FAQ1.pdf)
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.
Excellent! Thanks again!
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 guess we can workaround 1.5Gb+ size problem by specifying only required submodules here.
Starting from
chrono, filesystem, headers, system, tools/*
by trials and errors I came up with the following list which allows to compile successfully, but I bet you know better which submodules are needed. Also, I believe we can reduce number of submodules under thetools
folder.I know, this list is looking super scary, but explicitly listing submodules it is possible to decrease build time and downloading size significantly (
1.5Gb+ -> 700Mb
)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.
OK, I've experimented more and it looks like
we do not need submodules from. I'm updating my yesterday original comment with new suggestion.tools/
at allUPD: Was wrong.
tools/boost_install
andtools/build
are needed.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.
@StrikerRUS , thank you for doing this exploration.
I'm not opposed to this change, and I've committed the suggested patch, but I think there are some considerations the maintainers should be aware of.
One of the challenges in this patch was coaxing three different build systems (Boost's B2, cmake, and MSVC/make) to cooperate. And as you know I was originally targeting more than just the Windows platform. I found that the Boost dependency list generated at build time differed significantly by platform -- on Linux (generally) only the few expected dependent submodules were built, on Windows (generally), many more submodules were fetched. This was a bit surprising, but I didn't spend a lot of time chasing down why, because it seemed to me that downloading all submodules was always safe, and that even if I figured it all out for each platform, it would lead to complicated platform checking code that might turn out to be fragile in the long run (meaning a risk of not working anymore if the Boost libs or any of the three build systems changed or started interacting differently).
Of course I realize that there may be costs associated with fetching and processing code unecessarily in the CI pipeline, and also that non-Windows builds may never be needed, so I'm OK with the suggested change. I just wanted to alert you all that you may have to rethink this targeted download approach if other platforms are added or the build becomes unstable.
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.
OK, I understand! Please correct me: as long as we fix a particular commit in the
boost
repository and building the library only for Windows users, it is safe to go with my list. In future we can update this list to support building on Linux machines or add conditioningif(WIN32) ... else() ...
or fall back to downloading all submodules for all OSes.Despite that we are using only free CI services (BTW, it will be not true anymore after introducing CUDA support #3160), we build nightly artifacts for each commit in
master
and in general I believe it is good practice to download things only that are needed.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.
Not related to this PR, but just my curiosity. Don't you know were there any changes in macOS related to OpenCL support? Refer to #1523 (comment) and #667. I believe some macOS users with eGPUs will benefit a lot.
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 sorry, but I'm not too familiar with the details of OpenCL on MacOS. But the #667 issue you linked to seems (at first glance) like it could be resolved by an approach similar to this PR. I'll look into it further when I get a bit of time.
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.
Could you please comment on this? Is it related to KhronosGroup/OpenCL-ICD-Loader#11 or MinGW support can be just added later in another PR?
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.
This is a terrible message, I'm sorry for that -- I'm pretty sure it was just a placeholder I forgot to change.
The underlying issue that because MinGW installations are so varied, it's more difficult to predict the name and location of the .lib files. So this should be addressed in a separate PR.
I've changed the message to show that MinGW is not supported yet.
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.
Got it! Thank you!
I'm not sure but it seems that it even doesn't worth to implement MinGW support. Anyway, we will create nightly and release wheels under VS for the performance purposes (https://lightgbm.readthedocs.io/en/latest/FAQ.html#i-am-using-windows-should-i-use-visual-studio-or-mingw-for-compiling-lightgbm). As long as compiled with VS library doesn't conflict with MinGW (have no idea how can it happen) and this option remains "private" (for repo maintainers or very advanced third-party developers), MinGW support is not needed, I believe. Please correct me if I'm wrong.
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 far from an expert, but my impression is also that MinGW support is significantly less urgent since MSFT began making the MSVC community edition available for free.