Running development work-items task list

[gapisback]

This discussion item is simply a placeholder dumping ground to note down open development work-items, mainly in my head. Am putting this down to externalize this thinking / list so that we can collaborate on prioritizing and scheduling these work items with input from @gregthelaw

Development Items

1. Refactor test.sh as requested by discussion item #19. Done @sha 6f051b8.

2. Restabilize standalone L3 package, and L3+LOC integration on MacOSX. This may need multiple iterations and a continual watch, driven by manual CI/QA, to ensure that Mac support continues to work. Stabilization on Mac will be greatly simplified once we do (1), as then developer can use test.sh to re-run all builds-and-tests on Mac, with one easy command invocation. [Status: In review PR#27 . Merged under SHA 3659c77]

3. Support clang compiler for all builds: Both on Linux and Mac. Status: Subsumed automatically by (2) as on Mac/OSX gcc defaults to clang. But builds fail on Linux with clang. See in-flight changes in dev-branch gapisback/l3-unpack-loghdr-clang

4. Add CI support for clang compiler for all builds-and-tests [ Status: Done as part of (3). ]

5. Develop pytest tests for cross-checking results from L3+LOC logging and results unpacked by l3_dump.py. [ Status: Submitted for review PR [Pytest] Add pytests to verify decoding by l3_dump.py, including LOC-decoding. #30. Checked-in under SHA 637f928 ]

6. Develop LOC-ELF decoding of LOC-IDs captured in log-files. Do this either by using readelf in l3_dump.py. Or develop a standalone loc_elf decoder binary to do this work, implementing ELF APIs to unpack .rodata contents etc.

• Status: (3.May.2024) Developed ELF-library based standalone in dev-branch gapisback/decode-loc-elf-section. Works well, but only on Linux. Need to port entire approach for Mac/OSX to use Mach-O libraries. Revisit.

7. Decode L3 messages using Python interface to invoke C-style printf(). This way, we will get fully formatted formed messages, with arguments replacing print-format specifiers.

8. Support storing and unpacking of multiple arguments, initially restricting to 2 uint64 arguments. In theory we should be able to support any combination of [u]int32, [u]int64 arguments as long as the payload does not exceed 16 bytes.

9. Rewrite l3_dump.py with Python argument parsing support. [Status: Done under review, PR Support argument parsing in L3's core l3_dump.py utility. #31. Merged under ff1e385]

10. Cleanup mmap() management. For instance, we currently don't have a way to l3_deinit(), or to l3_reinit(). Client program may wish to stop logging, resume logging or re-start logging. Current mmap-file handling seems incomplete, and potentially buggy.

11. Make # of log-entries configurable. l3_init() could take size of the log-file in # of entries.

12. Add L3-log-file signature to identify provenance of the log-file.

• Make l3_dump.py robust by checking for this signature from the log-file header, so it does not go off the deep-end trying to unpack log-entries from a bogus file. Status: Scaffolding, by way of status flags, added to LOG-header. Need to add checking code.

• Provide a way to encode the LOC-encoding scheme in the header so that the appropriate LOC-decoding technique (either using a _loc binary or readelf) can be transparently invoked by the Python l3_dump.py script. [ Currently the LOC-decoding relies on an env-variable, which is a bit fragile approach. ] Status (1.May) This is done under PR Formalize L3-log header. Add status flags. Remove dependence on env-variables. #35 . Need to submit for review.

14. Merge l3_log_simple() and l3_log_fast() so that the author will get the fast assembly version on x86-64 and the slower C-version on other architectures. (Later we could add fast versions for other architectures, namely arm64.)

Performance benchmarking

We need to build a performance benchmarking exerciser for this logging library to measure and demonstrate the impact of L3 logging or L3-LOC logging. One idea:

Develop a sender-receiver client/server program that just does simple RPC message exchanges. Add metrics to time the round-trip message communication. Status: Completed on 3.May.2024 under multiple commits. SHA 7be0b54 & 94779dc added working sample program. This was refactored for our specific use-caseunder commit @sha e3884c2.

Inject L3 / L3-LOC logging. Re-measure the roundtrip time and show that there is very little, to immeasurable, affect on actual RPC msg-communication performance.

Update and future dev work-list

(30.Apr.2024) PR #33 includes a set of commits that implement a starting performance benchmark exerciser. Following is the plan of future dev work-items:

1. Finish review for above PR. Get that checked-in to /main

2. Implement Makefile changes to get 'C' client/server perf exerciser to:
   a) work with L3-LOC encoding. Status: Completed under commit @sha 6c714b1
   b) work with L3-ELF encoding - need to discover how-to do this. Status: Completed under commit @sha 9f18e31

3. Implement Makefile build changes to get the same client/server programs to work with C++ compiler

4. Explore how to integrate C++20's source_location{} object into this logging machinery, bundled with LOC-ELF approach. This itself will take time. Some new code dev here.

5. Drop-in (4) into this perf test bed, to show how-to use C++20's feature along with L3-logging

6. Do perf-comparisons of baseline v/s L3 logging v/s L3-LOC v/s L3-LOC-ELF v/s L3-C++-ELF encoding

7. Come up with perf measurements and also space overheads if any.

Other Follow-up items

List of non-blocking items raised during review which might merit some follow-up.

1. In PR [Pytest] Add pytests to verify decoding by l3_dump.py, including LOC-decoding. #30 , this comment asks to consider using Python pexpect() interface for testing methods.

[gregthelaw]

This looks good. Another thing is to merge l3_log() and l3_log_fast() so that the author will get the fast assembly version on x86-64 and the C version on other architectures. (Later we could add fast versions for other architectures, namely arm64.)

I like the idea of a printf-style interface -- that's neat. May even be possible to support arbitrary number of arguments though I suspect not, and probably also not e.g. "%s". I wonder what cleverness a C++ interface could permit though... Regardless, something more printf than we currently have would certainly be cool.