is blitzmax ever going to get a better threaded gc
BlitzMax Forums/BlitzMax Programming/is blitzmax ever going to get a better threaded gc
| ||
| Hey, Im not complaining here but I was just wondering what the plans are for the threaded gc... I want to expand my physics engine to make it threadable but right now when I run it in threaded mode the GC almost doubles the update time. Also it would be nice (for optimization's sake) if there were commands to free each thread and mutex and run the regular gc on everything non threaded. Im thinking about polishing the bmax version and switching this project over to c++ right now to continue working on it because it is getting faster but it will never be a whole lot faster without the use of threads without the annoying gc |
| ||
| good things come to those who wait... read into that whatever |
| ||
| Consider yourself lucky. My application runs at about 10% speed in threaded mode. |
| ||
| Interesting... my threaded bmk can build the official modules in half the time of the non-threaded version... |
| ||
| my threaded bmk can build the official modules in half the time of the non-threaded version... hmmm... really? Maybe its not as heavy with the variables created as physics, hence less for the gc to keep track of. My application runs at about 10% speed in threaded mode. hmm thats really slow... Maybe I should just convert it to c++ and continue from there instead? |
| ||
| Why couldn't a future version of BlitzMax have the option to turn off GC, so we can handle clean-up manually? |
| ||
| @Tachyon, it already has that feature. See GCSetMode(). |
| ||
| Personally, I think that the BlitzMax object system needs to take the whole object-oriented paradigm a few steps further, and copy the way things get done in the real world (also the way things work with the Blitz3D entity system). In the real world, you tend to have a base object (a case, chassis, frame, etc) which has a hierarchy of sub-objects attached to it. The sub-objects all operate within the context of the master object, behaving as an object cluster, and communication with other object clusters is done via interfaces, signal passing, and other protected and co-ordinated means. This is also the way that the Blitz3D entity system works. You have an unparented base object, with a hierarchy of child sub-objects parented to it; all operating in the same transformational context as the base object. With the BlitzMax object system, you should be able to create a base object, and then create sub-objects and attach them into the same context as the base object to form an object cluster. Each object cluster should have its own thread and garbage collector, with communication between object clusters occurring via signal passing, interfaces, and/or similar protected and co-ordinated methods. No chance of threading conflicts occurring, as anything that could access a variable, etc, directly would be running in the same thread - as would the cluster's garbage collector. Access to external resources, such as the filesystem, would probably need to be handled via a protected interface to prevent conflicts. |
   |