Garbage Collection in Long Running Concurrent Plugin Operations

Rhino Developer
1

Hello,
I am working on concurrency in my raytracing algorithms. These operate as part of my plugin in Rhino, but use my own ray-tracing algorithms. They are very long running ray-tracing operations (more so than in a rendering application) and so the efficiency of concurrency is always somewhat limited. On a multi-processor machine, I’ve usually been able to get 80 to 90% of all cores running. Others I know with similar algorithms apparently have the same issue, so I’m positive it’s working as well as is feasible. I’ve tried many things over the years to get it to perform better, but I’ve mostly had to settle for 90% CPU utilization.

My latest attempt has to do with Task Parallelism. In the past, tasks have performed terribly for this, and so far, this has been true for my latest attempts, even though I’ve been reading recent reports of Tasks being the latest and best thing for all kinds of concurrency. However, it has occurred to me that I haven’t tried a couple of things… including some of the newer features of garbage collection. So here is my question:

I would like to switch my GC to operate as a server collector, and set a region of no garbage collection with a 4 GB cap. So…

  • How is Rhino’s GC set up?
  • Is there a way for me to set the GC in Pachyderm to perform differently, even if Rhino’s GC is working as a workstation GC?
  • If so, how would I do this, and would it work cross platform?
  • In the past, the GC in my rhino plugin I think has blocked all threads during collection - at least during full collections. However, there is apparently now a concurrent mode (?). Is Rhino’s .Net GC doing collection in concurrent now? Is that as good as it sounds?

Maybe my knowledge is just incredibly out of date, but thanks in advance for any advice you can lend.

Arthur

3

Hey @Arthur,

The GC mode is set during initialization of the .NET Runtime, and we don’t set anything specific so it is the default (workstation) mode. If you want to change the GC mode you’d have to set specific environment variables before starting Rhino.

We do nothing specific with the GC, it is set to its defaults.

Not as far as I’m aware, there’s only one GC and it can only be in one mode.

Background garbage collection has been around for a while, I’m not aware of any newer concurrent GC mode. In some cases we collect memory in a non-blocking way via GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, false);, which may yield some results.

One of the best ways to improve performance is to not involve the heap wherever you can, using stackalloc, spans, structs, etc. There are many new performance features of .NET 7 that can be used in Rhino 8, some come without having to do anything to your code. It would certainly be worth a try in .NET 7/Rhino 8 to see what kind of performance gains you can get.

Hope this helps!
Curtis.

5

Thanks @curtisw,
It is helpful. Thanks. I’ll look into some of these concepts, and see if I can apply anything new to my Task-based implementation.

If I did want to play with GC settings, would I add those attributes in this file:
“C:\Program Files\Rhino 8\System\Rhino.exe.config”
…or would this need to be set during compile?

Another related thing - I’m currently debugging my code with Rhino set to .Net 4.8., because I couldn’t get it to debug in .Net 7.0 mode. Visual Studio threw an error unless I went to .Net 4.8. You probably know the one I mean. I would love to try it in .Net 7.0 mode. Is there a way to do that in Windows?

Arthur

6

This would need to be set during compile. You can use the environment variables mentioned in the link above to change the mode instead, which you can set in your debug settings or in your user profile.

To debug using Visual Studio in .NET 7 you need to either multi-target your plugin to compile for both .NET 7 and net48 (using a sdk-style csproj), or create a launcher project that targets .NET 7. The launcher project is only needed for debugging and doesn’t need to be included your plugin.

Curtis.

7

Hi,

well, I’m already multi-targetting net48, and Net7.0, but the issue seems to be with Rhino. In order to get it to debug, I had to use SetDotNetRuntime in Rhino 8 to set it to NETFramework. Otherwise it throws an error if I try…

(Or will it still use .Net 7.0 if it is set like this?)

My goal is to get it to run on Mac also, so I’ve been following all the posts on this forum to figure that out.

Arthur

8

What you need to do is select the .NET 7 target in your debug drop down, here:

Screenshot 2024-02-06 at 3.53.02 PM
Screenshot 2024-02-06 at 3.53.02 PM1074×482 74.7 KB

Also, you can add multiple debug targets, which you can select as well. This is my launchSettings.json, for example which allows one to debug Rhino 8 in either netfx, netcore, and also Rhino 7.

{
  "profiles": {
    "Rhino-netcore": {
      "commandName": "Executable",
      "executablePath": "C:\\Program Files\\Rhino 8\\System\\Rhino.exe",
      "commandLineArgs": "/netcore",
      "environmentVariables": {
        "RHINO_PACKAGE_DIRS": "$(ProjectDir)$(BaseOutputPath)$(Configuration)\\"
      }
    },
    "Rhino-netfx": {
      "commandName": "Executable",
      "executablePath": "C:\\Program Files\\Rhino 8\\System\\Rhino.exe",
      "commandLineArgs": "/netfx",
      "environmentVariables": {
        "RHINO_PACKAGE_DIRS": "$(ProjectDir)$(BaseOutputPath)$(Configuration)\\"
      }
    },
    "Rhino 7": {
      "commandName": "Executable",
      "executablePath": "C:\\Program Files\\Rhino 7\\System\\Rhino.exe"
    }
  }
}
2 Likes
9

I had to try it as soon as I saw your response. That’s amazing! Thanks so much for showing me that.

I’m having another issue, but I’ll start a new topic for that, so that others can find it easily if it comes up again.

Arthur