Greg Bronevetsky

Ideas

  • Empirically Identifying Application Noise-Sensitivity Profiles
    Large-scale applications are typically sensitive to timing noise caused by OS daemons, network contention, etc. While people have studied this phenomenon and developed techniques to reduce the amount of noise in their systems, thus far application developers have not had tools to help them reduce their application's sensitivity to noise. We can create a very useful tool by employing fault injection to inject variable amounts of timing noise into various parts of an application while it is executing. By observing the effect of these injections on the application's performance we can determine the parts of the application that are more or less sensitive to noise, allowing developers to focus their efforts on the parts of the application that are most critical.
  • Neutron Beam-Accuracy High-Level Soft Error Profiles
    Today the only way to get highly-accurate system fault vulnerability profiles is to expose the system to a close approximation of its operating environment. In the case of soft errors this means that systems must be exposed to neutron beams. This is obviously cumbersome and expensive. I'd like to make this significantly cheaper by creating a gate-level fault injector that simulates the effect of a neutron beam on a given piece of hardware while only performing a single round of neutron beam experiments to initialize the simulator. The idea is to create a suite of microbenchmarks and run then on both (i) the simulator while performing low-level fault injection and (ii) the real hardware while it is exposed to a neutron beam. The results of the two experiments can be correlated to determine the exact rate at which we should inject faults into various simulated system components to replicate the results achieved in the neutron beam experiments. From them on the simulator can to accurately evaluate the fault vulnerability of arbitrary applications without the need for any more neutron beam tests.
  • Compile-time Analysis of Explicitly Parallel Applications
    Today compilers provide little support for analyzing and optimizing explicitly parallel applications. I've been working on an extension to the traditional dataflow analysis framework hat is sensitive to the communication structure and does not depend on the knowledge of the processor count.
  • Performance Analysis tools for Dataflow Applications
    I am currently working on understanding the performance properties of the IBM Streams coarse-grained dataflow system. As I've been getting deeper into this project I've observed that it is generally rather complicated to understand how your dataflow application is behaving, where the bottlenecks are and how they are spreading. However, there appears to be little work on helping developers of such applications to identify and fix such problems. I'm currently working on automated tools to identify streams that are being over- or under-utilized and how the rest of the application is affected by such phenomena. I am hoping to take this work to develop a good way to visualize the performance properties of such applications to highlight for developers key trouble spots and show them the effects these problems are having on overall application performance.