Deciding whether to multi-thread under Windows.

[aCynic2]

I'm developing a program to find some physical characteristics of geometry. In short, you give it a model defined by a list of triangles that defines a closed geometry, a mass and scale (in case the model was designed at less than full sized) and the program proceeds to find the volume, the density, moments of inertia, center of mass and percussion, etc.

There are a couple considerations...

1. It will be time consuming. Geometry will be huge. Up to the size of battleship and I'm using a millimeter size resolution for sampling. So, it could very well be in the billions of samplings, making it time consuming. I can eliminate a lot by working on only that space that has something in it, and using spanning but it could still be time consuming. This is exacerbated by the fact the program will have to be two-pass. The first pass determines the volume for density determination, the second pass determines all that which is depends on particulate determination.

2. This is on my home machine, so I don't need to be courteous to anyone. Anything I can do to make this run faster, the better.

3. I want to watch numbers update, as much as for debugging as is for seeing the progress and wow factor.

Anyone else develop a program under such conditions and can advise?

 

[tfinch2]

If it will improve the performance of your algorithm you should definitely use them.

If you want to use the UI or see updates while processing, that's a decision you have to make if the application is just for you.

 

[EagleKeeper]

If you are not doing I/O, then threading will only help when you have multiple cores/CPUs available to you.

If you have mulitple cores available, then you need to figure out how to develop multi-threading to take advantage WITHOUT overloading the OS with to many threads.

I developed a simulation that handled messages being transmitted by wireless.
Without optimization it would take 8-10 hours to simulate a 15 second real time message running through the Wynn Hotel in Las Vegas.

 

[Markbnj]

I don't want to get into a debate over when multi-threading will help, but I would say the first thing to do is look at your data and nature of your algorithm, and decide whether the work can be parallelized efficiently. If you can break the work down into logical chunks (such as by assigning each thread a subset of the geometry) and then efficiently re-assemble the results, and the algorithm is compute-intensive, your application is likely to benefit from multiple threads.

 

[kamper]

I would propose two possible models for thinking about threading: data partitioning or calculation partitioning. In both cases you want to have different threads depend on each other as little as possible because synchronizing them is slow and dangerous. In data partitioning you'd have multiple threads doing the exact same thing. You'd just break off a piece of data for each and they'd all do the same thing, hopefully doing all the hard work before coming together to share the results.

In calculation partitioning, you'd divide the calculation into discrete steps and have one thread work on each in a pipeline. You can just install synchronized queues at all the joints. This is useful if you can't break up the data and have to process it all in a specific order. The disadvantage is that the slowest stage becomes your bottleneck. If you get fancy you can also do multiple threads in some stages (I worked on a system like that at work once, it was fun and worked quite well).

Of course this is all pointless if you only have a single single-threaded processor. The nice thing though is that, if you do it well, you can scale quite nicely to many processors by tweaking knobs that change how many threads you use. As for updating a gui, that's pretty simple if you do gui stuff in one thread that picks up little progress messages dropped in a queue by the calculation threads (most gui toolkits probably have a nice way to stick things in an event loop that runs in a managed thread). The key is that the calculation threads can leave their messages and continue on their way without waiting for the gui to do it's thing.