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

Feature/lospn2std opt select #61

Open
wants to merge 15 commits into
base: develop
Choose a base branch
from
Open

Conversation

mhalk
Copy link
Collaborator

@mhalk mhalk commented Jun 28, 2021

Optimization feature which will replace certain Categorical and Histogram leaves with Select operations.

mhalk added 4 commits May 31, 2021 19:14
LoSPN Categorical leaves are lowered to SelectOp if they consist of two probabilities.
 - ADDED support for marginals when lowering from lospn to cpu
 - ADDED/FIXED support for log-computations
 - FIXED argument types of SPNSelectLeaf
@mhalk mhalk requested a review from sommerlukas June 28, 2021 11:47
@mhalk mhalk self-assigned this Jun 28, 2021
@mhalk mhalk added the enhancement New feature or request label Jun 28, 2021
Copy link
Member

@sommerlukas sommerlukas left a comment

Choose a reason for hiding this comment

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

Mostly looks good, but the lowering tests need improvement:

  • The tests should be more focused on the select and contain less other operations, so it is easier to identify the actual interesting part.
  • The tests should cover a scenario where the input type to the leaf is different from it's result type, e.g. taking i32 as input, but producing f64.

For the remaining nits, please see the inline comments.

mlir/lib/Conversion/LoSPNtoCPU/NodePatterns.cpp Outdated Show resolved Hide resolved
mlir/lib/Conversion/LoSPNtoCPU/NodePatterns.cpp Outdated Show resolved Hide resolved
op.supportMarginalAttr());
return success();
}
return failure();
Copy link
Member

Choose a reason for hiding this comment

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

If possible, provide a message on failure by returning rewriter.notifyMatchFailure(...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ACK, an explanation is now provided, regarding the rewrite conditions.

mlir/include/Dialect/LoSPN/LoSPNOps.h Show resolved Hide resolved
return success();
}
}
return failure();
Copy link
Member

Choose a reason for hiding this comment

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

If possible, provide a message on failure by returning rewriter.notifyMatchFailure(...)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

ACK, an explanation is now provided, regarding the rewrite conditions.

@mhalk
Copy link
Collaborator Author

mhalk commented Aug 2, 2021

Thanks for your review.

The tests should be more focused on the select and contain less other operations, so it is easier to identify the actual interesting part.

The tests are now very concentrated on these instructions, I think they are far better now (and far easier to understand).

The tests should cover a scenario where the input type to the leaf is different from it's result type, e.g. taking i32 as input, but producing f64.

I thought that would be covered by select-replacement-histogram.mlir
See lines L14 and L41, respectively.

@mhalk mhalk requested a review from sommerlukas August 2, 2021 13:04
Copy link
Member

@sommerlukas sommerlukas left a comment

Choose a reason for hiding this comment

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

Thanks for the update. I found one minor issue in the code, see inline comment.

Other than that, we should also make sure that the optimization is also covered by the Python tests that also check the result of the computation.

Please make sure that

  • not all Categorical or Histogram in the existing are replaced by the new optimization
  • for every configuration (vectorization, GPU, ...) at least one Categorical and Histogram is replaced and check that the result is computed correctly.

// Convert from floating-point input to integer value if necessary.
// This conversion is also possible in vectorized mode.
auto intVectorTy = VectorType::get(vectorType.getShape(), inputTy);
thresholdVec = rewriter.create<FPToSIOp>(op->getLoc(), thresholdVec, intVectorTy);
Copy link
Member

Choose a reason for hiding this comment

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

Why convert a constant value? thresholdVec is vector of constant values, so it should not be created as vector of floats and then converted, but rather should be created as a vector integers in the first place.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Absolutely right, it'll be fixed.

@mhalk
Copy link
Collaborator Author

mhalk commented Aug 2, 2021

Thanks for the update. I found one minor issue in the code, see inline comment.

Other than that, we should also make sure that the optimization is also covered by the Python tests that also check the result of the computation.

ACK.

Please make sure that

* not all Categorical or Histogram in the existing are replaced by the new optimization

* for every configuration (vectorization, GPU, ...) at least one Categorical and Histogram is replaced and check that the result is computed correctly.

But all "2 probability/bucket Categoricals/Histograms" should be replaced, right?
So "not all" means, there should be corresponding (Cat/Hist-)leaves in the SPN with a count != 2?
Shall I add new tests or adapt existing ones?

@sommerlukas
Copy link
Member

But all "2 probability/bucket Categoricals/Histograms" should be replaced, right?

Yes.

So "not all" means, there should be corresponding (Cat/Hist-)leaves in the SPN with a count != 2?

Correct, there should be Cat/Hist that are not eligible for the transformation.

Shall I add new tests or adapt existing ones?

Please adapt the existing ones, so they are not eligible for the transformation and add new tests for the transformation.

 - Now, they will not(!) be eligible for "select-transformation".
  (New tests will be added in the next commit.)
 - Added corresponding scalar and vectorized codegen
 - Adapted regression tests
 - Added Python computation tests
@csvtuda csvtuda mentioned this pull request Nov 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants