Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adding multi-thread functionality #48

Closed
janhec opened this issue Nov 22, 2019 · 31 comments
Closed

Adding multi-thread functionality #48

janhec opened this issue Nov 22, 2019 · 31 comments

Comments

@janhec
Copy link

janhec commented Nov 22, 2019

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
Copy link

pk1954 commented Jan 16, 2020

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
Copy link
Owner

tyoma commented Feb 26, 2020

Hey guys!

Will it be sufficient to have such a combobox?
IMG_1350

  • '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
Copy link

pk1954 commented Feb 26, 2020

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
Copy link
Author

janhec commented Feb 26, 2020 via email

@tyoma
Copy link
Owner

tyoma commented Feb 26, 2020 •
edited

@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
Copy link
Owner

tyoma commented Feb 26, 2020

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

@tyoma
Copy link
Owner

tyoma commented Feb 26, 2020

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

@janhec
Copy link
Author

janhec commented Feb 26, 2020 via email

@janhec
Copy link
Author

janhec commented Feb 26, 2020 via email

@pk1954
Copy link

pk1954 commented Feb 26, 2020

Hi tyoma,
if there is no such thing, as a thread name, what is it then, what I see in the thread window:
image
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
Copy link
Owner

tyoma commented Feb 26, 2020

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
Copy link

pk1954 commented Feb 26, 2020

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

@tyoma
Copy link
Owner

tyoma commented Feb 26, 2020

@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
Copy link
Owner

tyoma commented Feb 26, 2020

@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
Copy link
Owner

tyoma commented Feb 26, 2020

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

thanks!

@tyoma
Copy link
Owner

tyoma commented Feb 26, 2020

@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

i can use it, when running on win 10, of course.

@pk1954
Copy link

pk1954 commented Feb 26, 2020

Great! Thank you
Good night (it's after midnight in Germany :-)

@tyoma
Copy link
Owner

tyoma commented Feb 26, 2020

cheers, guys! you’re very helpful!

@janhec
Copy link
Author

janhec commented Feb 27, 2020 via email

@tyoma
Copy link
Owner

tyoma commented Mar 2, 2020

Just to mark the progress...
As of 6783d19 I've added support of per-thread statistics transmission to the collector part. The frontend is displaying the same cumulative stats as it did before, but reads from per-thread grouped data. Think I can make it showing distinct data in a week of two.

@tyoma
Copy link
Owner

tyoma commented Mar 8, 2020 •
edited

Hey guys!

I've got this thing running as a first approximation (no selection, no names, not thread times yet):

image

I'll publish the build shortly to github, so that you can play with it if you want to.

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020

There it is: https://github.com/tyoma/micro-profiler/releases/download/v1.6.617.0/micro-profiler.v1.6.617.0.vsix

@pk1954
Copy link

pk1954 commented Mar 9, 2020

Hi Artem,
I'm afraid you have a regression on issue #51 "Installation problem".
After installing the new version VS missed micro-profiler_x64.lib. Same procedure as in #51. I found the micro-profiler stuff in a different directory, renamed it to the directory where VS assumed it to be and the build works.
The thread # display seems to work at first glance. I would love to see the full functionality of the combo box you described.
Display of thread name is not that urgent as I thought before. At least in my current use case it's no problem to identify the interesting thread by thread number.
Regards
Peter

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020 •
edited

Hi Peter!

Can you please send me logfiles from here: %LOCALAPPDATA%\.MicroProfiler\* ? There're paths exposed in them, so you can just hit me up on LinkedIn for a private message if you don't like that info go public.

Thanks!

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020

I don't see anything attached here or in the mail...

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020

Can you just attach it to the message? It gets abridged, otherwise:
"20200309T123145.066Z I MicroProfiler vspackage module loaded...

getpid(): 3360

self: c:\users\peter\appdata\local\microsoft\visualstudio\16.0_dae80a5f\extensions\0bmrhsvd.zsk\micro-profiler_frontend.dll

exe: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe

vs.m
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
"

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020

Thanks!
Seems, that when the profiler changed environment its variable (MICROPROFILERDIR) it was too late, since msbuild.exe process has already been started. It gets fine on the next start of Visual Studio. At least that's how it worked for me.

@pk1954
Copy link

pk1954 commented Mar 9, 2020

It really seems to have been a random effect. Just out of curiosity I uninstalled MicroProfiler and reinstalled it. This time everything worked from the beginning.

@tyoma
Copy link
Owner

tyoma commented Mar 9, 2020 via email •
edited

@tyoma
Copy link
Owner

tyoma commented Apr 1, 2020

Hey guys!

Please, check out for this release: https://github.com/tyoma/micro-profiler/releases/download/v1.6.619.0/micro-profiler.v1.6.619.0.vsix - it has the issue implemented. If you're satisfied, please close it.

thanks!

@pk1954
Copy link

pk1954 commented Apr 1, 2020

It works and is very useful. Issue can be closed from my point of view.

@tyoma tyoma closed this as completed Apr 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tyoma @janhec @pk1954