No, it is not. It's O(N+M) where M is the largest value in the list. And, notably, it can fail if the time to schedule the jobs takes longer than the smallest difference between elements in the list
No, it is not. It's O(N+M) where M is the largest value in the list. And, notably, it can fail if the time to schedule the jobs takes longer than the smallest difference between elements in the list
Given there's n timers and O(1) operations I'm not sure where the O(n log n) fits in here. Possible in the minimum number of ticks?
http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing...
Production implementation: https://github.com/facebook/folly/blob/master/folly/io/async...
> If we can guarantee that all timers are set for periods less than MaxInterval, this modified algorithm takes O(1) latency for START_TIMER, STOP_TIMER, and PER_TICK_BOOKKEEPING.
I think that puts this in the same class as counting sort.
> Bonkers, brilliant and definitely NSFW.
Edit:
Why divide by m, when you can divide by M*C. Where C will speed this portion up by a factor!
You can find the largest element in a list in O(1) time with n^2 processors[0]*.
Division of the list by that number is O(1) with n processors
Therefore the operation is O(1)
[0]* on a CRCW PRAM https://www.cpp.edu/~gsyoung/CS535/CS535Notes/Part2PRAM.pdf#...