update rocprofiler-sdk (v3) and roctracer (v1)

[cj401-amd]

Motivation

backport rocprofiler-sdk (v3) and roctracer (v1) to v0.8.0

Technical Details

• support both v3 and v1, building to use v1 as profiling backend is via --bazel_options="--define=xla_rocm_profiler=v1"
• support adjusting the maximum number of trace event, via export XLA_FLAGS="--xla_gpu_rocm_max_trace_events=30000000" , default to 4M
• support tracing hipGraphLaunch , export export XLA_FLAGS="--xla_gpu_graph_min_graph_size=1" (--xla_gpu_graph_level has been retired now)

no kernel details in the trace file to be fixed.

[Eetusjo]

I created a PR to fix the missing buffer flush in upstream: openxla#34956. @cj401-amd I think you could pick that commit here so the fix gets merged at the same time.

[alekstheod]

I think this should be
void AddEvent(RocmTracerEvent event)

it shall not restrict the user to move objects in?
You do call it as AddEvent(std::move(obj)); if you want to.

[Arech8]

what's the point of copying the object if it could just be moved from the source? (I don't know if it's could be moved from there, so I'm genuinely asking)

[alekstheod]

You will not be copying it, but what will you do is decided by the user of that api.
if you use std::move() to pass the argument it will be moved, if not it will be copied.

[Arech8]

Well.... that depends on how expensive the move is (might be, though typically not), and if the move operation is defined the first hand for the type. Passing by rvalue ref guarantees you'll have at most one copy (upon attempting to move the object into destination) in the worst case.

Can you explain what do you think is wrong with passing as rvalue ref?

[alekstheod]

Assume you have an object you want to add into that collection but you also want to use it later on. You just can't do that with this api. With a different api you can remote std::move and do it!

[alekstheod]

"And what could you do with the object after you've added a copy of it into a collection? If you're interested in querying its properties only (a.k.a. const this access), they couldn't this function just return a const reference to the object added into the collection?"
You can add it so some other container, copy it, modify it whatever. It is about the interface design and code readability.
In this particular case maybe we don't do so but why do we make our interface more complex than it should be? Why interface has to have a move semantics on it?

[Arech8]

Did you notice you have suddenly fully changed reasons to amend this?

And I fully disagree with the new rationale... There's just nothing wrong with Type&& argument, it's a perfectly normal C++. Did you ever read high-performance code? You must always think of even tiniest moves there, it's riddled with move semantic for that reason. I totally can't buy the "simplicity and readability" argument, especially given that I absolutely can't expect people using std::move(event) to prevent copying. This rarely happens even with very experienced people, most just never cares, so it's good to write code the way it just won't happen. For those who want something different - function overloads can handle this nicely.

[Arech8]

Why interface has to have a move semantics on it?

Because it's trivially simple standard C++?

[alekstheod]

I didn't change it. I just say you can have the same functionality without &&. Now regarding high performant code I would say you first measure then optimize, in the end we shall write a code which is easy to be understood by people! https://wiki.c2.com/?PrematureOptimization.
Regarding the move this is exactly what move is made for! You explicitly say I want to move this object I don't have intend to use it later on! If you don't do that someone reading the code will say ah this object was passed in (not moved) I expect it
to be used later on. But if it is not you will confuse the reader!

[Arech8]

I didn't change it.

You did. At first your argument was about an imaginary use of the function, that didn't occur yet (please note, this is what is actually called a "premature optimization", not the intent to clearly express operation semantic as the author did), then you made an argument about imaginary "readability and complexity". Maybe you covertly meant the second when was taking about the first, I don't know that, but these are totally different arguments that have nothing in common.

I just say you can have the same functionality without &&.

No, you can't. Functionality and the semantic of the operation will be different. That's why this syntactic sugar was introduced, btw...

Now regarding high performant code I would say you first measure then optimize,

Excuse me, but from that I only see that you've never tried to optimize a large bulk of badly designed code. It's very tricky to do efficiently in a limited time frame largely because of exactly such well hidden and quickly compounding costs. Inability to properly express an operation semantic, especially when the language permits it, - it a primary hall mark of a bad code.

in the end we shall write a code which is easy to be understood by people!

Which people? This is C++ project and the author used a concept that existed all the time compute programming exists, wrapped in a semantic sugar that is standardized for almost a decade and a half. We have all the rights to expect that minimally qualified people work with the code base, not just random people from a street.

Regarding the move this is exactly what move is made for! You explicitly say I want to move this object I don't have intend to use it later on! If you don't do that someone reading the code will say ah this object was passed in (not moved) I expect it to be used later on. But if it is not you will confuse the reader!

Now, that's right! That's exactly why rvalue reference is used here! You have no way to directly call this function with lvalue, you must use either std::move() or a type cast. Isn't?

class Type;
void foo(Type&& v);

Type v;
foo(v); // error: no matching function for call to `foo`, candidate function not viable: expects an rvalue for 1st argument

And btw, speaking of API - if you want to use the object passed as an argument later, you can just manually create a copy:

foo(Type(v));  // OK, creates a temporary object by copying v, making a hidden copy explicitly visible.

Alex, I see that you just aren't familiar with rvalue references (or C++ value categories in general) and move semantic. This is fine - nobody can know everything. But I'm concerned that instead of seeing this as an opportunity for learning, you seems to become hostile to the idea and invent reasons why this should not be used.

Look, rvalue references are very simple and in the context used here they even more simpler: it's just a normal reference, which on top says "I may take an ownership of this object, so you can forget about it". It's a clean and neat way to declare "hey there, this function efficiently accepts the parameter by reference (hence no, literally no runtime costs), but may steal the value of the parameter, so you can't use it afterwards.". This is light years better than "yeah, my function does the same as above, but now you MUST explicitly care about ensuring the object you don't need anymore won't be copied, and even in that case you MUST pay a runtime price for that"...

I know C++ value categories and move semantic might be confusing, so please reach me anytime, I'll be happy to help.

EDIT: clarified "it" -> "the idea", so I'm not sounding like I was offended or something. It's totally fine to not like an idea and we're only discussing ideas here.

[Arech8]

@cj401-amd , I'm sorry, I haven't finished and I'm way over my distraction budget, so I have to work on my own tasks for today... Please blink twice )) if you want me to continue reviewing; I could proceed later...

[i-chaochen]

Since most of stuff are similar to existing one from 0.7.1, LGTM to merge and unblock 0.8.0 release.

But, please share your smoke testing on profiling here https://github.com/ROCm/frameworks-internal/issues/12277

In addition, please address @Arech8 comments before we proceed.

[i-chaochen]

BTW @cj401-amd does this PR include Eetu's changes openxla#34956 ?

[cj401-amd]

BTW @cj401-amd does this PR include Eetu's changes openxla#34956 ?

it will be included. only a change of one line.