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

Disable fused multiply-subtract optimizations on activator calculations #8341

Merged
merged 1 commit into from
Jun 16, 2020

Conversation

mundaym
Copy link
Contributor

@mundaym mundaym commented Jun 16, 2020

Fixes TestAutoscalerPanicModeExponentialTrackAndStablize on arm64, ppc64le and s390x. These platforms aren't currently supported by Knative but it can be built from source on them and fixing this test will help any future porting efforts smoother. This is especially true since it is the only unit test that appears to fail on these platforms.

This change won't affect amd64 at all, except when using a compiler that supports fused multiply-subtract operations (e.g. gccgo or gollvm with -Ofast).

Ideally we'd make the tests and/or calculations more tolerant of minor variations in the output of individual floating point operations. Here the test failure is caused by a tiny numerical difference that is magnified by rounding down: math.Floor(330.999...) vs. math.Floor(331.000...). I'm not certain of the best way to do that though and it would certainly be a much larger and more invasive change.

Thanks for taking a look!

Fixes TestAutoscalerPanicModeExponentialTrackAndStablize on arm64,
ppc64le and s390x.

While we are here make the order of operations match between the
expectedECB and excessBCF calculations. Floating point operations
aren't associative so performing them in the same order reduces
the risk of unexpected differences.

Background:

On some platforms (not amd64 - unless using a compiler other than
gc) the Go compiler 'fuses' some floating point operations. This
improves performance and sometimes accuracy. However this can
cause issues with test data that has been generated on a platform
without such fused operations (such as amd64) or has been constant
folded. A simplified example of the problem (values changed):

  Without fused multiply-subtract: 1.333... * 3 - 2 = 2.000...
  With fused multiply-subtract:    1.333... * 3 - 2 = 1.999...

This commit disables fused multiply-subtract operations in all
excess burst capacity calculations. This ensures that the
calculations match across all platforms and in situations where
constant folding takes place.
@googlebot googlebot added the cla: yes Indicates the PR's author has signed the CLA. label Jun 16, 2020
@knative-prow-robot knative-prow-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Jun 16, 2020
@knative-prow-robot
Copy link
Contributor

Welcome @mundaym! It looks like this is your first PR to knative/serving 🎉

@knative-prow-robot
Copy link
Contributor

Hi @mundaym. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@knative-prow-robot knative-prow-robot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jun 16, 2020
@mundaym
Copy link
Contributor Author

mundaym commented Jun 16, 2020

/assign @vagababov

@markusthoemmes
Copy link
Contributor

/ok-to-test

@knative-prow-robot knative-prow-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Jun 16, 2020
@vagababov
Copy link
Contributor

Since I am unaware of platform specifics and I am curious :), would you care to explain what is not working on those platforms?

@vagababov
Copy link
Contributor

I can deal with approximations in the tests.

Copy link
Contributor

@vagababov vagababov left a comment

Choose a reason for hiding this comment

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

Ah, it's in the comment.
/lgtm
/approve

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 16, 2020
@knative-prow-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mundaym, vagababov

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 16, 2020
@knative-prow-robot knative-prow-robot merged commit 2b325ca into knative:master Jun 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/autoscale cla: yes Indicates the PR's author has signed the CLA. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants