Re: Floating point in pango

[Eero Tamminen <ext-eero tamminen nokia com>]

Hi,

ext Soeren Sandmann wrote:
> So, if sysprof was changed to be a "graphical frontend to oprofile",
> what differences would users see? Because there is *no* way I am going
> to add options for stuff like "L1-misses" or "Enable perfcounter 3000
> (Intel UltraARM IV only)" or whatever other gobbledigook oprofile
> supports.
>
> Maybe this is the crux of the difference: I would consider sysprof to
> be a *worse* program if it had a checkbox to support, say, counting
> branch mispredications. Such a checkbox would not do enough to help
> solving the problem that sysprof tries to solve, to be worth it.

Assuming that somebody would like to make Sysprof as a GUI for Oprofile
doesn't necessarily mean that it would need support all or even most of
its features.

There could be a separate UI for the pros who need to understand
better why something is slow instead of just knowing what is slow.


> I don't think the oprofile people would agree with me on that, and
> that's part of the reason I am not enthusiastic about porting sysprof
> to use the oprofile module.
>
>
> For the specific problem of profiling on ARM, there is another logical
> conclusion: Just add ARM support to sysprof and be done with
> it. Sysprof works, and that's what matters. All the talk about
> foundations and infrastructure is a just red hering.

Well, the:
  "Enable perfcounter 3000 (Intel UltraARM IV only)"

Could be the only way to get *reliable* performance data on
some platform whereas some more common method might be useful
just for locating the main bottlenecks.

It's also important to get performance data with different
methods so that:
- You can verify your results
- You can see different bottlenecks
(profiling affects the profiled system, so I'll never fully
trust the results.)


> The sysprof code, both userspace and kernelspace, is *good* code by
> any standard. It is the way it is as a result of a *deliberate*
> decision to focus on solving one specific problem and solving it
> well.

Personally I would like to get as much data as possible if it is proven
to be reliable, but in many cases its more important to get to the main
bottlenecks with as little fuzz as possible.  And in the beginning too
much data can distract from pinpointing the major bottlenecks.

However, once the easily identifiable bottlenecks have been identified
and fixed, you need more data.


	- Eero