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

Go API - [WIP] #212

Open
wants to merge 52 commits into
base: branch-24.12
Choose a base branch
from
Open

Go API - [WIP] #212

wants to merge 52 commits into from

Conversation

ajit283
Copy link
Contributor

@ajit283 ajit283 commented Jul 3, 2024

This PR adds a Go API. It's far from completion and still work in progress. Feel free to suggest improvements!

@ajit283 ajit283 requested a review from a team as a code owner July 3, 2024 19:57
Copy link

copy-pr-bot bot commented Jul 3, 2024

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@github-actions github-actions bot added the CMake label Jul 3, 2024
@benfred benfred added improvement Improves an existing functionality non-breaking Introduces a non-breaking change labels Jul 3, 2024
@cjnolet
Copy link
Member

cjnolet commented Jul 9, 2024

/ok to test

@ajit283 ajit283 requested review from a team as code owners July 10, 2024 17:26
@ajit283 ajit283 requested a review from jameslamb July 10, 2024 17:26
@github-actions github-actions bot added the ci label Jul 10, 2024
@cjnolet cjnolet changed the base branch from branch-24.10 to branch-24.12 November 4, 2024 20:20
@@ -0,0 +1,92 @@
package brute_force

// #include <cuda_runtime_api.h>
Copy link
Member

Choose a reason for hiding this comment

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

Can these be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The Go compiler uses these comments to link the necessary cuvs source files: https://go.dev/wiki/cgo

trained bool
}

// func (index *Index) Close() {
Copy link
Member

Choose a reason for hiding this comment

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

This too- can this be removed?

return p, nil
}

func CreateIndexParams() (*IndexParams, error) {
Copy link
Member

Choose a reason for hiding this comment

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

Are these function names namespaced in some way? For example, will this conflict with an ivfpq CreateIndexParams or does the Go compiler know that this is different because it's nested in a cagra directory? I wonder if we should mirror the C nameing convention (i.e. cuvsCagraIndexParamsCreate, prefix functions with cuvs, followed by the subject and put the verb at the end).

Copy link
Member

Choose a reason for hiding this comment

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

Nevermind, I see the package cagra at the top of the file so I'm assuming everything is nested inside. I think I'd prefer to fully qualify these packages, though, for consistency with the other cuVS APIs: cuvs.neighbors.cagra.


// CBuildAlgo, exists := CBuildAlgos[build_algo]

// if !exists {
Copy link
Member

Choose a reason for hiding this comment

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

Please make sure to remove all commented out code.

AutoSelect: C.AUTO_SELECT,
}

func CreateCompressionParams() (*CompressionParams, error) {
Copy link
Member

Choose a reason for hiding this comment

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

Can we please document all of these functions? Does Go have a common convention or tooling for generating standardized documentation?

DistanceDice: C.DiceExpanded,
}

func PairwiseDistance[T any](Resources Resource, x *Tensor[T], y *Tensor[T], distances *Tensor[float32], metric Distance, metric_arg float32) error {
Copy link
Member

Choose a reason for hiding this comment

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

This is really great! I like how nicely this API translates.

go/distance.go Outdated
// #include <cuda_runtime_api.h>
// #include <cuvs/core/c_api.h>
// #include <cuvs/distance/pairwise_distance.h>
// #include <cuvs/neighbors/brute_force.h>
Copy link
Member

Choose a reason for hiding this comment

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

For ease of maintenance, can we please create a separate directory for all the testing code?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In Go, the convention is to have the tests in the same folder, but with a _test suffix, see here: https://blog.jetbrains.com/go/2022/11/22/comprehensive-guide-to-testing-in-go/

The Go toolchain recognizes these files as tests and also excludes them from the compiled binary.

@@ -0,0 +1,160 @@
package cagra
Copy link
Member

Choose a reason for hiding this comment

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

For consistency, I think I'd prefer to mirror the top-level namspaces also (e.g. cuvs/neighbors/cagra. Can we do nested packages like this?

go/dlpack.go Outdated
@@ -0,0 +1,464 @@
package cuvs

// #include <stdio.h>
Copy link
Member

Choose a reason for hiding this comment

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

This would be easier to follow if we mirrored the existing cuVS directory structures for C/C++: cuvs/core/dlpack.go, etc...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was orienting myself at the rust library: https://github.com/rapidsai/cuvs/tree/branch-24.12/rust/cuvs/src
We can still put in a seperate folder though, I'm fine with either way

@cjnolet
Copy link
Member

cjnolet commented Nov 15, 2024

@ajit283 this is a great contribution and very welcomed! Overall, I think this PR is shaping up well. Each API needs documentation, and ideally usage examples. It would also be ideal to build the documentation as part of this PR. We use Sphinx for our documentation (with a plugin for Doxygen so that it can include our C++ docs alongside our Python docs). I believe there's a Go plugin for Sphinx also.

Please remove commented out code and structure your files to mirror C/C++ codebase and namespaces as much as possible.

I'm really happy to get this in 24.12! JFYI, burndown starts next Thursday (Nov 21) and code freeze is the following Thursday (you can learn more at https://docs.rapids.ai/maintainers/).

@cjnolet
Copy link
Member

cjnolet commented Nov 20, 2024

/ok to test


rapids-dependency-file-generator \
--output conda \
--file-key go \
Copy link
Contributor Author

Choose a reason for hiding this comment

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

do you know how I could add this file key to rapids-dependency-file-generator?

Copy link
Member

Choose a reason for hiding this comment

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

cc @bdice @vyasr @AyodeAwe any suggestions here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Add a key under files: in dependencies.yaml, then add dependency lists with the conda packages you need. Here’s the rust one for comparison:

rust:

Copy link
Contributor

Choose a reason for hiding this comment

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

go-build:
needs: cpp-build
secrets: inherit
uses: rapidsai/shared-workflows/.github/workflows/[email protected]
Copy link
Contributor Author

Choose a reason for hiding this comment

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

am I doing this correctly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci CMake improvement Improves an existing functionality non-breaking Introduces a non-breaking change
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

4 participants