search

codes-org / codes

The Co-Design of Exascale Storage Architectures (CODES) simulation framework builds upon the ROSS parallel discrete event simulation engine to provide high-performance simulation utilities and models for building scalable distributed systems simulations
Other
40 stars 16 forks source link

codes-workload API for user-defined workload generation (Imported #74) #74

Closed nmcglo closed 5 years ago

nmcglo commented 8 years ago

Original Issue Author: Jonathan Jenkins Original Issue ID: 74 Original Issue URL: https://xgitlab.cels.anl.gov/codes/codes/issues/74

Right now, for network workloads we basically have to use a trace (for IO we have a synthetic language, but it's crusty...). For simple benchmarks we could just roll our own.

The goal here is to provide a non-internal codes-workload plugin that users can provide function pointers to. You could imagine implementing a simple nearest-neighbor benchmark this way, among other things.

Really, the interface for providing codes-workload implementations should be user-visible and added to at runtime, but that might be more work... I'll probably take the path of least resistance for expedience.

nmcglo commented 8 years ago

Jonathan Jenkins:

I see, so you want a ROSS model (implemented using codes) to be able to define its own generator without modifying codes-base.

Would it be easier to just to add some publicly visible API hooks that let a caller dynamically add a new module to the existing API?

The current code has a static array of modules that is constructed at compile time, but it seems like it wouldn't be a big deal to add a linked list of dynamically registered modules that we search in addition to the static array.

nmcglo commented 8 years ago

Jonathan Jenkins:

It does. However, if I as a user wanted to, say, hack up a quick nearest-neighbor comm workload for use in the MPI workload processor, I would need to embed it into CODES internally and rebuild.

What I'd like to do instead is be able to register an implementation at runtime, so that I don't need to reach into the CODES source files, which isn't possible with the current setup.

nmcglo commented 8 years ago

Jonathan Jenkins:

Status changed to closed

nmcglo commented 8 years ago

Jonathan Jenkins:

Doesn't the existing API have function pointers already to let you change which module is used?

nmcglo commented 8 years ago

Jonathan Jenkins:

Yeah, that's what I'm proposing. Not sure if there are any gotcha's in simply appending to that array (usage of globals in various places and such).

nmcglo commented 8 years ago

Jonathan Jenkins:

Thankfully, there weren't any gotchas, just some slight changes to how things get initialized.