Crap! This was supposed to go to the list too. Pal: I imagine that you are using "reply-all" instead of "reply". Please don't. Replies to bitc-dev are directed to bitc-dev automatically. When your email agent adds me as a recipient, it breaks this behavior, with the result that I end up replying to you privately instead of to the list. I'll try to pay better attention, but could you please try not to add me individually when you are replying to the list?
Thanks On Tue, Apr 10, 2012 at 12:24 PM, Jonathan S. Shapiro <[email protected]>wrote: > On Tue, Apr 10, 2012 at 11: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'm well aware of that. But well-written games do not allocate memory > during frame render, so GC shouldn't be triggered at all. > > Or at least, that would be the case *except* that current safe languages * > force* you to allocate in various circumstances where it is not really > necessary, because the language/runtime design favors boxed objects. > > It's also worth noting that *malloc* can be expensive! > > >> 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. >> > > Depends a lot on when, why, and for how long. 20ms is definitely a long > time. On the other hand, it's pretty clear to me that I could build an > audio system with 0.7-1ms requirements in a GC'd language provided the > language offered adequate support for unboxed types. > > > shap > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
