On Tuesday 07 November 2006 16:50, Curtis Olson wrote: > Threads impose a huge penalty in terms of complicating the code, hiding > really subtle bugs, and maintaining threaded code over time just > complicates this matter because new people come in and make changes when > they don't fully understand all the subtle interrelationships (timing, > functionality, etc) of the code. > > So sure, we can add more threads, but there needs to be some really > substantial justification for doing it, and if there isn't a significant > performance based justification as part of that, then I will be very > sceptical. >
With the advent of multicore CPU's I have actually been considering the possibilities of moving parts of the AI code to a separate thread. The problem with AI isn't so much that it uses huge amounts of CPU time, but that it needs it (at least in the current implementation) in spikes. Currently this results in quite considerable pauses (which can actually last up to a few seconds, or more). The two main offenders are: - AI model loading, due to disk access. - The AI network route tracing algorithm, which just needs to do a lot of searching. It would possibly be possible to keep the trace algorithm in a single thread. By limiting the number of computations per frame, but I don't really see a clean way to implement that right away (especially not for the trace algorithm. Cheers, Durk ------------------------------------------------------------------------- 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 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
