This article has a hard time. A couple of months ago, I was asked to write a review on the subject of building software ecosystems for different architectures. At first, I rejected and joked in the spirit that the ecosystem is not biology. It's not even technology. This is exclusively about money. And sometimes about politics. Then he gathered his will into a fist, thoughts in a heap, sat down and wrote everything literally in one day. In English. The review was then translated into Chinese and published. On the way, the translator has significantly improved the text and added a couple of interesting thoughts. Then I decided that the text might be of interest to the Habr audience, and also useful to me to refer to it in the future. And he began to sculpt the Russian version, armed with the English original and the Chinese translation. It was that same struggle with specific English terms (SW ecosystem? = Software ecosystem,enabling? = promotion, application engineer? = application engineer) and still obscure hieroglyphs. As a result, the Russian text took longer than the English and Chinese combined ... It happens.
Over the past four or five decades, we've seen a lot of efforts to bring new processor and microcontroller architectures to market. Very few of these have proven to be successful in the long term. The two most telling examples are x86 architecture for servers and PCs and ARM for mobile phones and microcontrollers. The rest either occupy (occupied) a small niche, or did not exist for long. Of course, one of the key components of the success of a computing architecture as a whole is its ability to meet the most important customer needs in its segment. For servers, this demand is performance; for mobile devices, low power consumption / long battery life. But another important factor is the presence of a rich software ecosystem,which allows you to effectively develop new software, as well as port the existing one. Ecosystem creation is a very time-consuming and costly process, since all the required application software must be developed. But only in this way can architecture occupy the target market segment. However, once an ecosystem is developed, it serves as a natural defense mechanism, preventing competing architectures from entering the market. In this article, the author summarizes key lessons learned from the experience as applied to the task of building an ARM ecosystem in the server market segment.But only in this way can architecture occupy the target market segment. However, once an ecosystem is developed, it serves as a natural defense mechanism, preventing competing architectures from entering the market. In this article, the author summarizes key lessons learned from the experience as applied to the task of building an ARM ecosystem in the server market segment.But only in this way can architecture occupy the target market segment. However, once an ecosystem is developed, it serves as a natural defense mechanism, preventing competing architectures from entering the market. In this article, the author summarizes key lessons learned from the experience as applied to the task of building an ARM ecosystem in the server market segment.
Today's challenge
Today we are witnessing the most interesting time in the microelectrics market. Unlike 5 years ago, when Intel controlled 95% of the corporate market, today we have more architectural innovations than ever. The first to mention the Ryzen series chips , which seriously compete with Intel. However, this innovation is not an architectural innovation: AMD processors use the developed x86 ecosystem. Their advantage lies in their efficient implementation. Other innovations are more interesting because they require building a new software ecosystem.
The "artificial intelligence revolution" pioneered and led by NVidia has revolutionized the landscape of the server market. She created an entirely new segment, almost exclusively controlled by its creator. It is based on the CUDA parallel programming platform . CUDA (first introduced in 2007) is one of the interesting examples of building an ecosystem, we will look at it in more detail later. In turn, Intel is trying to introduce its own GPU (based in part on the Gen graphics system ) to compete in the field of artificial intelligence. Intel Introduces OneAPI Toolkit to Create a Programming Environment... This is an ambitious concept of a universal method for programming accelerators (GPU, AI, FPGA, etc.). In addition, Intel uses open source for OneAPI, which makes the interface more attractive than closed source models. Data Parallel C ++ plays a central role in the OneAPI concept . It is a set of C ++ extensions based on the CYCL standard. It seems to me that the success of this interesting attempt will depend on the inclusion of these extensions in future C ++ standards. And also from the effective implementation of Intel's GPU. The latest example is the penetration of the ARM architectureinto the field of artificial intelligence, cloud and high performance computing. ARM architecture is known for its success in low power markets and has a significant software ecosystem. Therefore, an attempt to penetrate higher market segments looks natural. This is the most interesting case for us, and we will consider it in more detail from various points of view.
Technology
Technological background I have given here .
Economy
Increased competition from AMD to Intel has led to a significant "price war" between the processor giants. This cuts producers' revenues, but makes life easier for end users. On the contrary, in the field of artificial intelligence, we are seeing the dominance of NVidia, which dictates the price to the market. And here consumers are more actively looking for alternative systems.
Politics
In connection with the increase in geopolitical tensions, China and Russia set a course for the development of a 100% independent ecosystem. However, this means more than just hardware independence. Software plays an equally important role. Many applications need to be migrated or replaced for true independence. The picture below illustrates the situation in Russia.
The political factor creates a strong demand for resources to close software gaps and long-term support for these efforts. There are several powerful forces behind the creation of the ARM ecosystem. But there are also very serious problems. Let me name a few of them:
Typical early-stage chicken-and-egg problem
Some commercial closed source applications are becoming the de facto standard for important segments. For example, SAP-Hana, Oracle for databases, VMWarefor virtualization, etc. Usually developers are not interested in porting and maintaining their products on an architecture that does not have a sufficient market share. On the other hand, end users do not buy hardware that the software does not support. There are several ways to break this vicious circle. The first is to pay (huge) money to software companies for porting. The second is to create a competitive solution that will either push the product out of the market or force the desired porting. The third is to convince one of the big custom developers to "push" on him. However, neither path is easy or cheap.
Legacy Software
Most applications in the server market have been written and optimized for decades for the dominant x86 architecture. Explicitly or implicitly, the stake was more on single-threaded performance than on massive parallelism. Thus, even if the source code is available, significant rework and optimization may be required to run successfully on ARM servers.
There are many problems on the horizon, and in order to solve them we should study
Lessons from the past
The history of various architectures and software ecosystems is a rather interesting topic for them, but even the minimum coverage significantly exceeds the volume of this article (enough for several theses). Therefore, I will describe several notable cases that may help us navigate the current circumstances.
In the early
days When Intel released its first 8-bit 8080 processor in the mid-70s, it had little architectural advantage over its competitors the Motorola 6800 or Zilog Z80.... Yet Intel was the first to recognize the importance of software in promoting hardware. She was also the first to introduce her own compiler to speed up, simplify and reduce the cost of software development. It was the tools that created an important competitive advantage for Intel and enabled it to be successful early on. Intel later introduced MKL for linear algebra, VTunefor program optimization and many other tools that have played an important role in the formation of the x86 ecosystem. Moreover, Intel has guaranteed the compatibility of its tools. Later, Intel realized the importance of the OS, which controls the operation of the hardware. Its tandem with Microsoft (Wintel) became the dominant force in the PC market for about three decades. However, with the development of the server market, Linux and open source in general have become very relevant. Thus, Intel became the main contributor to the Linux kernel, and is still in position number 1 (guess who is number 2?). Most importantly, Intel has always strictly adhered to the binary compatibility (Backward compatibility) of its platforms. The fact that binaries created for any previous generation of architecture work on a later generation out of the box,and allowed x86 to become the dominant force. Building an ecosystem takes time, but it's worth it.
Sunrise and sunset
This is the only counterexample where a developed ecosystem played against its creator. In the early 2000s, Sun Microsystems had a significant niche in the SPARC server market. The company initiated and developed the Java ecosystem . The problem, however, is that the Java machine is based on an interpreter, not a compiler. So when circumstances forced Sun to open Java, it was the beginning of the end. By implementing the Java interpreter for x86, Intel gradually pushed Sun out of the server market. The lesson to be learned is that interpreted languages (so popular today) are not effective market share defenders.
ARM's success in the low power market
Workstation architecture has been leading the market for cell phones and tablets since the early 2000s. The nature of its dominance is very different from x86 in PCs and servers. ARM is an open community - the license is relatively inexpensive, which creates the prerequisites for a large number of players to enter the game. And the open Android operating system further reduces the barrier to entry. It also played a role when leading players (Samsung, Qualcomm, Huawei, etc.) realized the need for an industrial alliance to create an ecosystem. This made it possible to build it in a very short time.
Intel's attempt to invade the mobile market
Around 2007, Intel (or earlier) realized the potential of the mobile phone and tablet market and attempted to conquer it. The project was based on Atom architecture (x86 with low power consumption) and binary translation from ARM to x86 ( Houdini ). This mechanism leverages the existing software ecosystem. The applications were launched on Intel devices in record time. However, two facts played against Intel. The first is the inability to catch up with ARM in terms of power consumption. The second is the complexity of the binary translation from RISC to a more complex CISC instruction set ... This translation involves significant overhead that may be unacceptable for some classes of applications. Thus, binary broadcasting can be viewed as a market entry tool, but it can hardly serve as a long-term solution.
Ecosystem CUDA
While Nvidia's success in the AI segment is undeniable, the development of its own CUDA ecosystem still raises my questions. For example, in HPC, the proportion of applications using CUDA is still low. The reason is the high cost of porting and maintaining such applications. Some developers ported (with considerable help from NVidia engineers) their codes, but later abandoned them due to the cost of support. On the contrary, in the segment of artificial intelligence, the position of Nidia is extremely strong. However, researchers mostly use higher level frameworks ( TensorFlow , PyTorchetc.) and do not directly program in CUDA. This leads us to the conclusion that choosing the right level of abstraction for the “software harness” is of great importance for the advancement of hardware.
Back to the Future
Now let's return to our task, armed with the lessons of the past.
Industry Alliance
The biggest problem with the ARM ecosystem on the server side as opposed to mobile is that it is still very fragmented. We need some kind of center of attraction to coordinate efforts. The alliance seems natural, given that the share of all ARM vendors in the server market is about 1%. They simply have no reason to compete. The task of jointly building an ecosystem should take precedence over differentiation among themselves. A number of attempts have been made to create such an alliance.
Mention may be made of the Open Green Computing Consortium(openGCC - it's hard for a programmer to think of a more wacky name), and our recent efforts under the ARM Advanced Technology Committee within APCIT . This might be a good start, but both are local alliances. Open GCC is a Chinese organization and APKIT is a Russian one. The industry dictates the need for a global alliance that can serve multiple purposes:
Synchronization and influence on regulators
First, there needs to be some agreement between the ARM vendors themselves to ensure that the software is portable across platforms from different vendors. Secondly, it will provide an opportunity to work with international and local standards bodies. Third, it will send a powerful signal to governments and societies that the emerging ARM ecosystem can serve as a viable alternative to the existing one. While this fact is not fully realized.
Working with suppliers of operating systems and applications
As we have seen from experience, operating systems play a central role in building a software ecosystem. You might also notice that OSs developed by hardware vendors have historically not been very successful (with the exception of Apple). So working with OS vendors is strategically very important. Part of this is happening now - patches, updates that appear in the latest versions of the Linux kernel, compilers and glibc, improve the performance of ARM systems for a wide variety of workloads. But these efforts are still very fragmented, with each vendor doing it on their own, which usually takes quite a long time. The Alliance can help synchronize these efforts and expedite the adoption of updates.
We also saw that solving the chicken-and-egg problem early in the advancement of an architecture can be very difficult. The alliance could provide additional leverage in negotiations with software vendors and help share the burden of early promotion among hardware manufacturers.
Software distribution system The
third important point here is software distribution. Nowadays, ARM server software is usually built from source, which takes time and hardware resources. Whereas for x86 there is a handy RPM based scheme used for distribution. Doing something like this will take a lot of work with the ISVs and operating system vendors. And the alliance can be very useful in helping in this direction.
Creating Effective Tools
In the past, software tools have proven to be a reliable tool for ecosystem development. Therefore, today attention to them is of critical importance. One of the best examples is Intel Corporation, which combined software developers and application engineers into one organization, as shown below. Red indicates critical interaction, green indicates regular, yellow indicates sporadic.
This ensures close collaboration between tool developers. This enables application engineers (AEs) to use the best tools in the industry. AEs running the same workloads share knowledge with each other and provide consolidated feedback to hardware architects. Etc. Etc. All this led to an interesting phenomenon: the engineers working in such an organization began to think not only about their products, but also about the wide ecosystem picture. They take into account the interdependence among themselves, as well as the impact on the ecosystem as a whole.
But to create such an organization, you need a kind of "common language" that all parties can use to communicate. At some point, the TMAM microarchitecture analysis method became such.
TMAM provides a way to collect, interpret, and use microarchitecture events to profile and optimize applications.
The most important advantage of this method is that it gives an objective picture of what is happening in the hardware and allows you to improve both it and the software. But perhaps more importantly, it is a unique vehicle for building an effective hardware promotion organization.
Conclusion
Building an ARM ecosystem in the server market looks promising from an economic, political and technological point of view. However, it is taking place against the backdrop of strong competition from the dominant x86 architecture. In addition, the early problems of advancing architecture are still far from resolved. However, I believe that in the future, ARM can become a serious force in the server market. The creation of a global industrial alliance and an effective ecosystem-building organization seems highly desirable.
Building an ARM ecosystem in the server market looks promising from an economic, political and technological point of view. However, it is taking place against the backdrop of strong competition from the dominant x86 architecture. In addition, the early problems of advancing architecture are still far from resolved. However, I believe that in the future, ARM can become a serious force in the server market. The creation of a global industrial alliance and an effective ecosystem-building organization seems highly desirable.
Russia is seen as one of the most promising arenas for building the ARM ecosystem from many points of view. The government's commitment to information independence provides long-term support for this initiative. However, the potential of the ARM ecosystem has not yet been fully realized at the government level. Serious work is needed for our voice to be heard. Another reason is the relatively large market and the variety of custom brands, both private and public. For example, one can name resource-extracting giants (Gazprom, Lukoil, Rosneft), leading banks (Sberbank, VTB, Alpha), mobile service providers (MTC, Megafon, Beeline, Tele2). There is a growing awareness of the need for alternatives to existing infrastructure (x86, IBM, Oracle), both in terms of security and pricing.
And last but not least, human resources. There are many programmers in Russia who have experience in solving ecosystem problems and think in these terms.