> and I think other criteria are far more important. I'm completely comfortable > with not supporting microsecond trading applications, and I'm reasonably > confident, given some conversations with Tim Sweeney, that the game examples > you cite can be solved.
woah, can i hire you and him? (i know who both of you are, so i know i can't, so i'm just kidding of course.) still, these are the domains *i* care about! games! gc for the cilent side, i'd like that. one small thing i'd like to interject: personally i think i *get* both sides of this debate: i *want* gc, but i also *hate* the gc's i've experienced in clients to date. there's research that in theory could reduce the suck, but i dunno if/when that will ever get into the mainstream. so i do think the theory is nice, but the practical realities to date have torpedoed the theory. is it just that developers don't know how to be careful with gc? like, gc sucks especially hard when the memory gets too tight. there's got to be some factor 2x, 4x, whateverX more free memz to keep the gc from thrashing, it would seem. so (a) getting that factor down would be nice. but (b) nobody knows how much their program will demand until they run it, so we're a bit in the dark. there's a paper or two about statically predicting how much memory your program will demand, so that you can try to make sure it "fits" nicely inside a given machine's heap / so you can pre-purchase the extra dram sticks to make sure it all plays well. (of course, harder to do that in a multi-concurrent-app resource-constrained mobile-esque setting.) _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
