Skip to content
This repository was archived by the owner on Nov 17, 2023. It is now read-only.

[MXNET-57] Added support android64 #11055

Merged
marcoabreu merged 1 commit intoapache:masterfrom
larroy:android
Jun 15, 2018
Merged

[MXNET-57] Added support android64 #11055
marcoabreu merged 1 commit intoapache:masterfrom
larroy:android

Conversation

@larroy
Copy link
Copy Markdown
Contributor

@larroy larroy commented May 24, 2018

Description

Fixes for Android64
Added Android64 to CI

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

  • The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
  • [] Changes are complete (i.e. I finished coding on this PR)
  • All changes have test coverage:
  • Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
  • Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
  • Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
  • Code is well-documented:
  • For user-facing API changes, API doc string has been updated.
  • For new C++ functions in header files, their functionalities and arguments are documented.
  • For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
  • Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
  • To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

@larroy larroy requested a review from szha as a code owner May 24, 2018 15:50
@larroy larroy requested a review from marcoabreu as a code owner May 24, 2018 16:13
@larroy larroy changed the title [WIP] Fixes for android64 [WIP] Added support android64 May 24, 2018
@larroy larroy force-pushed the android branch 3 times, most recently from 9f6e8f9 to 4dfd6d4 Compare May 24, 2018 23:11
@szha szha requested review from yzhliu and removed request for szha May 25, 2018 00:32
@larroy larroy force-pushed the android branch 2 times, most recently from c8d943f to 05ef1df Compare June 6, 2018 18:09
@larroy larroy changed the title [WIP] Added support android64 Added support android64 Jun 6, 2018
@larroy
Copy link
Copy Markdown
Contributor Author

larroy commented Jun 6, 2018

@marcoabreu @szha @piiswrong please merge

-DUSE_OPENCV=OFF\
-DUSE_OPENMP=OFF\
-DUSE_SIGNAL_HANDLER=ON\
-DCMAKE_BUILD_TYPE=RelWithDebInfo\
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

To reduce the size, I'd propose we build without debug info for now

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I want symbols to diagnose initial runs and crashes, there's a reason for this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'd propose that you set that flag locally then. We're referencing these instructions in our guides and to our customers, means we have to provide a ready-made solution. We had the same case previously when a customer complained about the size and in fact it was only the RelWithDebInfo.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I don't see how the points you are making about an experimental build which is not official nor tested are of any relevance at this stage of Android support. This is a development build and I want debug symbols to diagnose crashes, this should be reason enough to have it as it is, because size of build doesn't really matter right now, and debugability is more important.

Copy link
Copy Markdown
Contributor

@marcoabreu marcoabreu Jun 13, 2018

Choose a reason for hiding this comment

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

We already spoke about this offline and I said that I'm fine with moving forward. Before you explaining it to me, I was under the impression that this would be the final stage.

-DUSE_SSE=OFF\
-DUSE_LAPACK=OFF\
-DUSE_OPENCV=OFF\
-DUSE_OPENMP=OFF\
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

No open mp? Android phones usually have around 4 to 8 cores, so we should have it enabled

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

first we make a baseline version run, don't propose to overcomplicate things. Feel free to work on making openmp work in android to use all your cores if you have time.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Well we want to make a good first impression if people use it. If everything is slow the first time they test it, they most likely will not come back. OpenMP is very important, especially since we don't have any other hardware acceleration. Until that works, we can't really tell any customer to use it or we will lose creditability.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is an initial build, what you are saying doesn't apply. Nobody should test this.

Comment thread ci/docker/runtime_functions.sh Outdated
export MXNET_LIBRARY_PATH=`pwd`/libmxnet.so
#cd /work/mxnet/python
#python setup.py bdist_wheel --universal
#cp dist/*.whl /work/build
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Remove commented code

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

there will be more work to build a binary so these comments will go away, having another run of CI will take many hours and with flaky tests potentially days. I would suggest to merge this as it is.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Removed commented out code and added comments on flags that need further investigation

Copy link
Copy Markdown
Contributor

@marcoabreu marcoabreu Jun 7, 2018

Choose a reason for hiding this comment

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

"CI will take many hours and with flaky tests potentially days" is not a valid reason.

