Overview
Topic status: We're looking for students to study this topic.
Multi-core processors are now common place and the number of cores is expected to continue to increase exponentially. Unlike with previous processor improvements, compilers are generally unable to automatically exploit this parallel hardware. Parallel programming has long belonged to the specialized realm of high performance computing but is now a mainstream challenge; set to have a major impact on the software development industry. Parallelizing programs currently requires considerable specialized knowledge and skill, is time consuming and error prone. We need to develop better ways of expressing and analysing programs to make it easier to safely exploit parallel hardware.
Any kind of static program analysis is always going to be conservative - it will assume more data dependences than actually exist and consequentially find less parallelism than actually exists. At runtime, however, we know exactly which memory locations are read and written, allowing us to infer dependences and reason about parallelism. The dependences may of course vary depending on the input data, so runtime analysis will give us a lower bound on the actual data dependences and an up bound on available parallelism. It may of course be possible for the programmer to restructure their programs toexpose more inherent parallelism. The goal then is to create a kind of parallel programmer's workbench (integrated into say Visual Studio or Eclipse) where control and data dependences detected at runtime are presented to the programmer in a visual manner and allow them torefactor and parallelize their code based on this information.
Hypothesis
That dynamic tracing of data and control dependencies can help programmers understand and correctly parallelize their applications
Approaches
There are two parts to the project - the first involves instrumenting the code to dynamically gather the data and control dependences. For .NET code we can do this (for example) by altering the Mono JIT compiler. For native code we can use an Intel instrumentation tool called PIN. The second part of the project involves presenting the data to the user in an IDE such as Visual Studio or Eclipse. Both IDEs provide extensibility frameworks to support this kind of custom plug-in.
References
- Study level
- PhD
- Supervisors
- QUT
- Organisational unit
Science and Engineering Faculty
- Research area
- Contact
- Please contact the supervisor.
Dr Wayne Kelly
