[GraphBolt] Improve sample_neighbors() on CPU with prob/mask by 6.47%, fixing #7462

[az15240]

Description

A one line change in NonUniformPickOp, to make prob/mask samplings go faster.

Runtime data is supported by this sheet, by running benchmark_graphbolt_sampling.py locally. Note that this function only works for prob/mask, so I left out data for cases that probs=None.

Checklist

Please feel free to remove inapplicable items for your PR.

• The PR title starts with [$CATEGORY] (such as [NN], [Model], [Doc], [Feature]])
• I've leverage the tools to beautify the python and c++ code.
• The PR is complete and small, read the Google eng practice (CL equals to PR) to understand more about small PR. In DGL, we consider PRs with less than 200 lines of core code change are small (example, test and documentation could be exempted).
• All changes have test coverage
• [ x] Code is well-documented
• To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change
• Related issue is referred in this PR
• If the PR is for a new model/paper, I've updated the example index here.

Changes

[dgl-bot]

To trigger regression tests:

• @dgl-bot run [instance-type] [which tests] [compare-with-branch];
  For example: @dgl-bot run g4dn.4xlarge all dmlc/master or @dgl-bot run c5.9xlarge kernel,api dmlc/master

[dgl-bot]

Commit ID: 1fc5f8a

Build ID: 1

Status: ✅ CI test succeeded.

Report path: link

Full logs path: link

[dgl-bot]

Commit ID: f6819dd1089299f7fbff4c05590eff2d1e191bfe

Build ID: 2

Status: ✅ CI test succeeded.

Report path: link

Full logs path: link

[az15240]

Update: simply removing the .squeeze(1) call will also work, improving performance by 6.47%.

[mfbalin]

@az15240 6.5% speedup with such a simple change is quite good but I wouldn't say this change fixes the issue altogether. Do you think there are other opportunities to further speed it up?

[az15240]

@az15240 6.5% speedup with such a simple change is quite good but I wouldn't say this change fixes the issue altogether. Do you think there are other opportunities to further speed it up?

@mfbalin I think the main reason for this 14x slower is because for certain combination of parameters, the sampling time is too fast. It is not necessarily because our sampling is bad.

In regression, when replace=False or when fanouts=[-1], the cases that probs=None rans really fast. This pattern is not found when replace=True.