GSoC in need of a mentor: Performance tools, study and optimisation of GEGL
GSoC in need of a mentor.
I'm a master's student at UPC (Universitat Politècnica de catalunya,
Barcelona, Spain) and I would like to do this project on GEGL. I would
need a mentor for it. The mentor doesn't need to be an expert in
performance tools / performance counters as I have unofficial support
for that already from the university as well as some experience.
Thanks,
Henrik
Description of project:
----------------------------------------------------------------
"Performance tools, study and optimisation of GEGL."
a) Creating a multi-platform performance tool-set for automatically
extracting performance data from the gegl library using performance
counters
b) Creating a set of typical scenarios for gegl, which could double as
integration/regression tests
c) Reporting on current status of gegl performance.
d) Identification of main bottlenecks
e) Documenting above tools.
f) Prototyping or implementing solution for above bottlenecks. (optional)
Elaboration of point a), tools used:
1 - OProfile (as it is better documented and than sysprof and runs on
more platforms/processors) for system-wide profiling i.e. finding
_where_ the time is spent.
2 - PAPI instrumentation of the code for finding out _what_ it is
doing that takes time.
3 - Ruby script for extracting a html report that is reasonably easy
to understand (performance counters can be quite difficult to
understand). The ruby script would use graphviz, gnuplot etc for
generating suitable output.
Step 2 could possibly be automated using the output from step 1, but I
might be aiming a bit too high here.
I further propose 3 scenarios:
1 - automatic performance report (make profile?) using a set of
performance cases
2 - targeted performance report on operations.
3 - memory management profiling - for reporting on ram usage and disk
usage and swapping (this might require other tools than OProfile/PAPI
and it might again be aiming too high).
The tool would only function with command-line based applications,
that are not using any interactive input.
As a matter of discipline, all profiling-runs should be written as
tests and would therefore also guarantee the correct output of
optimised operations.
