http://paralleltasks.codeplex.com/
This isn't an issue as it is a question as to whether anyone working on improvements have pondered the possibility of moving the existing architecture over to a more parallel approach? The included link is one of the better parallel libraries I have seen to date, works on the 360, and I switched over from my own threaded code base to utilize the Parallel tasks library. Simpler to implement and actually ended up running faster in most cases.
The caveat is that you have to pre-organize your data into "buckets" that don't share common dependencies/variables when processing through a chunk of data or the like. One additional bonus is that there is no real need for any form of thread synchronization once complete.
I looked through some of the threading code, which is very good, however ran into some performance issues that are related to the garbage collection handling on the 360. There are a few places where values are being continuously constructed and various list management techniques that adds up when you start dealing with hundreds of entities.
Just throwing the two concepts out there in off chance that both concepts were not discussed...
Nicely implemented on all fronts...for something ~free~... it is absolutely awesome!
Comments: Also, with regards to reproducing garbage, it's always a good idea to try the latest development version first: http://bepuphysics.codeplex.com/SourceControl/network/forks/RossNordby/Development It's continuously updated with new stuff as I finish it, so it generally has a few extra bug fixes. It may also have a few extra bugs in any new features or changes, though :)
This isn't an issue as it is a question as to whether anyone working on improvements have pondered the possibility of moving the existing architecture over to a more parallel approach? The included link is one of the better parallel libraries I have seen to date, works on the 360, and I switched over from my own threaded code base to utilize the Parallel tasks library. Simpler to implement and actually ended up running faster in most cases.
The caveat is that you have to pre-organize your data into "buckets" that don't share common dependencies/variables when processing through a chunk of data or the like. One additional bonus is that there is no real need for any form of thread synchronization once complete.
I looked through some of the threading code, which is very good, however ran into some performance issues that are related to the garbage collection handling on the 360. There are a few places where values are being continuously constructed and various list management techniques that adds up when you start dealing with hundreds of entities.
Just throwing the two concepts out there in off chance that both concepts were not discussed...
Nicely implemented on all fronts...for something ~free~... it is absolutely awesome!
Comments: Also, with regards to reproducing garbage, it's always a good idea to try the latest development version first: http://bepuphysics.codeplex.com/SourceControl/network/forks/RossNordby/Development It's continuously updated with new stuff as I finish it, so it generally has a few extra bug fixes. It may also have a few extra bugs in any new features or changes, though :)