Multi-Threading as it applies to Multi-Processing

[hutch--]

If you can see the processing duration in well over milliseconds then if the data allows it to be chopped up in blocks, parallel processing makes sense as you can process blocks in parallel then write them back in sequence. You will need to have some thread synchronisation but its to your advantage to minimise this as it adds to the total overhead. Now for example if you are streaming data from disk, its possible to run one thread that does the disk input and more than one other to process the data once it is in memory.

It can get very messy but if you are streaming data fast enough for long enough you can justify the work to set up a technique like this, especially if you can set up the data processing with later instructions that are designed to handle parallel processing in each core. You basically need somewhat more processing power than the maximum disk input so that you have a bit of headroom for thread synchronisation.

[dedndave]

i don't think the number of threads per core is the real issue, within reason
it's more important to talk about what they're doing
i.e., create a new thread when it's meaningful to do so
a simple example might be a window update loop
in that case, the new thread has purpose
it wasn't created in an attempt to enhance performance, per se
it has a task to perform, which frees up the main program to perform other tasks

now, in some cases, you might be able to split a single task to enhance performance
i think you could read a chunk of a file and split that into sections to search for text - something like that
unfotunately, so many functions that we'd like to speed up must be performed in serial order