Hmm, I think wine-mono has been working in 64-bit mode for a while - although you have to invoke wine explicitly as wine64 to hook into it . I think there are some quirks about how wine and wine-mono interacts, in such a way that you cannot do 32-bit + 64-bit switches within the process - i.e. you must do 64-bit wine to get at 64-bit wine-mono.
Do you notice any performance difference between using wine-mono and dotnet472 64-bit ?
I am going back to wine-mono for your issue, as mono supports setting profiling option via environment variables (catering for exactly this use case, when mono is running embedded inside another process), and you can set WINE_MONO_* variables to pass those along. I am not sure about the exact details so you'll need to look up the relevant docs, but I know this is possible - mono has a built-in profiler, and it is accessible and turned on via environment variables.
-------------------------------------------- On Tue, 25/6/19, Chambers, Matthew matt.chambers42@gmail.com wrote:
The application requires dotnet472 and 64-bit at that. I actually had to add that verb to winetricks to get our application to work. I'm definitely getting varying mileage! My question is how to profile it with Windows symbols so I can understand why and either help fix it in Wine or possibly avoid the problem from my application code.
The WINE_MONO_* variables are just the ones we've added. Other MONO_* variables should generally work the same as in regular Mono. I haven't worked with Mono's profiling tools so I can't give any further advice.
On Fri, Jun 28, 2019, 11:18 AM Hin-Tak Leung htl10@users.sourceforge.net wrote:
Hmm, I think wine-mono has been working in 64-bit mode for a while - although you have to invoke wine explicitly as wine64 to hook into it . I think there are some quirks about how wine and wine-mono interacts, in such a way that you cannot do 32-bit + 64-bit switches within the process - i.e. you must do 64-bit wine to get at 64-bit wine-mono.
Do you notice any performance difference between using wine-mono and dotnet472 64-bit ?
I am going back to wine-mono for your issue, as mono supports setting profiling option via environment variables (catering for exactly this use case, when mono is running embedded inside another process), and you can set WINE_MONO_* variables to pass those along. I am not sure about the exact details so you'll need to look up the relevant docs, but I know this is possible - mono has a built-in profiler, and it is accessible and turned on via environment variables.
On Tue, 25/6/19, Chambers, Matthew matt.chambers42@gmail.com wrote:
The application requires dotnet472 and 64-bit at that. I actually had to add that verb to winetricks to get our application to work. I'm definitely getting varying mileage! My question is how to profile it with Windows symbols so I can understand why and either help fix it in Wine or possibly avoid the problem from my application code.
This is the relevant part of the documentation. So presumably you can do MONO_ENV_OPTIONS="--profile" and MONO_ENV_OPTIONS="--profile=stuff" , I believe.
===
DEVELOPMENT OPTIONS ... --profile[=profiler[:profiler_args]] Loads a profiler module with the given arguments. For more information, see the PROFILING section. This option can be used multiple times; each time will load an additional profiler module.
ENVIRONMENT VARIABLES ... MONO_ENV_OPTIONS This environment variable allows you to pass command line arguments to a Mono process through the environment. This is useful for example to force all of your Mono processes to use LLVM or SGEN without having to modify any launch scripts. ===
On Friday, 28 June 2019, 19:09:22 BST, Vincent Povirk madewokdev@gmail.com wrote:
The WINE_MONO_* variables are just the ones we've added. Other MONO_* variables should generally work the same as in regular Mono. I haven't worked with Mono's profiling tools so I can't give any further advice.
On Fri, Jun 28, 2019, 11:18 AM Hin-Tak Leung htl10@users.sourceforge.net wrote:
Hmm, I think wine-mono has been working in 64-bit mode for a while - although you have to invoke wine explicitly as wine64 to hook into it . I think there are some quirks about how wine and wine-mono interacts, in such a way that you cannot do 32-bit + 64-bit switches within the process - i.e. you must do 64-bit wine to get at 64-bit wine-mono.
Do you notice any performance difference between using wine-mono and dotnet472 64-bit ?
I am going back to wine-mono for your issue, as mono supports setting profiling option via environment variables (catering for exactly this use case, when mono is running embedded inside another process), and you can set WINE_MONO_* variables to pass those along. I am not sure about the exact details so you'll need to look up the relevant docs, but I know this is possible - mono has a built-in profiler, and it is accessible and turned on via environment variables.
-------------------------------------------- On Tue, 25/6/19, Chambers, Matthew matt.chambers42@gmail.com wrote:
The application requires dotnet472 and 64-bit at that. I actually had to add that verb to winetricks to get our application to work. I'm definitely getting varying mileage! My question is how to profile it with Windows symbols so I can understand why and either help fix it in Wine or possibly avoid the problem from my application code.
To use this I would have to self-host mono, right? I'm currently just relying on the compiler to add the .NET build-up/tear-down.
I was finally able to get VsPerfCollectionTools working for trace mode under wine, but not sampling mode. It required using vsinstr to instrument the binary, and I had to be careful about which functions I allowed to be instrumented. It seems if I let it instrument any .NET functions (with funcspecs like "my.nested.namespace.*" instead of "my::nested::namespace::*"), it would crash. But I was at least able to instrument C++ functions.
Thanks for all the suggestions though everyone! -Matt
On 7/1/2019 4:49 AM, Hin-Tak Leung wrote:
This is the relevant part of the documentation. So presumably you can do MONO_ENV_OPTIONS="--profile" and MONO_ENV_OPTIONS="--profile=stuff" , I believe.
===
DEVELOPMENT OPTIONS ... --profile[=profiler[:profiler_args]] Loads a profiler module with the given arguments. For more information, see the PROFILING section. This option can be used multiple times; each time will load an additional profiler module.
ENVIRONMENT VARIABLES ... MONO_ENV_OPTIONS This environment variable allows you to pass command line arguments to a Mono process through the environment. This is useful for example to force all of your Mono processes to use LLVM or SGEN without having to modify any launch scripts. ===
On Friday, 28 June 2019, 19:09:22 BST, Vincent Povirk madewokdev@gmail.com wrote:
The WINE_MONO_* variables are just the ones we've added. Other MONO_* variables should generally work the same as in regular Mono. I haven't worked with Mono's profiling tools so I can't give any further advice.
On Fri, Jun 28, 2019, 11:18 AM Hin-Tak Leung <htl10@users.sourceforge.net mailto:htl10@users.sourceforge.net> wrote:
Hmm, I think wine-mono has been working in 64-bit mode for a while - although you have to invoke wine explicitly as wine64 to hook into it . I think there are some quirks about how wine and wine-mono interacts, in such a way that you cannot do 32-bit + 64-bit switches within the process - i.e. you must do 64-bit wine to get at 64-bit wine-mono. Do you notice any performance difference between using wine-mono and dotnet472 64-bit ? I am going back to wine-mono for your issue, as mono supports setting profiling option via environment variables (catering for exactly this use case, when mono is running embedded inside another process), and you can set WINE_MONO_* variables to pass those along. I am not sure about the exact details so you'll need to look up the relevant docs, but I know this is possible - mono has a built-in profiler, and it is accessible and turned on via environment variables. -------------------------------------------- On Tue, 25/6/19, Chambers, Matthew <matt.chambers42@gmail.com <mailto:matt.chambers42@gmail.com>> wrote: The application requires dotnet472 and 64-bit at that. I actually had to add that verb to winetricks to get our application to work. I'm definitely getting varying mileage! My question is how to profile it with Windows symbols so I can understand why and either help fix it in Wine or possibly avoid the problem from my application code.