On Wed, Apr 11, 2012 at 2:00 AM, Pal-Kristian Engstad < [email protected]> wrote:
> On 4/10/2012 10:09 AM, Jonathan S. Shapiro wrote: > > > So I agree that the behavior you describe exists, but I do *not* agree > that it is any sort of impediment to use. The occasional, rare, 20ms pause > in an application like this just isn't a big deal > > > That depends on the application. Games, as an example, would never > tolerate a 20 msec pause. The application has to produce images at 30 > frames per second, or sometimes at 60 frames per second. In a 30 FPS game, > you have 1,000 [msec] / 30 [frames] = 33.33.. [msec/frame] to respond to > user input, perform game logic, prepare rendering information and then > produce an image. As you can clearly see, 20 msec is *huge*, it is 60% of a > frame! > > I would think that a lot of real-time and soft real-time systems would > have similar reasons to abandon any system that paused the program for such > a long period of time. > > 3D is the hardest GC case because 1) It uses a very large activee 1G heap ( and GC times for 1+G heaps are not pretty) 2) It is bound to HW device , to which many parts of the Heap communicate Im not sure 1 frame missed every half hour is a big deal , if it is an issue you can move the vertex buffers and some basic code movement code into a separate service with its own non GC thread and use either ref counting OR static memory management on those buffers. On 2+ cores with a multi threaded graphics runtime this is likely to work better anyway. Managed DirectX seems to be ok from what i hear ( Warning hearsay) with the new Background GC , though no one has really pushed it for a big game , Speak of Midori, WinRT ( which has some of the Midori ideas i noticed) uses ref counting for some of its internals and its likely a new 3d runtime will use ref counting while the app uses a GC ( or C++) as above, Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
