Thread level Parallelism VS Process level Parallelism

Short answer: performances and programming ease

Long answer :

First, one must consider two different kinds of parallelism: task based parallelism (or "macroparallelism") (for instance task A modify some data and passes the result to task B) and data level parallelism (or "microparallelism") (for instance, the load to process a large matrix or vector is spread among several parallel agents).

Second, when parallelism is considered, the different agents need to exchange information. For thread level parallelism, all threads have access to the same address space and communication is just memory access. On the contrary, process level parallelism requires specific means for interprocss communication (IPC) to allow processes to exchange data. Several IPC methods exist (pipe, shared-mem,sockets, etc) (see for instance https://en.wikipedia.org/wiki/Inter-process_communication).

The problem is that these methods generally have an important overhead and a communication may require several time consuming data copies. This is the main reason why they are presently barely used on a single proc. But when considering process running on distinct and potentially distant processors, process level parallelism is largely used. For instance, client-server applications are process level parallelism.

On a single processor, process level parallelism is also currently used for shell scripts as a simple mean to reuse existing programs. For instance, on unix a script like "sort < a_large_file | uniq" is process level parallelism. Probably not the most efficient way to implement this action (in term of performances), but completely unbeatable if you consider programming time.

Besides that the big advantages of thread level parallelism are:

1) simple and fast communication mechanism through shared memory

2) well adapted to either task level parallism or data level parallelism

3) easy to program

Point 2) and 3) are probably the most important. While thread level parallelism can be based on independent tasks, speed up is frequently limited and most present applications rely on data level parallelism, for which threads are well adapted. The common memory space make communication overhead very limited (except when locks are considered) and very efficient and easy to use parallelizing tools exist (for instance open-MP)

Implementing this kind of parallelism on independent processes is also possible. It even happens frequently when considering large calculators for high performance computing. Some (crude) tools exist (for instance "message passing interface"), but implementation is by far more complex, error prone and less efficient than thread level parallelism.

Process-level parallelism exists.

However, the Linux kernel has no idea of threads or processes. It only knows tasks.

There is Task_parallelism which is performed by processes or threads.

Threads are tasks that share most of the resources (address space, mmaps, pipes, open file handlers, sockets, etc) with the parent task. The unavoidable problem of parallelism is to share resources.

There are also Linux APIs to control how many resources to share or not share among threads, that provide more flexibility.

That's why thread-level parallelism is more popular, especially in applications written for commercial servers such as databases.