benroywillis
commented
3 years ago Right now we are working on a submission for the new developments. I'll send you a link to the archived paper when it is submitted (right now we plan on making this submission in about 4 weeks).
For integration with CEDR, the short answer is yes, that is the plan. Currently we are doing this with two general approaches, a software API based approach and an Ontology-based approach.
The API approach aims to structure programs using a C-like API. The user can trivially swap its kernel calls with a suitable Dash API call (for exampe a gsl FFT or FFTW FFT can just be swapped with the Dash FFT). It is more straightforward than the ontology approach and can help CEDR and their users address implementation issues that don't have to do with ontology/software integration and gets things working now.
The ontology approach aims to structure the input program into a task graph. This task graph has tasks as nodes and producer-consumer relationships as directed edges, where the edge points from producer to consumer (John presented on this and had figures representing task graphs in our QPR12 slides). This requires that we both segment the program into its tasks and evaluate producer-consumer relationships between tasks, which are roughly done by the cartographer and dag extractor, respectively. Currently we do not have a dag extractor for the new version of the tools. This tool will be released with the new updates to TraceAtlas in the pending pull request (probably about 3 more weeks).
Please let me know if you have any more questions and I'll send you the link to our archived submission when it's available.
Hi, Is there additional documentation on the methodology of the new trace atlas implementation? Perhaps a paper?
It would be nice to understand how the tool is going to be used in the flow. Is it still the intention that there will be a dag extractor and that will be ingested by CEDR? Thanks.