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

Utilization derived metric #101

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

johntran-nv
Copy link
Contributor

No description provided.

@github-actions
Copy link

github-actions bot commented Feb 14, 2022

MLCommons CLA bot All contributors have signed the MLCommons CLA ✍️ ✅

@johntran-nv
Copy link
Contributor Author

@petermattson , what do you think of this?

@tjablin
Copy link
Collaborator

tjablin commented Feb 14, 2022

  • peak_system_tensor_flops_per_second means the peak tensor operations of the hardware, counting only tensor math throughput and not additional vector or pointwise math datapaths.

I think peak_system_tensor_flops_per_second is well-defined for architectures like NVIDIA GPUs and Google TPUs, but is not well-defined for CPUs, DSPs, or FPGAs. Furthermore, it is possible that some architectures may allow overlapping tensor and vector math operations such to achieve greater than 100% throughput.

Comparing utilization for different software implementations for fixed hardware seems useful, but utilization comparisons between different hardware seems meaningless. I guess the intention is to promote utilization as a conversion factor between FLOPS and actual performance, but I think we should try to promote comparisons based on performance directly and not try to fix FLOPS.

Given the experience in MLPerf Inference with NIC to accelerator bandwidth, I would prefer not to involve numbers in MLPerf that cannot be measured directly. I don't want to adjudicate complaints that someone is not calculating the peak tensor operations of their hardware correctly, and I also don't want to get into the business of measuring FLOPS.

The model_tensor_flops term seems like a pain to compute with many possible edge cases and room for disagreements. If this is proposal is accepted, I would prefer that MLCommons provide an official model_tensor_flops for each model rather than allowing submitters to calculate their own.

The definition of model_tensor_flops implies that there is a single unambiguous number of operations required by a given model, but its unclear how to count required operations when an implementation may choose a sub-cubic dot implementation. How are model_tensor_flops counted for sparse operations?

@petermattson
Copy link
Contributor

petermattson commented Feb 21, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants