On 05/29/2015 05:55 PM, Andi Kleen wrote:
> Martin Liška writes:
>>
>> Following patch sums samples that belong to a line in assembly language.
>> What do you think about it, would it be acceptable solution?
>
> Basic patch looks good to me now. Thanks.
>
> The only ugly thing is the global vari
Martin Liška writes:
>
> Following patch sums samples that belong to a line in assembly language.
> What do you think about it, would it be acceptable solution?
Basic patch looks good to me now. Thanks.
The only ugly thing is the global variable, perhaps that could be
cleaned up.
-Andi
--
a..
On 05/27/2015 04:04 PM, Andi Kleen wrote:
If I understand correctly, is it just about division of the number of events
related to an instruction and total number of events?
Yes that's it. The information is already displayed in the main view
(or more fine grained if you do --sort ...,srcline; u
> If I understand correctly, is it just about division of the number of events
> related to an instruction and total number of events?
Yes that's it. The information is already displayed in the main view
(or more fine grained if you do --sort ...,srcline; unfortunately not
sorted in this case)
-A
On 05/27/2015 10:46 AM, Martin Liška wrote:
On 05/26/2015 07:03 PM, Andi Kleen wrote:
Anyway, attached patch is capable of displaying milliseconds approximation for
each instruction.
You realize that the events perf is not counting do not directly map to
wall time? Even if you count cycles, t
On 05/26/2015 07:03 PM, Andi Kleen wrote:
Anyway, attached patch is capable of displaying milliseconds approximation for
each instruction.
You realize that the events perf is not counting do not directly map to
wall time? Even if you count cycles, the cycles are either stopping in idle
or chan
> Anyway, attached patch is capable of displaying milliseconds approximation
> for each instruction.
You realize that the events perf is not counting do not directly map to
wall time? Even if you count cycles, the cycles are either stopping in idle
or changing unit as the CPU's frequencies change
On 05/25/2015 05:14 PM, Andi Kleen wrote:
perf diff does not handle this? Especially with the differential
profiling options it should.
It does not work if you, in my case, compare ICC and GCC, where ICC uses a
different mangling
scheme for fortran modules. Moreover, situation can be more comp
> >perf diff does not handle this? Especially with the differential
> >profiling options it should.
>
> It does not work if you, in my case, compare ICC and GCC, where ICC uses a
> different mangling
> scheme for fortran modules. Moreover, situation can be more complicated if a
> compiler perfor
On 05/23/2015 06:08 AM, Andi Kleen wrote:
Martin Liška writes:
I've been working on a new feature for perf annotate, which should be able to
annotate
instructions with total spent time (compared to percentage usage).
Let's consider following use-case. You want to compare two different compil
Martin Liška writes:
> I've been working on a new feature for perf annotate, which should be able to
> annotate
> instructions with total spent time (compared to percentage usage).
>
> Let's consider following use-case. You want to compare two different compilers
> on the same code base and let'
Hello.
I've been working on a new feature for perf annotate, which should be able to
annotate
instructions with total spent time (compared to percentage usage).
Let's consider following use-case. You want to compare two different compilers
on the same code base and let's assume 90% of wall-time
12 matches
Mail list logo