Z AI1.4
1.0.0
Brief introduction
The open source version can be obtained freely, modeled freely, and resolved and identified problems by themselves. The project framework design, base and platformization, and implementation are not open source and do not provide documentation.
The algorithm system consists of algorithm API + algorithm support. Algorithm support refers to running algorithm conditions, such as modeling systems, algorithm application ideas, such as the dnn-thread system, which is an algorithm support, the sample database is also an algorithm support, and modeling tools built based on the sample database are also a support.
The algorithm API is part of the open source projects with various CV+ recognition properties in Git. ZAI will have some independent innovations, and the algorithm ideas and directions are basically consistent with these open source projects. Some open source projects are even more advanced than ZAI's algorithms and have a higher recognition rate. Looking at open source projects, we look at the intensity of updates. Only continuous strong updates can truly advance to social production and application, otherwise they will be washed away by time.
In the early versions of ZAI (1.2/1.3), I have always paid great attention to the construction of the algorithm system. Basically, every time I update, a lot of new algorithms will be added. Later, after the release version is completed, these algorithms can be equivalent to dozens of open source projects, and most of these algorithms have not been applied. This is embarrassing! Because the most applications are only target detection, target classification, scene classification, and other algorithms will basically not be applied. Even if dozens of algorithms are added, it will not change anything. For example, it will be the same when adding yolov7. It is meaningless to integrate multiple same-nature algorithms in the computing engine. This will not change the application model, nor will it change the modeling results and project success or failure.
The matching between algorithms and actual projects is actually very small, and the AI solutions we use through Baidu, Hongruan, SenseTime, etc. are all made with great effort, which is not at the algorithm level. These companies have their own technical systems and application-level ideas. Algorithms are a resource, and the fate of algorithms is screened and reconstructed by the technical system. The proportion of algorithms is very small. The systems around algorithms are the core of the survival of AI companies. To put it another way, AI companies rely on the dividends of the times, algorithms are the food that AI companies eat, and the framework and algorithm support system are the digestive system of AI companies, and finally produce various application solutions.
After clarifying the essential positioning of the algorithm, return to the ZAI algorithm system, the core of the algorithm is the algorithm support system. Only after that can the application layer framework be established.
The algorithm support system part of ZAI has been baptized for three years. Now, ZAI is taking its own route.
The AI database system can only be used for modeling systems. For example, the scene classifier samples will at least tens of thousands of 720p/1080p. A little larger, these samples will answer a million-level scale. At this time, for big data management and efficient access, server hardware devices must be used, such as large memory, >20 core CPUs. This has certain requirements for database technology.
The AI database system is not a traditional database, but a program-level data structure. These data structures all support multi-threading acceleration and Large-Scale (TB-level big data support system). The PC used in traditional mis/erp development cannot adapt to AI databases: once the sample size is large, the memory is insufficient, and it must be streamlined or used the Large-Scale method to manage the database, which will waste a lot of time doing meaningless work that competes with the hardware.
AI database structure = + sample chain structure + sample chain matrix structure that adapts to the data requirements of all models
AI database system = Z.AI.Common (AI database) + Z.AI.Editor (AI toolchain copy database) +*.dproj (the entire modeling toolchain system, about 20-30 modeling support tools). These databases use DFE, ZDB1, and ZDB2 tool support libraries at the bottom of the storage layer.
The AI database system does not distinguish between the target model. Any data required by the model will be supported accordingly in the AI database system. These support includes API support, standardized support, and toolchain support.
Due to project development, the AI toolchain has been updated as an internal version.
At the time of writing, the toolchain has built nearly 150 versions, which have undergone numerous repairs and updates.
Version count history has been 1.4 Eval1..Eval9 (90% of the number of versions are gone here)
After that, Beta1..Beta3 (at this time, the release time plan for 2023-June)
Tip: The open source version does not include platform support technology
Simply put: only AI modeling and recognition can be used, and the application implementation depends on your own
First, clarify the future usage route of ZDB2: the foundation of big data
Secondly, clarify the big data problem solving: the database engine must comply with the computer mechanism, the database application scenario is never certain, and the database will not be a system to solve all data problems. ZDB2 believes that to solve the database problem, you must design the database engine yourself, and use a unique and independent design database engine in all projects.
Review of the technical route promotion of ZDB2 system
It has not been put into the foreground promotion plan for the time being, but it will open source ZDB2 and will also provide some related demos. The underlying logic is because I am a programmer, and my relationship with the world is that the world needs my contribution. At the same time, the world is also calculating and plagiarizing me at any time, but the world cannot stop my contribution behavior. For a long time, I and the world have been a relationship of mutually stepping on a balance beam. This is also the original intention of only open source technology but not open source projects: embrace technology and establish an open source filtering mechanism.
Because ZDB2 has big data support capabilities, the high probability in the future will give a very good data foundation at the bottom when certain conditions are met. Only a custom data engine can meet all requirements.
ZNet represents the entire backend server system, an upper-level architecture based on ZNet.
From a macro perspective, C4 system + ZDB2 system + BigList system + Core system
This set of combination punches can only be used in 1.4 or future versions.
The data engine of the ZDB2 backend system is unique. Almost all ZNet backend servers work in the thread model (every requests with a delay of more than 100ms are pulled by threads). The BigList system brings large capacity improvements to the data link, and C4 provides an advanced architecture for the server backend.
There are many programmers in the pas circle who take the design pattern as their work route. They have brought fool-like backend frameworks to the majority of beginners, and they have a very deep computer theory foundation. This has created a situation: users and designers are dependant, not completely interdependent, and when designers cannot improve themselves, users will be passive. Reflecting in real life and work is a sign that new things appear in the world. Many people have discovered it, but designers cannot control it, which makes users located downstream of designers unable to start.
Taking some programmers and designers of delphi manufacturers as an example, their job is to maintain and develop delphi. In 2016, I saw them still trying to get started with opengl, and obviously missed the historic upgrade era of open1.x (solid tube) -> open2.0 (programmable pipeline). delphi acquired dxscene through commercial routes, and fmx was brought to the front. This is a passive behavior, which is not a pioneering practice. If the designer has self-limits on the way and the project cannot meet the standards, the user will be very, very passive.
Summary: ZNet represents the entire backend server system in the future, keeping it open and updating.
DrawEngine is abbreviated as DE, and its positioning is lightweight + standardized, and it requires a rendering and output interface. It is located in the front-end user layer.
Graphics API standards originate from Khronos, and software and hardware manufacturers will also have their own specifications. Most of these specifications are reflected in the mechanisms of pixel arrangement, pixel optimization, and API optimization.
At the same time, the graphics API also has many standards, metal, opengl, gles, vulkan, d3d, which creates a situation: the renderer needs to be compatible with various platforms and APIs, and requires a large number of interfaces, and these interfaces are upgraded and updated very quickly, which makes the development and maintenance of the rendering engine difficult. DE directly avoids the previous standard interfaces and platformization in design positioning, and makes middleware: it's okay to make the renderer differentiate, and it's no problem that the renderer can support at least one API system on the target platform.
The underlying layer of FMX is a renderer. For multi-platform API support, it is actually possible to do it. It is used to design games and VR is fine. DE uses FMX as an output interface, but it will not be limited to FMX. DE is not a renderer positioning.
The application of DrawEngine does not directly allow the program to complete the process, because rendering requires data sources, such as videos, pictures, and various visual frames. Most of the time, this requires a system like tool chain, backend, and content production. The pure code route cannot be controlled.
On the other hand, DE has a certain global perspective of computer graphics. It takes its own route.
In the 1.4 update, DrawEngine's rendering scheduling capability was greatly optimized.
Components of computer graphics solve
Please read: 1.34 old version document
Please read: Details
| Architecture | AI-Demo | tools | Net-tools | Net-Advance-Demo | Net-C4-Demo | Net-demo |
|---|---|---|---|---|---|---|
| x86 | Passed | Passed | Passed | Passed | Passed | Passed |
| x64 | Passed | Passed | Passed | Passed | Passed | Passed |
| MKL64 | Passed | Passed | Passed | Passed | Passed | Passed |
| CUDA10 | Passed | Passed | Passed | Passed | Passed | Passed |
| CUDA11 | Passed | Passed | Passed | Passed | Passed | Passed |
| CUDA12 | Passed | Passed | Passed | Passed | Passed | Passed |
The fpc compiler tests all libraries in the source directory. The source directory subdirectory is platform correlation. Fpc does not support it.
over
2023-7-26
