[FLINK-17795][example] Add MatrixVectorMul example

[KarmaGYZ]

What is the purpose of the change

Add MatrixVectorMul example. In this example, we implement the matrix-vector multiplication program that shows how to leverage GPU resources in Flink.

Notice that this example could only be executed in a Linux environment with CUDA 10.0.

Brief change log

Add MatrixVectorMul example.

Verifying this change

I manually test it in a Linux environment with NVIDIA GPU and CUDA 10.0 toolkit.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): yes
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: no
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

[flinkbot]

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit 78762a3 (Fri May 29 02:04:44 UTC 2020)

Warnings:

• 1 pom.xml files were touched: Check for build and licensing issues.
• No documentation files were touched! Remember to keep the Flink docs up to date!

_{Mention the bot in a comment to re-run the automated checks.}

Review Progress

• ❓ 1. The [description] looks good.
• ❓ 2. There is [consensus] that the contribution should go into to Flink.
• ❓ 3. Needs [attention] from.
• ❓ 4. The change fits into the overall [architecture].
• ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
• @flinkbot approve all to approve all aspects
• @flinkbot approve-until architecture to approve everything until architecture
• @flinkbot attention @username1 [@username2 ..] to require somebody's attention
• @flinkbot disapprove architecture to remove an approval you gave earlier

[flinkbot]

CI report:

• 4703e15 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run travis re-run the last Travis build
• @flinkbot run azure re-run the last Azure build

[tillrohrmann]

Thanks for creating this PR @KarmaGYZ. The example looks good to me. I had a question concerning the limitations of JCuda and the juggling of temp directories. Moreover, I would suggest to not include this example in flink-dist. I believe that it is too specific for an example.

[tillrohrmann]

Same here. Why can we exclude it.

[KarmaGYZ]

Same as above.

[zentol]

I would like to hold off on merging this PR.

There are some ongoing discussions related to CUDA in LEGAL-515/LEGAL-516, which make it difficult to nail down what the licensing situation actually looks like.
While the JCuda project itself is MIT licensed, they do compile against the NVIDIA CUDA headers, which may impose limitations that are not compliant with the ASF.

While we aren't redistributing JCuda in the usual sense, we still offer a one-click retrieval service for users without providing additional legal information, which is effectively the same.

[tillrohrmann]

@zentol do you think it would be good enough to remove add-jcuda-dependency.sh and add a section to the example description which explains how to download the cuda library manually?

[zentol]

@tillrohrmann That would probably be fine. The example itself isn't a problem since all native code is(?) contained in the *-natives dependencies that we exclude.

[tillrohrmann]

Ok, then let's do it like this. We remove the add-jcuda-dependency.sh script and write it in the JavaDocs of the example what the requirements are and where you can download the native code. Would this be ok with you @KarmaGYZ?

[KarmaGYZ]

@tillrohrmann I'm ok with it.
Regarding the legal issue, I afraid that I don't fully understand the problem. Is it only related to the native codes? Could @zentol help to check the https://repo1.maven.org/maven2/org/jcuda/jcuda/10.0.0/jcuda-10.0.0.jar?

[KarmaGYZ]

@tillrohrmann Thanks for the review. PR updated according to the latest consensus.

[zentol]

@KarmaGYZ Yes, this is only about the native code, since that is what is being compiled against the cuda headers. The linked jar only contains java code, and thus should be fine.

[KarmaGYZ]

@zentol Thanks for the explanation and help!

[tillrohrmann]

Thanks for addressing our comments @KarmaGYZ. LGTM. Merging this PR now.