search

LLNL / apollo

Apollo: Online Machine Learning for Performance Portability
Other
22 stars 9 forks source link

[mpi/opencv] Allow user supplied "results" for trials #2

Closed DavidPoliakoff closed 4 years ago

DavidPoliakoff commented 4 years ago

I think this one would be pretty easy. Just add an "end" method to region that takes in a float/double. Instead of using the time the region took, use that float. It should be a user error if they call end with a value one time and not another in a Region.

cdwdirect commented 4 years ago

This is a good feature request and will be added to Apollo.

Dump of related text from Slack chat:

It occurred to me during the call David that allowing an alternative end method with a float param allows a developer to establish their own objective function for Apollo. 5:00 Basically Apollo is applying the min function to execution time by default, but if you plug in your own weight value as that float for some objective instead of time, Apollo will seek min for that value and converge its recommendation towards it for some set of features you've provided, without any new programming in Apollo. 5:02 Could be a useful little hack for application-level parameter selection, in addition to facilitating synthetic apps expressing an arbitrary exec time without needing to actually sleep that long so that Apollo records that arbitrary time. 5:06 Apollo would just track the float you provide as if it were the execution time, so 0.0 is the ideal recommendation you want Apollo to be making, and then larger values would represent varying distances from ideal, according to your user-defined concept of that. Bonus, you can use Apollo in both ways at the same time, and have multiple custom objectives, since each Region is tracked independently.

An example of a user-defined objective function where you could utilize the reg->end(custom_weight) trick might be something like plugging in the result of a function f(E,T) that multiplied E measure of error by T amount of time some granularity of massless particles in a flow took to process for Lagrangian flow analysis... so Apollo could help an application converge on the ideal amount of particles to track in order to minimize both error and evaluation time in some balance. The function f(E,T) could be as complex and internally-weighted as someone wanted it to be to properly express something like what I mention here, but the idea is that Apollo (even as simple as it is presently constructed) could get you there.