Adding multi-thread functionality

[janhec]

I'm looking for an effective way to profile a multithread operation, which is complicated because a thread may fork again. Is it possible to add thread information/PID into the mix? That might help to fix the sweet point in the number and division of threads, I hope.
Admittedly, I do not have a very clear picture of this, but I hope a relatively minor report addition may go a long way, for me, at least.
Further elaboration:
I tried to use the profiler for optimizing a multi-thread proces, but couldn't do it, because I could not pinpoint real bottlenecks. Especially since individual threads may need quite different runtimes. The aim is to prioritize threading to ensure that the total runtime equals the longest run (or as close as possible). That is basically done by "subthreading" (my term but I think it is clear). So main threads are started only when there is a bit of unused cpu capacity available.
There are really two optimization problems:

1. are there parts of the implementation where speedup would help;
2. can I still improve my scheduling.

Reading up a bit I realize that this is a tall order even in terms of theoretical methods. But anyhow, advice and or more data (e.g. an absolute timeline) could help.

[pk1954]

I support the request to restrict profiling to a specific thread. janhec describes a rather complex thread structure, but the desire for thread specific profiling arises also in very simple situations. My app has only two threads, one for handling the user input and screen display, the other doing computations in the background. Several access functions are used by both threads. The UI thread can run circles around the block, while the background thread is the bottleneck limiting the performance of the app. I can activate profiling selectively on subproject level, with /GH /Gh compiler switches even on the level of individual .cpp files. Both options do not prevent microprofiler to merge profiling data from both threads. Even if I had a way to restrict profiling to single functions or code sequences, it wouldn't help, as the same code is executed by both threads.

[tyoma]

Hey guys!

Will it be sufficient to have such a combobox?

• 'Cumulative' mode will be equivalent to what you currently see;
• 'All' mode will display statisticts, where functions will also have 'thread id' (basically another column in statistics lists) and functions called from multiple threads are gonna have multiple lines per each thread they are called from;
• 'Thread #<tid>' will simply display statistics for a thread selected.

Thank you!

[pk1954]

Great, this will get the job done. If I could ask for something more, I would prefer to have the thread name instead of or in addition to the thread Id. Normally I do not know the id of the thread I am interested in. Of course I can do a "Break All" and look up the Id in the threads window. But seeing the thread name directly in the Combobox would be very convenient.

[janhec]

Hey Artem, This looks good. What I (also) hope for is a shared time frame, to judge the usefulness of some (harebrained) threading-scheme ;) I suppose that ought to be deducible from a duration set, but (optional) times (start/end) of threads would help. Not totally sure that can be done, you are the expert. Thanks, Jan

…

On Wed, Feb 26, 2020 at 10:18 PM Artem G. ***@***.***> wrote: Hey guys! Will it be sufficient to have such a combobox? [image: IMG_1350] <https://user-images.githubusercontent.com/383348/75388174-bf426580-58a1-11ea-84d2-6366eb7fea70.jpeg> - 'Cumulative' mode will be equivalent to what you currently see; - 'All' mode will display statisticts, where functions will also have 'thread id' (basically another column in statistics lists) and functions called from multiple threads are gonna have multiple lines per each thread they are called from; - 'Thread #<tid>' will simply display statistics for a thread selected. Thank you! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=ADTBHL54OW6D3YIJ4WQ2QZTRE3MA5A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENB5QNA#issuecomment-591648820>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTBHL4B4OVC3NPUXFJ2CWLRE3MA5ANCNFSM4JQWFF4Q> .

[tyoma]

@pk1954 there’s no such thing, as thread name per se in native mode. what i can do is to add a stack trace of resolved functions as a mean to identify a thread visually. but let me first implement the ids - that way we can move fast with development. btw, did you try the last version- 1.6.616? it should’ve worked better - i expected no more problems with broken paths - that kind of stuff...

[tyoma]

@janhec what do you mean by ‘shared time frame’? a percentage among all threads?

[tyoma]

@janhec in the dropdown i can add the start/stop (if complete) time for a thread. is that ok?

[janhec]

shared time frame: start and end measured against the same start time is all I mean. Perhaps trivial, but need to know simultaneity.

…

On Thu, Feb 27, 2020 at 12:01 AM Artem G. ***@***.***> wrote: @janhec <https://github.com/janhec> what do you mean by ‘shared time frame’? a percentage among all threads? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=ADTBHL5ZIUULWIP3QXC2NU3RE3YC7A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHHOY#issuecomment-591688635>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTBHL7DJOEDID4GNLWR5KDRE3YC7ANCNFSM4JQWFF4Q> .

[janhec]

Yes, that would be great.

…

On Thu, Feb 27, 2020 at 12:02 AM Artem G. ***@***.***> wrote: @janhec <https://github.com/janhec> in the dropdown i can add the start/stop (if complete) time for a thread. is that ok? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#48?email_source=notifications&email_token=ADTBHLZBWESDX53KQI76SW3RE3YI3A5CNFSM4JQWFF42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENCHLHY#issuecomment-591689119>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTBHL27QRBP2PPOLXVJ4IDRE3YI3ANCNFSM4JQWFF4Q> .

[pk1954]

Hi tyoma,
if there is no such thing, as a thread name, what is it then, what I see in the thread window:

The thread names like "WorkerTHread", "CrsrsWindow" etc. are created by me via the SetThreadDescription API. The others are created by the system and of course not very useful.

[tyoma]

ok, let me see what flexibility (in terms of dynamic updates - so that the times be updated as they observed) can i get from standard combobox. i plan to switch to completely custom controls (due to performance and portability reasons), but that is not gonna happen for a few months...

[pk1954]

I didn't try version 1.6.616? so far, will give you feedback later.

[tyoma]

@pk1954 those are the names visual studio infer from stack locations- i meant there’s no api to set/get it. it’s possible though to associate a name manually with a tls (or other thread-specific location in fs/gs segment in x86/x64)

[tyoma]

@pk1954 ha, seems my knowledge is outdated - they’ve added it in win10 finally:

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getthreaddescription

[tyoma]

I didn't try version 1.6.616? so far, will give you feedback later.

thanks!