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

CPU crunching for more realistic algorithm #24

Merged
merged 7 commits into from
Jul 17, 2024
Merged

Conversation

joott
Copy link
Collaborator

@joott joott commented Jul 12, 2024

BEGINRELEASENOTES

  • MockupAlgorithm now finds prime numbers instead of just sleeping
  • Each worker calibrated once before any graphs scheduled (in examples/schedule.jl)
  • Based on calibration, number of primes picked according to graph average runtime

ENDRELEASENOTES

joott added 3 commits July 12, 2024 15:28
Function to find the nth prime number with helpers for worker
calibration
Calibration coefficient is stored on each worker and used to crunch for
average runtime using prime number finder
@m-fila m-fila self-requested a review July 12, 2024 15:47
Copy link
Collaborator

@m-fila m-fila left a comment

Choose a reason for hiding this comment

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

Looks good 👍
I'm not sure if linear calibration with a single coefficient is always a good approximation since the density of primes is not constant. Maybe we could check how does the time vs number of iterations looks like and maybe replace single coefficient with a list and do some linear or polynomial approximation. We'd need to know a typical range of algorithm execution times - we could calculate it from ATLAS example. This'd require some more work, so I'd rather stay here with basic mechanism and if needed revise in another PR

src/algorithm.jl Outdated Show resolved Hide resolved
src/FrameworkDemo.jl Outdated Show resolved Hide resolved
joott added 4 commits July 16, 2024 13:41
It uses an more naive approach that is not dependent on the density of
primes
Calibration now involves two parameters instead of one
Copy link
Collaborator

@m-fila m-fila left a comment

Choose a reason for hiding this comment

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

The values in 1ms - 20s range seem to have a $\pm$ 15% error, which should be enough. It could be interesting to add a separate benchmark for the n_max vs time/error

@m-fila m-fila merged commit afcc5b3 into key4hep:main Jul 17, 2024
2 checks passed
@joott joott deleted the crunching branch July 23, 2024 09:08
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.

2 participants