radix tree prototype for profiler

[q40603]

This pull request is the next step for 190

Basic Information

The current scope-based timer enables one to simply profile the program.
One can insert a macro at target function to record the execution time and exact hit count.
The scope-based timer used a map with function name as key to record how many times a function is executed.

std::map<std::string, TimedEntry> m_entry;

With such information, a profiling report could be generated.

Euler1DCore.march_alpha2 : count = 51 , time = 0.0365707 (second)
Euler1DCore.setup_march : count = 1 , time = 2.2676e-05 (second)
Euler1DCore::density : count = 51 , time = 0.0020337 (second)
...

Problem to solve

Rather than knowing how many times a single function is executed, I think people will be more interested in how many times a single call path is hit during profiling as a single function may have different callers.
Also, with call path information, I am able to generate a flame graph in the future.
To record the call path, I propose to use a radix tree to dynamically construct the call graph.

Each node acts as an function being executed, and it has:

• TimedEntry
• List of children node that represent callees

Prototype expected output

root - Count: 0 - Time: 0
  a - Count: 1 - Time: 5
    b - Count: 1 - Time: 3
    c - Count: 1 - Time: 7
      d - Count: 1 - Time: 9
        e - Count: 1 - Time: 1
    f - Count: 1 - Time: 2.41 

[yungyuc]

• Build the code using CMake
• Put everything under modmesh namespace
• Use a header file
• Ending comment
• Put test code in Google test directory

[yungyuc]

@q40603 Please let me know what's your progress or plan

[q40603]

@yungyuc
I have fixed the key std::string comparison using a unordered_map to hash the function name. (code not committed yet)
I will later fix the namespace issue and build the code with CMake.
After that, I will profile the modmesh with my prototype.
The ETA should be 2023/10/29 Sunday.

[yungyuc]

@q40603 if you encounter CI issue, try to rebase to the latest master to pick up #248 .

Please let a global comment when you want the code to be reviewed or have anything to discuss.

[q40603]

• Build the code using CMake
• Put everything under modmesh namespace
• Use a header file
• Ending comment
• Put test code in Google test directory

todo

1. add more test cases in gtest (e.g. tree print)

questions:

1. I am afraid that I used too much raw pointers

[yungyuc]

• Build the code using CMake
• Put everything under modmesh namespace
• Use a header file
• Ending comment
• Put test code in Google test directory

todo

1. add more test cases in gtest (e.g. tree print)

It's a good idea to add more tests. For printing, I'd suggest to do it in Python, so the first step is to make pybind11 wrapper.

Testing string representation in Python is way easier than doing that in C++.

It is a separate task. You should use another PR to do it. I will write up an issue to keep track of the followup work.

questions:

1. I am afraid that I used too much raw pointers

Using raw pointers is the right thing to do. Inside the tree implementation we should either use a pointer or an index that works like a raw pointer. The ordinary smart pointers (STL ones) are too heavy-weight for performance.

Could you please make the following finishing touches?

• Pass all CI
• Squash and rebase the branch to make history clean

Hopefully the code can be merged in a day or two. But it depends on your time.

[yungyuc]

• Please avoid touching unrelated files. You probably need to rebase to the latest master.

[yungyuc]

Please format and tidy the code before push. Using clang-format and clang-tidy locally will save your time.

[q40603]

• Please avoid touching unrelated files. You probably need to rebase to the latest master.

Ready for review,

• Formated the code and passed the CI
• Add more tests in gtest.

[q40603]

Also, it just came up to me that should I handle recursive function profiling?
Because if the recursive function is executed, the tree will become very large and deep.
But I also wonder if recursive function is used in high performance computing?

[yungyuc]

Also, it just came up to me that should I handle recursive function profiling? Because if the recursive function is executed, the tree will become very large and deep. But I also wonder if recursive function is used in high performance computing?

Yes, we should handle recursion. And you are right that we tend to avoid recursion in HPC. To be precise, we do not like function calls in tight loop, not the recursion itself. Good (fast) recursion may be replaced to loop so that in the optimized code it does not cause runtime issue. However, as you pointed out, in the profiling mode, recursion creates crazy stack entries.

As a profiling tool we need to handle recurse. It is not because the code wants to use recursion, but to be able to analyze where recursion happens so that we can eliminate it. Sometimes we tolerate the non-ideal construct for quick delivery, and the profiling tool needs to show proper information.

[tigercosmos]

it seems the code is not yet usable. is there any follow-up? @q40603

[tigercosmos]

I found it's somehow difficult to find the hierarchical representation of a object

say an object is

struct Foo {
  void Bar1();
  Void Bar2();
};

slightly modifying the proposal output, I expect to get something like this:

Foo
    Bar1 - Count: 1 - Time: 3
    Bar2 - Count: 1 - Time: 7

I expect to get a hierarchical representation like Foo::Bar1, so we can leverage the radix tree, but seems that C++ does't natively support it, and there is no common solution for this.

[yungyuc]

@q40603 please comment.

[tigercosmos]

I already found the answer, will open a PR soon :)

[q40603]

I found it's somehow difficult to find the hierarchical representation of a object

say an object is

struct Foo {
  void Bar1();
  Void Bar2();
};

slightly modifying the proposal output, I expect to get something like this:

Foo
    Bar1 - Count: 1 - Time: 3
    Bar2 - Count: 1 - Time: 7

I expect to get a hierarchical representation like Foo::Bar1, so we can leverage the radix tree, but seems that C++ does't natively support it, and there is no common solution for this.

@tigercosmos Thanks for bringing this up. From you comment, it seems that you want to use the radix tree to visualize the hierarchical representation of an object?

The radix tree prototype is targeted at improving the TimeRegistry so function call path could be recorded during profiling.

To profile the program, a user is expected to put the macro at the function he or she is interested in, such as Euler1DCore.cpp, a macro is put at the beginning of the function.

In your case, the macro that needed to be put in function Bar1 should be like this

MODMESH_TIME("Foo::Bar1");

Consider the following code.

struct Foo f;
f.Bar1();
f.Bar2();
f.Bar1();

The profiling report should be like this

root
  Foo::Bar1 - Count: 2 - Time: 5.4
  Foo::Bar2 - Count: 1 - Time: 2.1