Re: Floating point in pango

[Soeren Sandmann <sandmann daimi au dk>]

Richard Purdie <richard openedhand com> writes:

> > These things together led to sysprof being the way it is. Most of the
> > oprofile features are _useless_ given the design criteria above, and
> > most of the features _actually_ needed are just not there in oprofile.
> 
> So basically sysprof concentrated on the frontend and I agree it did
> well with it. It just lacks the backend and infrastructure.

No, sysprof concentrated on answering the question

        "What would it take to get GNOME people to do useful profiling
        of their software?"

To answer that question, it turned out that the necessary kernel
support was less than 300 lines of code, most of which is boilerplate,
and that all the hard work was in the userspace part. *If* it had
turned out that a huge complicated profiling subsystem was required to
answer the question, I would have looked at using oprofile. But it
wasn't. The backend and infrastructure that you think sysprof lacks
are simply not necessary given sysprof's design criteria.

To make it work with oprofile would have meant

        1. Figure out why oprofile didn't work at all on my system

        2. Recompile kernel to add stack trace support

        3. Find out how oprofile kernel module works

        4. Patch oprofile module to add necessary features

        5. Write complicated userspace code to deal with arcane
           oprofile interface

vs.

        1. Write simple kernel module that did what I needed.

It didn't (and doesn't) make any sense technically to use oprofile as
the "backend" for sysprof. For what sysprof is doing, oprofile is
totally overengineered.

> oprofile lacks a GUI and my original email said as much but it does have
> a solid infrastructure behind it.
> 
> There is a logical conclusion here, change sysprof to be a graphical
> frontend to oprofile. 

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.

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.

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.


Soren