Thank you.

Comment thread CMakeLists.txt
mxnet_option(USE_CUDNN "Build with cudnn support" ON) # one could set CUDNN_ROOT for search path
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON)
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON IF NOT ARM)
mxnet_option(USE_F16C "Build with x86 F16C instruction support" ON) # autodetects support if ON
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

does ARM/android support F16C instruction?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

AFAIK F16C is x86, so maybe only in android x86 but most android is ARM, and this is an ARM build ATM. We should add x86 android builds in the future, good point.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should do an automatic scan in the future if the feature is present on the system and the compiler like for F16 in this PR.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does this work also for cross compilation?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Can you give thumbs up or down to the review? Any more comments?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Sure, here you go)

Comment thread CMakeLists.txt Outdated
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON)
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON IF NOT ARM)
mxnet_option(USE_F16C "Build with x86 F16C instruction support" ON) # autodetects support if ON
mxnet_option(USE_LAPACK "Build with lapack support" ON IF NOT MSVC)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

why is this relevant to android64?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

this logic is buggy, so tries to always use LAPACK, and if I recall correctly is not available atm in android. See also: #11094

@larroy larroy force-pushed the android branch 5 times, most recently from 10a6af5 to a74fb07 Compare June 10, 2018 18:52
@larroy larroy changed the title Added support android64 [MXNET-57] Added support android64 Jun 10, 2018
Comment thread CMakeLists.txt
mxnet_option(USE_CUDNN "Build with cudnn support" ON) # one could set CUDNN_ROOT for search path
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON)
mxnet_option(USE_SSE "Build with x86 SSE instruction support" ON IF NOT ARM)
mxnet_option(USE_F16C "Build with x86 F16C instruction support" ON) # autodetects support if ON
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Does this work also for cross compilation?

#COPY install/ubuntu_ccache.sh /work/
#RUN /work/ubuntu_ccache.sh

FROM dockcross/base:latest
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why not use dockcross/android-arm64 ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Happy to do so in a subsequent PR, now this one passed. I would very much like to get it merged so at least we have this build as a gatekeeping mechanism.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ok, cool

@larroy
Copy link
Copy Markdown
Contributor Author

larroy commented Jun 12, 2018

@marcoabreu @piiswrong @szha please merge

#COPY install/ubuntu_core.sh /work/
#RUN /work/ubuntu_core.sh
#COPY install/ubuntu_ccache.sh /work/
#RUN /work/ubuntu_ccache.sh
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Could you elaborate?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Let's get the ARMv7 PR merged first and then I ammend this one and re-enable the ccache logic.

Copy link
Copy Markdown
Contributor

@marcoabreu marcoabreu left a comment

Choose a reason for hiding this comment

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

LGTM besides the ccache removal

@larroy larroy changed the title [MXNET-57] Added support android64 [WIP][MXNET-57] Added support android64 Jun 12, 2018
* Fixes sources for android64
Add initial android64 build logic.
Remove pthread when linking MXNet in Android. Bionic provides built-in support for threads.
* Simplify and fix android64 build
@larroy larroy changed the title [WIP][MXNET-57] Added support android64 [MXNET-57] Added support android64 Jun 12, 2018
@larroy
Copy link
Copy Markdown
Contributor Author

larroy commented Jun 13, 2018

CI is giving problems when downloading CUDA?

http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/PR-11055/23/pipeline

This is an adversarial environment to get code merged.

@marcoabreu marcoabreu merged commit ebf3777 into apache:master Jun 15, 2018
@larroy larroy deleted the android branch June 19, 2018 19:25
zheng-da pushed a commit to zheng-da/incubator-mxnet that referenced this pull request Jun 28, 2018
* Fixes sources for android64
Add initial android64 build logic.
Remove pthread when linking MXNet in Android. Bionic provides built-in support for threads.
* Simplify and fix android64 build
XinYao1994 pushed a commit to XinYao1994/incubator-mxnet that referenced this pull request Aug 29, 2018
* Fixes sources for android64
Add initial android64 build logic.
Remove pthread when linking MXNet in Android. Bionic provides built-in support for threads.
* Simplify and fix android64 build
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants