Why the threading based programming model is not the best choice for multicore CPU times

This article will explain why thread based programming is not the best way to implement application parallelism in a multi-core era.

Moore's Law (Moore 1965 predicts that the number of components per integrated circuit doubles every 18-24 months) is still applicable, and its applicability is expected to continue into 2015-2020 years. Before 2005, the CPU clock rate also increased synchronously, which was enough to improve the performance of all applications executing on those CPUs. Http://www.aliyun.com/zixun/aggregation/13521.html "> Application Development Community can enjoy this performance improvement simply by making a small investment in algorithmic improvements or even without investing."

However, since 2005, the growth of the clock rate and the number of transistors is no longer synchronized. The clock rate has stopped growing (or even decreased) due to physical limitations of the processor material, and processor manufacturers are beginning to encapsulate more execution units (cores) into a single chip (slot). This trend, which appears to be able to remain in the foreseeable future, has begun to bring increasing pressure on the application development and programming language development community, which is largely manifested in two areas:

simply upgraded to a more powerful CPU can no longer achieve the performance growth rate of single-threaded applications before 2005. The performance of single-threaded applications is unchanged, regardless of the number of cores in the CPU. That is, each core throughput is almost the same, regardless of how many cores the CPU has (assuming there is no breakthrough in the automatic parallelization of the compiler, VM, or OS level). Upgrading to multi-core CPUs only benefits the incremental load on the system, not the existing load.

The only way to efficiently leverage the core of available CPUs is to use parallelism. So far, the operating system primarily uses parallelism at the process level to provide a seamless multitasking, multi-processing experience. In application development, thread-based concurrent programming is the leading mechanism to achieve parallelism.

Thread-based parallelism has the following advantages:

It is a widely accepted programming model. The application development community has an in-depth understanding of how threads are created, dispatched, executed, and managed. Developers have been trained to develop sequential thinking algorithms. The threading model is simply an extension of the same approach in terms of parallelism.

However, the problem of thread-based application parallelism is greater than the advantage. This article explains that explicit thread-based application parallelism may not be the best way to take advantage of the CPU core and some of the reasons why we need a different programming pattern.

Call Stack Depth

The call stack is an internal structure maintained by the operating system or virtual machine that handles all method calls. Each method call in the execution of a thread advances a stack frame (consisting of the details of a parallel method invocation, such as parameters, return addresses, and local variables).

Figure 1 shows the internal principle of the method invocation:

Figure 1. Call stack internal structure and growth

No matter how you block an application into multiple logical tiers, such as the controller layer, the appearance layer, the component layer, and the data Access object [DAO] layer, at run time, the thread is the ultimate loom (Weaver), and it has only one stack. The call stack is a wonderful invention in the run-time processing of source code modularity. However, as the complexity of the application and the growth of the load on the system, the current call stack structure model restricts application scalability, and it also has internal issues related to memory size and object accessibility.