> That is why CPU ISAs provide a timer that increments at a constant rate
> (fixed frequency). It is not bound to the core's clock frequency. If the
> core's frequency adjusts dynamically you can no longer use cycle counter
> to measure time. If the core's frequency is fixed, it's still not
>
On 02/14 14:17:04, Bill Fischofer wrote:
> I thought Petri's arguments this morning were articulate.
Agreed. That is part of why I put such things into a shared document.
> From a
> performance tuning standpoint cycle count provides a time-independent
> means of measuring algorithmic efficiency
I thought Petri's arguments this morning were articulate. From a
performance tuning standpoint cycle count provides a time-independent
means of measuring algorithmic efficiency since the number of cycles
is simply a function of the ISA and compiler optimization level rather
than the specific CPU
if cpu goes for some small time to turbo mode then what you will measure
with timer?
btw, is cpu timers have only single propose - to measure functions time?
Maybe we need some tracing functionality for that case? Not just api for
current counters?
Maxim.
On 14 February 2017 at 22:37, Francois
Thanks for taking the lead ;-)
I fully agree on deprecating cpu cycles API in ODP. Better use a true PMU
profiling API: we will not be able to upstream a special driver and if we
have to spend engineering resources, better off on ODP itself.
FF
On 14 February 2017 at 19:37, Brian Brooks
On today's call, it became clear to me that some users are extremely
interested in measuring cycles. Since this is not as simple as it
sounds, I started documenting...
https://docs.google.com/a/linaro.org/document/d/1sY7rOxqCNu-bMqjBiT5_keAIohrX1ZW-eL0oGLAQ4OM/edit?usp=sharing
Please have a
