Jump to: navigation, search

NEWS: Since 2015, we moved all related developments, benchmarks, data sets and tools to our new Collective Knowledge Framework!


Development methodology

Developing any new research infrastructure is a challenging process since often one of the primary objectives of such frameworks is to quickly prototype multiple new and often high-level research ideas while focusing less on implementation. Typically, software is being developed in parallel with research and after several years it often becomes too complex, unmanageable, hardwired and undocumented that frequently leads to complete rewriting or abandoning such tools. To avoid such problems, we are developing a new generic, modular and unified infrastructure that enables collaborative and reproducible R&D, quick prototyping of ideas and sharing of knowledge. Though there is an associated start-up cost to design such a framework, we expect that later it will be easy to specialize it to various end-user scenarios such as application and architecture characterization and optimization.

Since developing such kind of infrastructure from scratch often requires very large teams and many years of work which we can't afford, we decided to use Agile software development methodology that we successfully applied to most of the cTuning tools and in the MILEPOST project. This methodology is very effective for new research projects that has to be completed with a very limited amount of time and manpower while conducting research, developing software and documenting best found variants at the same time to be able to quickly start up long-term R&D. Such methodology is also very common for goal-oriented research and development projects rather than process-oriented straightforward development projects.

When prototyping new ideas/concepts, we use the following methodology:


  • discuss high-level idea/concept;
  • discuss requirements and schedule;
  • agree on several possible implementation variants (unless implementation is straightforward);
  • quickly prototype various variants, test them and select the best working variant;
  • stabilize and clean up the final working variant, add tests, prepare developer specifications, demos and user guides;
  • prepare releases and obtain user feedback.

When extending existing framework or providing new relatively straight-forward features, we use the following methodology:


  • discuss high-level feature;
  • discuss requirements and schedule;
  • prepare/update specification on how to implement it;
  • implement and test it;
  • test the whole framework;
  • update specifications, demos and user-guides if needed;
  • prepare release and obtain user feedback.

Development conventions

cTuning3 framework enables collaborative R&D through modules (plugins) and distributed repositories. Plugins allow flexibility in development and coding conventions while focusing more on required high-level functionality. However, we still suggest to follow specific development and coding conventions to make cTuning3 and cTuning3-powered tools easily extensible by other users. If some code/text is not following conventions, you are very welcome to help us to update the code!

C example:

 * @brief   brief description
 * @param   parameters
 * @param   parameters
 * @todo:   ToDo notes
 * @return  return parameters  

Python example:

brief description
Input:  input parameters
Output: output parameters

  • cTuning3 generally follows GNU Coding Standards (, though the first focus is on functionality and research.
  • cTuning3 should NOT HAVE TABS in the sources, but SPACES.

  • We use "_" and not "-" in the names of the files.

  • The end of line should always be \n.

  • We suggest to use one space indent in sources.

  • We should not hardwire constants that can be user/environment-dependent inside the code. Instead we move them to configuration files or to configuration arrays.

  • When visualizing something in format "X:Z", we should have a space after : and not before, i.e. X: Z.
  • When visualizing something in format "X=Z", we should not have spaces before and after = or should have both spaces, i.e. X=Z or X = Z.

  • We use lower-case for:
    • data/module aliases
    • names of parameters in json files
    • names of commands in modules
  • We use upper-case for:
    • types of parameters ("URL", "MODULE_UID", etc)

  • In C, we suggest to add void in function declarations if there are no parameters:
int function(void);

Testing methodology

cTuning2 core and each module should normally have a "self-test" function to test itself using some standard inputs and outputs. Developers and users are welcome to add gradually more tests.


  1. Agile Software Development
Locations of visitors to this page