FastPointer
Blitz3D Forums/Blitz3D Programming/FastPointer
| ||
| I'm doing some tests with FastPointer, where a simple program displays the rebound from a bucket on the floor. In a second parallel thread updating physical is done, my question is whether it really helps the performance of the program ?, or otherwise is not much improvement ?. |
| ||
| The answer to this will always depend on what exactly you're doing. Threads give the processor the ability to do more than one thing at once: if the time you save by doing the tasks at the same time is greater than the time you spend on setting up the tasks to run that way, you profit. For very small tasks, launching a thread or sending it data may be more expensive than simply running it sequentially. HOWEVER FastPointer is not safe. Multithreading in general in Blitz3D is not safe. Blitz3D was designed without multithreading in mind - this means that none of its data structures are designed to be accessed or updated from more than one piece of code at the same time, and have hidden mutable state (both local and global). This state is not synchronized, and will become corrupt if you access it in the wrong way. For example, you cannot safely use strings, custom type objects, or any of the graphics commands from separate threads. Even assigning a custom type object or string to a variable is not safe, as it has a hidden internal reference count which could be overwritten by two threads at once. Creating and deleting type objects is not safe, because if two threads create an object both of them will try to occupy the same position in the list, and so on. Another example is TFormPoint. When called, it doesn't return a result directly, because it needs to provide three separate coordinates for the X/Y/Z dimensions. Instead, it sets three hidden global variables with the coordinates, and lets you query them with TFormedX/Y/Z. If two threads were to try to use TFormPoint at the same time, only one set of TFormedX/Y/Z values would be available to both, and it might well be corrupt too (if they both write to the actual variables at the same time, the value might be scrambled). If you actually need to use threads for something, use BlitzMax. Blitz3D cannot do anything actually practically useful with them. (Alternative options for Blitz3D might include multi-process execution, where two whole program instances run in parallel, or a userlib to provide SIMD or GPU computation to Blitz3D code, which is far better for data-crunching anyway.) |
| ||
| I'd echo what Yasha said - after a lot of experimenting I came to the conclusion that you should NEVER built a product from the ground up in B3D around fastpointer's functionality (unless you have absolute carnal knowledge of how b3d does things behind the scenes). Adding "experimental" functions as an extra option once you have the project fully up and running is the best idea. I've had some success with limited use for i.e. resource loading where the data structures were completely separated from the main program and only handed over once the thread had completed its job and some limited optimisation for physics - however if you use a 3rd party physics API there is a good chance they will be using threading anyhow so there is limited benefit of threading your physics processing within B3D though there might be other things you could safely be processing while the main thread is stalled waiting on physics to complete. |
| ||
| Thanks for the feedback, I have always something to learn. In this case what we have done and presents no problem is updated in a second parallel thread physical functions. |
   |