Skip to content

Latest commit

 

History

History
70 lines (64 loc) · 3.29 KB

TODO.md

File metadata and controls

70 lines (64 loc) · 3.29 KB
Raw

TODOs

  1. Support for (de)serialization of resuls, spec,s etc. to json. Running of same.

  2. Clang cross-compiler support

    1. See clang-cross-compile branch for progress.
    2. Seems to probably work but can't compiler libcfiddle because of header issue.
    3. cfiddle.make could be made less gcc-centric. The variables are a mess.

  3. Support for remote exection (based on 5)

  4. Error reporting on perf counters

    1. Not available
    2. Incompatable set of counters.

  5. Documentation

    1. Add change log to README.md
    2. Add devel instructions to README.md
    3. Update cross refs in docstrings.

  6. Multiple workflow support (mostly runners)

    1. Install relevante inspectors on Executables
    2. Encapsulate a configuration in a Workflow object. (One for C, one for Rust, remote execution, etc.)
    3. from cfiddle import * would pull in the default.

  7. Support for Rust

    1. Use the FFI interfaces in each language to get access to libcfiddle.
    2. Extend the makefile.

  8. Turn on debug for all tests

  9. Cleanup full_flow_tests

    1. Parameterize them across toolchains.
    2. Expand full flow to also run code analysis tools.

  10. Build per-base class tests for derived classes

    1. Builder
    2. Runner
    3. Toolchain

  11. cleanup cfg code. it's a mess.

  12. Integrate moneta

  13. fancy code/assembly/cfg highlighting like it compiler explorer. Can we do it just using CSS?

  14. Move src/cfiddle/resources to the root src/ directory

  15. Create language abstraction. 1. get rid of util.infer_language

  16. Executable-based execution (rather than .so)

    1. It'd be usef to be able to run programs at the command line
      1. e.g. to use gdb to interact with debug information while enhancing DebugINfo
    2. Auto-generate code from python.
      1. Build generic C++ library with at template function that can execute use << to deserialize arguments passed on the cmdline.
      2. ExeRunner should build an executable and attach it to the Executable object and reuse it later.
      3. Or maybe there should be an ExeBuilder that just builds the executable outright.
      4. Just do one invocation per process
      5. Statically link so gprof will work.
      6. I think the .so things is a bad idea. We'll see how much slower executables are.
      7. There was maybe some benefit in the shared state via libcfiddle, but I don't think it's bidirectional.
      8. It would make collecting stdout/stderr and providing stdin possible and easy.

  17. MacOS support 11. Clang support (done) 12. dylib suppport

  18. Windows support

  19. Generalized measurement mechanism of which perf counters would be a special case.

    1. Measure IO

  20. Use run() to check characteristics of execution envirnoment

    1. E.g. for remote execution, run a program to find the list of perf counters. If you run it in on the execution environment, you'll get the currently-/workload-correct answer.

  21. Automatically run a test several times and generate average/stdev etc. Then automatically draw error bars

Notes on CAP_PERFMON

  1. It's enable in these binaries: https://master.dockerproject.org/ as of 1/18/2022
  2. But it doesn't actually work:
    1. docker run --cap-add PERFMON -it -w /home/jovyan/cfiddle/tests stevenjswanson/cfiddle:devel pytest test_PerfCounter.py
    2. can't read counters
    3. moby/moby#43163