Difference between revisions of "Performance Evaluation and Optimization"

From Nsnam
Jump to: navigation, search
Line 1: Line 1:
 
Our goal here is to improve the performance of our simulation core and of our models, both from a cpu and a memory perspective. Since this is a very broad project, interested students will have to start by defining better the scope of what they would like to achieve.  
 
Our goal here is to improve the performance of our simulation core and of our models, both from a cpu and a memory perspective. Since this is a very broad project, interested students will have to start by defining better the scope of what they would like to achieve.  
 +
 +
There are lots of components of the simulator which could benefit from careful optimizations:
 +
* some of the core parts, most likely the event scheduler (see the directory src/simulator/)
 +
* some of the models
 +
 +
While it would be nice to work on the models, focusing the core components of the simulator would be much more useful because it will benefit many more users. Some potential projects related to the event scheduler:
 +
* implement and carefully optimize a so-called Calendar Queue (R. Brown. Calendar Queues: A Fast O(1) Priority Queue Implementation for the Simulation Event Set Problem. Communications of the ACM (CACM), volume 31, number 10, pages 1220--1227, October 1988.).
 +
* implement a "Dynamic Calendar Queue" event scheduler. The reference paper is: JongSuk Ahn, SeungHyun Oh, "Dynamic Calendar Queue," ss, p. 20, Thirty-Second Annual Simulation Symposium, 1999.
 +
Both of the above projects will require that the candidate implement a new subclass of the src/simulator/scheduler.h base class. Testing of the new subclass will be done by instantiating the new CalendarQueueScheduler and calling Simulator::SetScheduler before scheduling any event.
 +
  
 
We expect, however, all proposals to be based on the following workflow:
 
We expect, however, all proposals to be based on the following workflow:

Revision as of 16:24, 27 March 2008

Our goal here is to improve the performance of our simulation core and of our models, both from a cpu and a memory perspective. Since this is a very broad project, interested students will have to start by defining better the scope of what they would like to achieve.

There are lots of components of the simulator which could benefit from careful optimizations:

  • some of the core parts, most likely the event scheduler (see the directory src/simulator/)
  • some of the models

While it would be nice to work on the models, focusing the core components of the simulator would be much more useful because it will benefit many more users. Some potential projects related to the event scheduler:

  • implement and carefully optimize a so-called Calendar Queue (R. Brown. Calendar Queues: A Fast O(1) Priority Queue Implementation for the Simulation Event Set Problem. Communications of the ACM (CACM), volume 31, number 10, pages 1220--1227, October 1988.).
  • implement a "Dynamic Calendar Queue" event scheduler. The reference paper is: JongSuk Ahn, SeungHyun Oh, "Dynamic Calendar Queue," ss, p. 20, Thirty-Second Annual Simulation Symposium, 1999.

Both of the above projects will require that the candidate implement a new subclass of the src/simulator/scheduler.h base class. Testing of the new subclass will be done by instantiating the new CalendarQueueScheduler and calling Simulator::SetScheduler before scheduling any event.


We expect, however, all proposals to be based on the following workflow:

  • define reference application-level scenarios and establish reference benchmarks for them
  • perform cpu and memory profiling of the reference scenarios. Observe hotspots, explain the hotspots.
  • propose and implement a solution to decrease the impact of the observed hotspots.
  • re-run reference scenarios: if no improvement, hotspot explanation or implementation are most likely buggy. Understand why proposed solution did not improve things. If improvement, go back to profiling.

Typical profiling tools on linux include:

  • oprofile
  • sysprof
  • gprof
  • valgrind/kcachegrind

A good proposal will most likely integrate results from very early reference scenario definition, profiling, and hotspot explaination. i.e. it should contain a simple rough first iteration of the above workflow.