You're right sometime I forget it's "only" a C++ generator... :) -----Original Message----- From: skaller [mailto:[EMAIL PROTECTED] Sent: 11 juillet 2006 11:38 To: Stephane Le Dorze Cc: [email protected] Subject: Re: [Felix-language] garbage collection.
On Tue, 2006-07-11 at 09:50 -0400, Stephane Le Dorze wrote: > I am not saying I want something similar to C/C++. > Avoiding memory management is a quality in a garbage collector and is > very appreciated. > (I do not want people in the team manually delete objects neither - it > is hazardous). It may or may not be, depending on the data structure. Felix, like C++, allows you blow off your foot -- with a thermo-nuclear weapon .. :) The point is there are multiple techniques for reducing the load on the collector(s). Exactly what will work is likely to be application dependent, clearly I can't make any promises. All that is really guaranteed is that Felix is ultimately C++ so if you can do it in C++ you do the exact same thing in Felix: body """ // put C++ code here """; is a valid Felix program :) > I just want to be sure not having garbage collection stopping my game > more than a fraction of a frame at a 60 fps rate. > Iterative garbage collector algorithms exist for this purpose. > I already used it for similar reasons and Unreal also uses this system > to ensure reliability. Boehm collector can run incrementally I believe .. however it is extremely slow because it is conservative .. it more or less has to scan ALL memory. Felix collector is exact (precise) .. it knows where every pointer in the system is. At this point there is no incremental collector. Naive sweep must mark all objects reachable before any garbage can be collected, and it has to run thru the list of all objects to remove the garbage. Felix does supply an arena allocator with copying/compacting collection .. however it has proved slower than plain malloc so far. It is certainly possible to consider different technology: we need use cases though. Lua recently tried to add a generational incremental collector and it was a failure: it not only didn't work properly, it used twice the memory and slowed programs down. The thing is most GC are designed for a single thread. Multi-threaded gc don't seem to work nearly as well. Still, it is probably faster than ref-counting .. which needs a mutex to protect every counter increment/decrement. The best system seems to require purely functional operation: that allows parallel collection. > Obviously, I am not able to do a real test - I have no game programmed > in Felix running yet. Nor do I. Most of the tests are so small and short running no collection is ever invoked. RF's game runs for hours without noticeable problems, but it probably isn't as demanding as a more serious game. It's hard to tell .. most games have virtually no game engine, so they're not doing any real high level work. > I just want to be sure to have a B plan. It's an egg and chicken > problem. > Multi million dollar project deserve this level of assurance. Indeed. The assurance is that Felix is just a C++ code generator. You can mix up your Felix and raw C++ code as required. Generally, once you have used Felix for a while, you get some idea where the overheads are and have two choices: (a) use a technique with less overhead (b) complain on the list and get the problem fixed :) -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
