-
Notifications
You must be signed in to change notification settings - Fork 36
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
GPU implementation of hamming distance #541
base: main
Are you sure you want to change the base?
Conversation
for more information, see https://pre-commit.ci
… into numba_hamming
for more information, see https://pre-commit.ci
… into numba_hamming
for more information, see https://pre-commit.ci
…tcrdist distance metrics
… into numba_hamming
for more information, see https://pre-commit.ci
… into numba_hamming
for more information, see https://pre-commit.ci
… into numba_hamming
…curing in all sequences
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
…into gpu_hamming
for more information, see https://pre-commit.ci
…into gpu_hamming
for more information, see https://pre-commit.ci
…ceCalculator` in documentation
…into gpu_hamming
for more information, see https://pre-commit.ci
gpu_n_blocks: | ||
Number of blocks in which the final result matrix should be computed. Each block reserves GPU memory | ||
in which the computed result block has to fit in sparse representation. Lower values give better performance | ||
but increase the risk of running out of reserved memory. This value should be chosen based on the | ||
estimated sparsity of the result matrix and the size of the GPU device memory. | ||
gpu_block_width: | ||
Maximum width of blocks in which the final result matrix should be computed. Each block reserves GPU memory | ||
in which the computed result block has to fit in sparse representation. Higher values allow for a lower | ||
number of result blocks (gpu_n_blocks) which increases the performances. This value should be chosen based on | ||
the GPU device memory. |
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.
Why do we need both? Can't you infer one based on the other?
|
||
block_offset = start_column | ||
|
||
print( |
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 suggest to use logging.info
instead of print
seqs_mat1, seqs_L1 = _seqs2mat_fast(seqs, max_len=max_seq_len) | ||
seqs_mat2, seqs_L2 = _seqs2mat_fast(seqs2, max_len=max_seq_len) | ||
except UnicodeError: | ||
print( |
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 suggest to use logging.info instead of print
for more information, see https://pre-commit.ci
Hamming distance implementation with numba.cuda for GPU support.
This is built on top of the changes in Hamming distance implementation with Numba #512
@grst: