mirror of
https://github.com/openmlsys/openmlsys-zh.git
synced 2026-10-31 20:45:32 +08:00
fix(v1-en): repair missing figures and section pages in English edition
- Remap 129 broken image paths in v1/en_chapters to the files that exist under v1/img (old chapter numbering, renamed files, and .pdf figures that browsers cannot display inline). - Restore ch07/7.5/distribute.png and ch08/distillation.png, which were dropped in #499 because the `dist*` .gitignore rule matched them; narrow the rule to `/dist/`. - Fix the English toc blocks: chapter entries now point at real files and the root toc has part headings, so section pages are built again (previously only chapter index pages were generated). - Add tests/test_image_references.py to CI to catch missing or unrenderable figure references. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Chivier Humber
1
.github/workflows/main.yml
vendored
1
.github/workflows/main.yml
vendored
@@ -29,6 +29,7 @@ jobs:
|
||||
python3 -m unittest discover -s tests -p 'test_prepare_mdbook_zh.py'
|
||||
python3 -m unittest discover -s tests -p 'test_assemble_docs_publish_tree.py'
|
||||
python3 -m unittest discover -s tests -p 'test_ensure_book_resources.py'
|
||||
python3 -m unittest discover -s tests -p 'test_image_references.py'
|
||||
python3 -m unittest discover -s tests -p 'test_update_docs_workflow.py'
|
||||
|
||||
- name: Build v2 (EN + ZH) with mdBook
|
||||
|
||||
1
.github/workflows/update_docs.yml
vendored
1
.github/workflows/update_docs.yml
vendored
@@ -28,6 +28,7 @@ jobs:
|
||||
python3 -m unittest discover -s tests -p 'test_prepare_mdbook_zh.py'
|
||||
python3 -m unittest discover -s tests -p 'test_assemble_docs_publish_tree.py'
|
||||
python3 -m unittest discover -s tests -p 'test_ensure_book_resources.py'
|
||||
python3 -m unittest discover -s tests -p 'test_image_references.py'
|
||||
|
||||
- name: Build v2 (EN + ZH) with mdBook
|
||||
run: bash build_mdbook_v2.sh
|
||||
|
||||
2
.gitignore
vendored
2
.gitignore
vendored
@@ -6,7 +6,7 @@ data/
|
||||
*.DS_Store
|
||||
*.csv
|
||||
*egg-info*
|
||||
dist*
|
||||
/dist/
|
||||
_build/
|
||||
test*.md
|
||||
run.sh
|
||||
|
||||
59
tests/test_image_references.py
Normal file
59
tests/test_image_references.py
Normal file
@@ -0,0 +1,59 @@
|
||||
from __future__ import annotations
|
||||
|
||||
import os
|
||||
import re
|
||||
import unittest
|
||||
from pathlib import Path
|
||||
|
||||
from tools.ensure_book_resources import RESOURCE_NAMES
|
||||
|
||||
REPO_ROOT = Path(__file__).resolve().parent.parent
|
||||
CHAPTER_DIRS = (
|
||||
REPO_ROOT / "v1" / "en_chapters",
|
||||
REPO_ROOT / "v1" / "zh_chapters",
|
||||
)
|
||||
SHARED_RESOURCES = REPO_ROOT / "v1"
|
||||
MARKDOWN_IMAGE_RE = re.compile(r"!\[[^\]]*\]\(\s*([^)\s]+)")
|
||||
HTML_IMAGE_RE = re.compile(r"<img[^>]*?\ssrc=\"([^\"]+)\"")
|
||||
# Browsers cannot display these inline, so mdBook renders a broken image.
|
||||
UNRENDERABLE_SUFFIXES = {".pdf", ".eps", ".tif", ".tiff"}
|
||||
|
||||
|
||||
def iter_markdown_files(chapter_dir: Path):
|
||||
for path in sorted(chapter_dir.rglob("*.md")):
|
||||
relative = path.relative_to(chapter_dir)
|
||||
if relative.parts[0] in RESOURCE_NAMES:
|
||||
continue
|
||||
yield path
|
||||
|
||||
|
||||
def resolve_reference(chapter_dir: Path, markdown_file: Path, reference: str) -> Path:
|
||||
# Resource dirs are symlinks created at build time, so resolve them manually.
|
||||
target = Path(os.path.normpath(markdown_file.parent / reference))
|
||||
relative = target.relative_to(chapter_dir) if target.is_relative_to(chapter_dir) else None
|
||||
if relative is not None and relative.parts and relative.parts[0] in RESOURCE_NAMES:
|
||||
return SHARED_RESOURCES / relative
|
||||
return target
|
||||
|
||||
|
||||
class ImageReferenceTests(unittest.TestCase):
|
||||
def test_chapter_images_exist_and_are_renderable(self) -> None:
|
||||
problems: list[str] = []
|
||||
for chapter_dir in CHAPTER_DIRS:
|
||||
for markdown_file in iter_markdown_files(chapter_dir):
|
||||
text = markdown_file.read_text(encoding="utf-8")
|
||||
references = MARKDOWN_IMAGE_RE.findall(text) + HTML_IMAGE_RE.findall(text)
|
||||
for reference in references:
|
||||
if reference.startswith(("http://", "https://", "data:")):
|
||||
continue
|
||||
location = f"{markdown_file.relative_to(REPO_ROOT)}: {reference}"
|
||||
if Path(reference).suffix.lower() in UNRENDERABLE_SUFFIXES:
|
||||
problems.append(f"unrenderable format {location}")
|
||||
elif not resolve_reference(chapter_dir, markdown_file, reference).is_file():
|
||||
problems.append(f"missing file {location}")
|
||||
|
||||
self.assertEqual(problems, [], "\n".join(problems))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
unittest.main()
|
||||
@@ -2,20 +2,110 @@
|
||||
|
||||
[Machine Learning Systems: Design and Implementation (1st Edition)](index.md)
|
||||
[Preface](chapter_preface/index.md)
|
||||
[Introduction](chapter_introduction/index.md)
|
||||
[Programming Model](chapter_programming_interface/index.md)
|
||||
[Computational Graph](chapter_computational_graph/index.md)
|
||||
[Part I Framework Design](chapter_preface_advanced/index.md)
|
||||
[AI Compiler Frontend](chapter_frontend_and_ir/index.md)
|
||||
[AI Compiler Backend](chapter_backend_and_runtime/index.md)
|
||||
[Hardware Accelerator](chapter_accelerator/index.md)
|
||||
[Data Processing Framework](chapter_data_processing/index.md)
|
||||
[Model Deployment](chapter_model_deployment/index.md)
|
||||
[Distributed Training](chapter_distributed_training/index.md)
|
||||
[Part II Application Scenarios](chapter_preface_extension/index.md)
|
||||
[Recommender System](chapter_recommender_system/index.md)
|
||||
[Federated Learning Systems](chapter_federated_learning/index.md)
|
||||
[Reinforcement Learning System](chapter_reinforcement_learning/index.md)
|
||||
[Explainable AI Systems](chapter_explainable_AI/index.md)
|
||||
[Robotic System](chapter_rl_sys/index.md)
|
||||
[Appendix: Introduction to Machine Learning](appendix_machine_learning_introduction/index.md)
|
||||
|
||||
# Fundamentals
|
||||
|
||||
- [Introduction](chapter_introduction/index.md)
|
||||
- [Machine Learning Applications](chapter_introduction/applications.md)
|
||||
- [Design Objectives of Machine Learning Frameworks](chapter_introduction/design.md)
|
||||
- [Machine Learning Framework Architecture](chapter_introduction/architecture.md)
|
||||
- [Application Scenarios of Machine Learning Systems](chapter_introduction/ecosystem.md)
|
||||
- [Book Organization and Intended Audience](chapter_introduction/readers.md)
|
||||
- [Programming Model](chapter_programming_interface/index.md)
|
||||
- [Overview](chapter_programming_interface/development_history.md)
|
||||
- [Machine Learning Workflow](chapter_programming_interface/ml_workflow.md)
|
||||
- [Neural Network Programming](chapter_programming_interface/neural_network_layer.md)
|
||||
- [Bridging Python and C/C++ Functions](chapter_programming_interface/c_python_interaction.md)
|
||||
- [Functional Programming](chapter_programming_interface/ml_programming_paradigm.md)
|
||||
- [Chapter Summary](chapter_programming_interface/summary.md)
|
||||
- [Computational Graph](chapter_computational_graph/index.md)
|
||||
- [Computational Graph Functions](chapter_computational_graph/components_of_computational_graph.md)
|
||||
- [Computational Graph Basics](chapter_computational_graph/background_and_functionality.md)
|
||||
- [Generating a Computational Graph](chapter_computational_graph/generation_of_computational_graph.md)
|
||||
- [Scheduling and Executing Computational Tasks](chapter_computational_graph/schedule_of_computational_graph.md)
|
||||
- [Chapter Summary](chapter_computational_graph/summary.md)
|
||||
|
||||
# Part I Framework Design
|
||||
|
||||
- [Overview](chapter_preface_advanced/index.md)
|
||||
- [AI Compiler Frontend](chapter_frontend_and_ir/index.md)
|
||||
- [Overview of AI Compilers](chapter_frontend_and_ir/ai_compiler_design_principle.md)
|
||||
- [Overview of AI Compiler Frontends](chapter_frontend_and_ir/overview_of_frontend.md)
|
||||
- [Intermediate Representation](chapter_frontend_and_ir/intermediate_representation.md)
|
||||
- [Automatic Differentiation](chapter_frontend_and_ir/ad.md)
|
||||
- [Type Systems and Static Analysis](chapter_frontend_and_ir/type_system_and_static_analysis.md)
|
||||
- [Frontend Compilation Optimization](chapter_frontend_and_ir/common_frontend_optimization_pass.md)
|
||||
- [Chapter Summary](chapter_frontend_and_ir/summary.md)
|
||||
- [AI Compiler Backend](chapter_backend_and_runtime/index.md)
|
||||
- [Overview](chapter_backend_and_runtime/overview.md)
|
||||
- [Graph Optimization](chapter_backend_and_runtime/graph_optimizer.md)
|
||||
- [Operator Selection](chapter_backend_and_runtime/kernel_selecter.md)
|
||||
- [Memory Allocation](chapter_backend_and_runtime/memory_allocator.md)
|
||||
- [Computation Scheduling and Execution](chapter_backend_and_runtime/compute_schedule_and_execute.md)
|
||||
- [Operator Compiler](chapter_backend_and_runtime/op_compiler.md)
|
||||
- [Chapter Summary](chapter_backend_and_runtime/summary.md)
|
||||
- [Hardware Accelerator](chapter_accelerator/index.md)
|
||||
- [Overview](chapter_accelerator/accelerator_introduction.md)
|
||||
- [Components of Hardware Accelerators](chapter_accelerator/accelerator_architecture.md)
|
||||
- [Programming Methods](chapter_accelerator/accelerator_programming.md)
|
||||
- [Performance Optimization Methods](chapter_accelerator/accelerator_practise.md)
|
||||
- [Chapter Summary](chapter_accelerator/summary.md)
|
||||
- [Data Processing Framework](chapter_data_processing/index.md)
|
||||
- [Overview](chapter_data_processing/requirements.md)
|
||||
- [Usability Design](chapter_data_processing/program_model.md)
|
||||
- [Efficiency Design](chapter_data_processing/performance.md)
|
||||
- [Order Preservation Design](chapter_data_processing/data_order.md)
|
||||
- [Scaling Single-Machine Data Processing Performance](chapter_data_processing/extension.md)
|
||||
- [Summary](chapter_data_processing/summary.md)
|
||||
- [Model Deployment](chapter_model_deployment/index.md)
|
||||
- [Overview](chapter_model_deployment/model_deployment_introduction.md)
|
||||
- [Conversion to Inference Model and Model Optimization](chapter_model_deployment/model_converter_and_optimizer.md)
|
||||
- [Model Compression](chapter_model_deployment/model_compression.md)
|
||||
- [Model Inference](chapter_model_deployment/model_inference.md)
|
||||
- [Security Protection of Models](chapter_model_deployment/model_security.md)
|
||||
- [Chapter Summary](chapter_model_deployment/summary.md)
|
||||
- [Distributed Training](chapter_distributed_training/index.md)
|
||||
- [Overview](chapter_distributed_training/overview.md)
|
||||
- [Parallelism Methods](chapter_distributed_training/methods.md)
|
||||
- [Architecture of Machine Learning Clusters](chapter_distributed_training/cluster.md)
|
||||
- [Collective Communication](chapter_distributed_training/collective.md)
|
||||
- [Parameter Server](chapter_distributed_training/parameter_servers.md)
|
||||
- [Chapter Summary](chapter_distributed_training/summary.md)
|
||||
|
||||
# Part II Application Scenarios
|
||||
|
||||
- [Overview](chapter_preface_extension/index.md)
|
||||
- [Recommender System](chapter_recommender_system/index.md)
|
||||
- [Overview](chapter_recommender_system/system_architecture.md)
|
||||
- [Recommendation Pipeline](chapter_recommender_system/multi_stage_recommender_system.md)
|
||||
- [Model Update](chapter_recommender_system/model_update.md)
|
||||
- [Supporting Real-time Machine Learning](chapter_recommender_system/case_study.md)
|
||||
- [Chapter Summary](chapter_recommender_system/summary.md)
|
||||
- [Federated Learning Systems](chapter_federated_learning/index.md)
|
||||
- [Overview](chapter_federated_learning/overview.md)
|
||||
- [Horizontal Federated Learning](chapter_federated_learning/horizontal_fl.md)
|
||||
- [Vertical Federated Learning](chapter_federated_learning/vertical_fl.md)
|
||||
- [Privacy Encryption Algorithms](chapter_federated_learning/privacy_encryption_algorithm.md)
|
||||
- [Outlook](chapter_federated_learning/outlook.md)
|
||||
- [Summary](chapter_federated_learning/summary.md)
|
||||
- [Reinforcement Learning System](chapter_reinforcement_learning/index.md)
|
||||
- [Introduction to Reinforcement Learning](chapter_reinforcement_learning/rl_introduction.md)
|
||||
- [Single-Node Reinforcement Learning System](chapter_reinforcement_learning/single_node_rl.md)
|
||||
- [Multi-agent Reinforcement Learning](chapter_reinforcement_learning/marl.md)
|
||||
- [Multi-agent Reinforcement Learning System](chapter_reinforcement_learning/marl_sys.md)
|
||||
- [Chapter Summary](chapter_reinforcement_learning/summary.md)
|
||||
- [Explainable AI Systems](chapter_explainable_AI/index.md)
|
||||
- [Background](chapter_explainable_AI/explainable_ai.md)
|
||||
- [Robotic System](chapter_rl_sys/index.md)
|
||||
- [Overview of Robotic Systems](chapter_rl_sys/rl_sys_intro.md)
|
||||
- [Robot Operating System](chapter_rl_sys/ros.md)
|
||||
- [Case Study: Using ROS](chapter_rl_sys/ros_code_ex.md)
|
||||
- [Modern Robot Learning](chapter_rl_sys/robot_learning.md)
|
||||
- [Chapter Summary](chapter_rl_sys/summary.md)
|
||||
|
||||
# Appendix
|
||||
|
||||
- [Appendix: Introduction to Machine Learning](appendix_machine_learning_introduction/index.md)
|
||||
- [Neural Networks](appendix_machine_learning_introduction/neural_network.md)
|
||||
- [Gradient Descent and Backpropagation](appendix_machine_learning_introduction/gradient_descent.md)
|
||||
- [Classic Machine Learning Methods](appendix_machine_learning_introduction/classic_machine_learning.md)
|
||||
|
||||
@@ -20,7 +20,7 @@ target market of the GPU.
|
||||
Figure :numref:`ch06/ch06-gv100` illustrates the architecture of the
|
||||
Volta GV100 . This architecture has:
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-gv100`
|
||||
|
||||
1. 6 GPU processing clusters (GPCs), each containing:
|
||||
@@ -118,7 +118,7 @@ handle various neural networks.
|
||||
Figure :numref:`ch06/ch06-compute-unit` demonstrates how different
|
||||
layers of neural networks select appropriate compute units.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-compute-unit`
|
||||
|
||||
1. **Scalar Unit**: calculates one scalar element at a time, similar to
|
||||
@@ -145,7 +145,7 @@ floating-point arithmetic units, which are Scalar Units, and 8 Tensor
|
||||
Cores, which are 3D Cube Units specially designed for neural network
|
||||
applications.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-SM`
|
||||
|
||||
A Tensor Core is capable of performing one $4\times4$ matrix
|
||||
@@ -156,7 +156,7 @@ Figure :numref:`ch06/ch06-tensorcore`.
|
||||
D = A * B + C
|
||||
```
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-tensorcore`
|
||||
|
||||
$\bf{A}$, $\bf{B}$, $\bf{C}$, and $\bf{D}$ are $4\times4$ matrices.
|
||||
@@ -170,7 +170,7 @@ compute units.
|
||||
|
||||
## Domain Specific Architecture
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-davinci_architecture`
|
||||
|
||||
Domain Specific Architecture (DSA) has been an area of interest in
|
||||
|
||||
@@ -68,7 +68,7 @@ row index and the column vector in matrix $B$ according to the column
|
||||
index, computes the vector inner product. The thread also stores the
|
||||
result back to $C$ matrix in line 17.
|
||||
|
||||
|
||||
|
||||
:label:`cuda_naive_gemm`
|
||||
|
||||
The method of launching the kernel function is shown in
|
||||
@@ -177,7 +177,7 @@ from matrix $A$ and matrix $B$ from left to right and from top to
|
||||
bottom, computes the data, and stores the data to matrix $C$, as shown
|
||||
in Figure :numref:`use_float4`.
|
||||
|
||||
|
||||
|
||||
:label:`use_float4`
|
||||
|
||||
For details about the complete code, see
|
||||
@@ -188,7 +188,7 @@ Figure :numref:`use_tile`. For
|
||||
details about the code used to achieve this, see
|
||||
[gemm_use_tile.cu](https://github.com/openmlsys/openmlsys-cuda/blob/main/gemm_use_tile.cu).
|
||||
|
||||
|
||||
|
||||
:label:`use_tile`
|
||||
|
||||
The test results are as follows:
|
||||
@@ -256,7 +256,7 @@ shared memory can be used to improve the program throughput by enabling
|
||||
different threads in the same thread block to load unique data and reuse
|
||||
shared data.
|
||||
|
||||
|
||||
|
||||
:label:`duplicated_data`
|
||||
|
||||
We have previously mentioned that the inner product can be computed by
|
||||
@@ -281,10 +281,10 @@ threads from the global memory and stores the data in the shared memory.
|
||||
During computational processes, each thread only needs to load the data
|
||||
it requires from the shared memory.
|
||||
|
||||
|
||||
|
||||
:label:`use_smem_store`
|
||||
|
||||
|
||||
|
||||
:label:`use_smem_load`
|
||||
|
||||
For details about the complete code, see
|
||||
@@ -355,10 +355,10 @@ the current operation do not require the data in the next loop. As such,
|
||||
the execution of these computation instructions will not be blocked by
|
||||
the instructions that load the data for the next loop.
|
||||
|
||||
|
||||
|
||||
:label:`use_smem_pipeline`
|
||||
|
||||
|
||||
|
||||
:label:`hide_smem_latency`
|
||||
|
||||
For details about the complete code, see
|
||||
@@ -398,7 +398,7 @@ written to `tile` in the last loop in the inner loop after $tileK - 1$
|
||||
loops are executed, further reducing the latency of writing data to
|
||||
`tile`. Figure :numref:`hide_global_latency` shows the optimized pipeline.
|
||||
|
||||
|
||||
|
||||
:label:`hide_global_latency`
|
||||
|
||||
For details about the complete code, see
|
||||
|
||||
@@ -18,9 +18,9 @@ This chapter has the following learning objectives:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Components_of_Hardware_Accelerators
|
||||
Programming_Methods
|
||||
Performance_Optimization_Methods
|
||||
Chapter_Summary
|
||||
accelerator_introduction
|
||||
accelerator_architecture
|
||||
accelerator_programming
|
||||
accelerator_practise
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -27,7 +27,7 @@ fusing \"Conv + Conv + Sum + ReLU\". This fusion optimization eliminates
|
||||
two read operations and two write operations, optimizing the read and
|
||||
write of the outputs generated by Conv and Sum.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-03`
|
||||
|
||||
Furthermore, automatic operator generation technology enables more
|
||||
@@ -65,7 +65,7 @@ on general compute rules, thereby facilitating efficient execution.
|
||||
However, it should be noted that this approach involves additional
|
||||
memory movements.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-graph-kernel`
|
||||
|
||||
## Hardware-Specific Optimizations
|
||||
@@ -88,7 +88,7 @@ split a 100-input Concat node into two smaller nodes, one with 63 inputs
|
||||
and the other with 37 inputs, to meet the 63-input requirement of the
|
||||
accelerator.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-04`
|
||||
|
||||
### Memory Format Restrictions
|
||||
@@ -111,5 +111,5 @@ figure) are inverse operations of each other. By employing pattern
|
||||
matching on the computational graph, such operations can be easily
|
||||
eliminated.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-05`
|
||||
|
||||
@@ -28,11 +28,11 @@ This chapter aims to achieve the following learning objectives:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Graph_Optimization
|
||||
Operator_Selection
|
||||
Memory_Allocation
|
||||
Operator_Compiler
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
overview
|
||||
graph_optimizer
|
||||
kernel_selecter
|
||||
memory_allocator
|
||||
compute_schedule_and_execute
|
||||
op_compiler
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -41,7 +41,7 @@ row-major order by default, as shown at the top of the figure. However,
|
||||
matrix **B** is read in column-major order in the matrix multiplication
|
||||
process, as shown at the bottom.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-06`
|
||||
|
||||
Storing matrix **B** in the reading order increases the computation
|
||||
@@ -56,7 +56,7 @@ channels, and H and W denote the height and width respectively. Figure
|
||||
diagram of an input with batch size 2, channels 16, height 5, and width
|
||||
4.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-07`
|
||||
|
||||
A multidimensional matrix is flattened into 1D format before it is
|
||||
@@ -88,7 +88,7 @@ before the next channel is processed. The same procedure is repeated
|
||||
until the last channel of the last image is processed. NCHW is the
|
||||
default format on PyTorch and MindSpore.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-08`
|
||||
|
||||
Access to data in NHWC format also begins at the lowest dimension (i.e.,
|
||||
@@ -109,7 +109,7 @@ to the jumps from the innermost axis to the next. For example, \[a:1\]
|
||||
indicates the jump from axis W to axis H, and \[b:1\] indicates the jump
|
||||
from axis C (the innermost) to axis W.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-nchwandnhwc`
|
||||
|
||||
These two formats offer a high degree of flexibility and are therefore
|
||||
@@ -141,7 +141,7 @@ In Figure :numref:`ch07/ch07-float32andfloat16`, *Sig* refers to the sign
|
||||
bit that indicates the sign of a number, *Exponent* refers to the
|
||||
exponent bits, and *Mantissa* refers to the mantissa bits.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-float32andfloat16`
|
||||
|
||||
Applying Equation
|
||||
@@ -190,7 +190,7 @@ types, and execution efficiency of a given operator vary depending on
|
||||
the target hardware. Then, the compiler backend selects an operator
|
||||
based on the data type and data format derived from the IR.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-select`
|
||||
|
||||
The result of the operator selection process might not be as expected
|
||||
|
||||
@@ -28,7 +28,7 @@ that the device can directly access the data. When the computation is
|
||||
finished, the user can obtain the training result once the result data
|
||||
is copied from the device memory back to the host memory.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-01`
|
||||
|
||||
## Process of Memory Allocation
|
||||
@@ -57,7 +57,7 @@ Figure
|
||||
:numref:`ch07/ch07-compiler-backend-memory-02` illustrates an
|
||||
example of memory allocation.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-02`
|
||||
|
||||
In this example, memory addresses are assigned to the input tensor,
|
||||
@@ -94,7 +94,7 @@ operator memory to be allocated using offset pointers from pre-allocated
|
||||
device memory, significantly reducing the time required compared to
|
||||
direct memory allocations from the device.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-03`
|
||||
|
||||
## Memory Reuse
|
||||
@@ -129,7 +129,7 @@ in the same memory. In Figure
|
||||
accommodate only four rectangular blocks (i.e., tensors T0, T1, T2, and
|
||||
T3) when no memory reuse policy is applied, as shown in the left chart.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-04`
|
||||
|
||||
To determine an appropriate memory reuse policy, we face an NP-complete
|
||||
@@ -182,7 +182,7 @@ in this scenario, a typical approach is to allocate contiguous memory
|
||||
addresses to all weights on the network and then perform a single
|
||||
broadcast operation.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-06`
|
||||
|
||||
### In-place Operators
|
||||
@@ -209,7 +209,7 @@ simplified to a single step: copying tensor `b` to the position
|
||||
corresponding to tensor `a`. This reduces data copy time by eliminating
|
||||
two copies and eliminates the need to allocate memory for tensor `a’`.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-memory-08`
|
||||
|
||||
## Data Compression
|
||||
|
||||
@@ -4,7 +4,7 @@ Figure :numref:`ch07/ch07-compiler-backend-01` illustrates the
|
||||
architecture of the AI compiler backend, situated between the frontend
|
||||
and the hardware driver layer.
|
||||
|
||||
|
||||
|
||||
:label:`ch07/ch07-compiler-backend-01`
|
||||
|
||||
Graph optimization is a crucial step that involves transforming the
|
||||
|
||||
@@ -7,7 +7,7 @@ dependencies between operators.
|
||||
Figure :numref:`ch04/ch04-simpleDAG` shows a computational graph example
|
||||
of $\bf{Z}$=ReLU$(\bf{X}\times\bf{Y})$.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-simpleDAG`
|
||||
|
||||
## Tensors and Operators
|
||||
@@ -20,7 +20,7 @@ vector is a rank-1 tensor with one axis; and a three-channel RGB color
|
||||
image is a rank-3 tensor with three axes. See Figure
|
||||
:numref:`ch04/ch04-tensor`.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-tensor`
|
||||
|
||||
In a machine learning framework, a tensor stores not only data itself
|
||||
@@ -78,7 +78,7 @@ Sparse tensors often handle graph data of graph neural networks (GNNs)
|
||||
and are encoded using special formats such as the coordinate list (COO)
|
||||
to improve storage efficiency.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-tensor1`
|
||||
|
||||
Operators are the basic compute units of neural networks. They process
|
||||
@@ -143,7 +143,7 @@ activation function, and the data flow will be interrupted. We can
|
||||
therefore conclude that the operators in this computational graph depend
|
||||
on each other with transitive relations.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-dependence`
|
||||
|
||||
Three types of dependencies are available.
|
||||
@@ -174,7 +174,7 @@ underflow to negative infinity, or tend to 0. These all lead to
|
||||
unexpected training results. As such, we should avoid circular
|
||||
dependencies between operators when designing deep learning models.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-recurrent`
|
||||
|
||||
In machine learning frameworks, the *unrolling* method is used to
|
||||
@@ -192,7 +192,7 @@ with unique identifiers. When a subgraph is replicated to produce an
|
||||
unrolled loop, the replicated tensors and operators are assigned new
|
||||
identifiers to avoid circular dependencies.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-recurrent-1`
|
||||
|
||||
## Control Flows
|
||||
@@ -289,7 +289,7 @@ participate in computation due to conditional control. Similarly, in the
|
||||
backward computational graph, tensor $\bf{C}$ is skipped in gradient
|
||||
computation.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-if`
|
||||
|
||||
A control loop allows us to execute an operation in a loop zero or
|
||||
@@ -324,7 +324,7 @@ also a loop, with the same number of iterations as the forward loop. The
|
||||
gradient value output by one iteration serves as the input value for
|
||||
calculating the gradient of the next iteration until the loop ends.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-while`
|
||||
|
||||
## Gradient Computation Using the Chain Rule
|
||||
@@ -384,7 +384,7 @@ backpropagation based on the error between the output value and label
|
||||
value to update the weight parameters to minimize the error. The weight
|
||||
parameters to be updated include $\bf{W}$ and $\bf{W_1}$.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-chain`
|
||||
|
||||
The mean square error (MSE) is selected as the loss function in this
|
||||
|
||||
@@ -21,7 +21,7 @@ decoupling the frontend and backend languages in design, as shown in
|
||||
Figure :numref:`ch04/ch04-DAG`. From a top-level view, computational
|
||||
graph technology provides the following key functions:
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-DAG`
|
||||
|
||||
1. **Unified representation of the computation process.** Developers
|
||||
|
||||
@@ -26,7 +26,7 @@ The static graph approach decouples the definition and execution
|
||||
processes. That is, a static graph is compiled before it is executed, as
|
||||
shown in Figure :numref:`ch04/ch04-static`.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-static`
|
||||
|
||||
When a model program is generated using the frontend language, the
|
||||
@@ -81,7 +81,7 @@ learning frameworks are able to compile Python control flows as their
|
||||
static graph equivalents. In order to implement control flows in this
|
||||
case, we can use the control primitives provided by the framework.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-static-gen`
|
||||
|
||||
Static computational graphs offer two distinct advantages. First, they
|
||||
@@ -133,7 +133,7 @@ paradigm, the dynamic graph approach allows developers to create neural
|
||||
network models at the frontend and is therefore favored by a vast number
|
||||
of deep learning researchers.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-eager1`
|
||||
|
||||
Next, we reuse the pseudocode in the previous section to compare the
|
||||
@@ -154,7 +154,7 @@ computational dependencies, and dynamically generates a temporary graph.
|
||||
Figure :numref:`ch04/ch04-dynamic-gen` shows the process of generating a
|
||||
dynamic graph.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-dynamic-gen`
|
||||
|
||||
Forward computation is run through the neural network in the sequence
|
||||
@@ -362,7 +362,7 @@ into the corresponding static graph API in this phase, so as to include
|
||||
every branch of the control flow in the resulting graph. Next, we can
|
||||
easily generate static graph code from the translated syntax tree.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-ast`
|
||||
|
||||
In numerous instances, the utilization of either tracing or source code
|
||||
|
||||
@@ -18,10 +18,9 @@ this technology, this chapter explains the following key aspects:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Computational_Graph_Functions
|
||||
Computational_Graph_Basics
|
||||
Generating_a_Computational_Graph
|
||||
Scheduling_and_Executing_Computational_Tasks
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
components_of_computational_graph
|
||||
background_and_functionality
|
||||
generation_of_computational_graph
|
||||
schedule_of_computational_graph
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -42,7 +42,7 @@ a). According to the operator call sequence of the model code, such as
|
||||
a-\>b-\>c-\>d-\>e, all operator nodes are put into the queue in turn,
|
||||
and the scheduling ends.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-diaoduzhixing`
|
||||
|
||||
With the ordering, we then prepare to distribute the operators in the
|
||||
@@ -107,7 +107,7 @@ upstream. As such, we have to schedule the operators in this
|
||||
computational graph to a serial queue in order to ensure that each
|
||||
operator receives the necessary input.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-diaodu`
|
||||
|
||||
A computational graph may also contain operators independent of each
|
||||
@@ -117,7 +117,7 @@ different hardware devices to implement parallel computing. Compared
|
||||
with the serial mode, parallel computing decreases execution time by
|
||||
leveraging more computing resources at the same time.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-para`
|
||||
|
||||
Serial execution and parallel execution have their own advantages and
|
||||
@@ -217,7 +217,7 @@ preprocessing and model training tasks must wait until a batch of data
|
||||
is completely loaded, and because the I/O channel for data loading is
|
||||
idle at model training time.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-tongbu`
|
||||
|
||||
In the asynchronous setting shown in Figure
|
||||
@@ -229,7 +229,7 @@ idle time between data loading, data preprocessing, and model training
|
||||
in the asynchronous mechanism is notably reduced, thereby shortening the
|
||||
overall training time with improved execution efficiency.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-yibu`
|
||||
|
||||
To further shorten the training time and improve the execution
|
||||
@@ -241,5 +241,5 @@ and preprocessing, allowing the model to quickly traverse the entire
|
||||
dataset. On the other hand, parallel computing increases the batch size
|
||||
in iterative training, increasing the efficiency of computing resources.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-yibubingxing`
|
||||
|
||||
@@ -28,7 +28,7 @@ val count = ones.reduce(_+_)
|
||||
|
||||
We can see that users need only four lines of code to accomplish the complex task of counting specific field occurrences in a distributed dataset. This is made possible by Spark's core RDD programming abstraction. From the computation flow visualization in :numref:`rdd_transformation_example`, we can also clearly see that after creating the dataset, users only need to describe the operators applied to the dataset, while the execution and implementation of the operators are handled by the system's runtime.
|
||||
|
||||
|
||||
|
||||
|
||||
:width:`800px`
|
||||
:label:`rdd_transformation_example`
|
||||
|
||||
@@ -35,7 +35,7 @@ restrict network communication within individual racks. This approach
|
||||
has become a core design requirement for distributed machine learning
|
||||
systems.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-datacentre`
|
||||
|
||||
So, how much network bandwidth is required for training a large-scale
|
||||
|
||||
@@ -18,7 +18,7 @@ communication before introducing commonly used collective communication
|
||||
operators. These include Broadcast, Reduce, AllGather, Scatter, and
|
||||
AllReduce:
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-collective-operators`
|
||||
|
||||
- **Broadcast**: The Broadcast operator is often employed in a
|
||||
@@ -130,7 +130,7 @@ devices 1 and 3 are paired to jointly complete the summation of data in
|
||||
partition 3, and devices 3 and 2 are paired to jointly complete the
|
||||
summation of data in partition 2.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-allreduce-process`
|
||||
|
||||
Such distributed computing of gradients performed by Reduce operators
|
||||
|
||||
@@ -40,15 +40,11 @@ The key learning objectives of this chapter are as follows:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Parallelism_Methods
|
||||
Pipeline_Parallelism_with_Micro-Batching
|
||||
Architecture_of_Machine_Learning_Clusters
|
||||
Collective_Communication
|
||||
Parameter_Server
|
||||
Federated_Learning
|
||||
Training_Large_Language_Models
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
overview
|
||||
methods
|
||||
cluster
|
||||
collective
|
||||
parameter_servers
|
||||
summary
|
||||
```
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ network, we employ a computational graph, comprising connected
|
||||
operators. Each operator executes a layer of the neural network, storing
|
||||
parameters to be updated during the training.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-single-node`
|
||||
|
||||
The execution of a computational graph involves two phases: *forward*
|
||||
@@ -83,7 +83,7 @@ devices (e.g., gradient 1 on device 1 and gradient 1 on device 2) are
|
||||
aggregated (typically by AllReduce, a collective communication
|
||||
operation) to calculate an average gradient.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-data-parallel`
|
||||
|
||||
## Model Parallelism
|
||||
@@ -121,7 +121,7 @@ completes backward computation based on the local partition of
|
||||
operator 1. The local computation results on the devices are aggregated
|
||||
and returned to complete the backward computation process.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-model-parallel-intra-op`
|
||||
|
||||
In some cases, the overall model --- rather than specific operators ---
|
||||
@@ -144,7 +144,7 @@ backward computation, device 2 sends the backward computation result of
|
||||
operator 2 to device 1 for backward computation of operator 1,
|
||||
completing the training on a mini-batch.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-model-parallel-inter-op`
|
||||
|
||||
## Hybrid Parallelism
|
||||
@@ -170,5 +170,5 @@ local gradients are averaged by using the AllReduce operation. The
|
||||
averaged gradient is back-propagated to the replicas of operator 1 on
|
||||
devices 1 and 3, and the backward computation process ends.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-hybrid-parallel`
|
||||
|
||||
@@ -46,7 +46,7 @@ expansive data centers and cloud computing facilities and managing them
|
||||
effectively through distributed training systems, we can cater to the
|
||||
surging computational requirements of evolving models.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-computation-increase`
|
||||
|
||||
### Memory Constraints
|
||||
@@ -77,7 +77,7 @@ distributed training. We can harness the power of numerous servers in a
|
||||
distributed training system to parallelly train a machine learning
|
||||
model.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-single-vs-multi`
|
||||
|
||||
For enhancing the efficiency of the distributed training system, it is
|
||||
|
||||
@@ -8,7 +8,7 @@ while TensorFlow and MindSpore come with built-in parameter server
|
||||
implementations, PyTorch requires users to implement the parameter
|
||||
servers themselves by using RPC interfaces.
|
||||
|
||||
|
||||
|
||||
:label:`ch010/ch10-parameter-servers`
|
||||
|
||||
## System Architecture
|
||||
|
||||
@@ -190,12 +190,12 @@ particularly important when dealing with functions of multiple
|
||||
variables, with each mode having specific use cases and efficiency
|
||||
implications.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-calculation_graph`
|
||||
|
||||
### Forward Mode
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-forward-mode-compute-function`
|
||||
|
||||
Figure :numref:`ch04/ch04-forward-mode-compute-function` elucidates thecomputation process within the forward mode. The sequence of elementaryoperations, derived from the source program, is displayed on the left.Following the chain rule and using established derivative evaluationrules, we sequentially compute each intermediate variable ${\dot{v}_i}=\frac{\partial v_i}{\partial x_1}$ from top to bottom, as depicted on the right.
|
||||
@@ -234,7 +234,7 @@ leveraging the chain rule and established derivative evaluation rules
|
||||
${\bar{x}_1}=\frac{\partial y}{\partial x_1}$ and
|
||||
${\bar{x}_2}=\frac{\partial y}{\partial x_2}$.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-backward-mode-compute`
|
||||
|
||||
Every reverse pass of function $f$ produces partial derivatives of asingle output with respect to all inputs, represented by the followingvectors. This corresponds to a single row of the Jacobian matrix.Consequently, executing $m$ reverse passes gives us the full Jacobianmatrix.
|
||||
|
||||
@@ -16,7 +16,7 @@ compilers like the Low Level Virtual Machine (LLVM). Thus, gaining an
|
||||
understanding of the basic architecture of the LLVM compiler, depicted
|
||||
in Figure :numref:`ch04/llvm-basic`, will be beneficial.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/llvm-basicwidth="\\linewidth"`
|
||||
|
||||
The LLVM compiler consists of three components: the frontend,
|
||||
@@ -82,5 +82,5 @@ In this process, the compiler frontend handles graph compilation and
|
||||
hardware-agnostic optimization, while the compiler backend conducts
|
||||
tasks like hardware-specific optimization and operator selection.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/msflowwidth="\\linewidth"`
|
||||
|
||||
@@ -26,7 +26,7 @@ types and sequence of optimization operations. These adjustments are
|
||||
contingent upon the set level of compilation optimization, as
|
||||
illustrated in Figure :numref:`ch06/ch06-opt-pass`.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-opt-pass`
|
||||
|
||||
## Prevalent Optimization Methods
|
||||
@@ -48,7 +48,7 @@ code can decrease the size of IRs and expedite both the compilation and
|
||||
execution of a program. These types of code can result from human errors
|
||||
or may manifest during other compilation optimizations.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-opt-pass-useless-code0-elimination`
|
||||
|
||||
In Chapter
|
||||
@@ -70,7 +70,7 @@ compilation.
|
||||
Figure :numref:`ch06/ch06-opt-pass-constant-broadcast` depicts these two
|
||||
methods.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-opt-pass-constant-broadcast`
|
||||
|
||||
### Common Subexpression Elimination
|
||||
@@ -84,7 +84,7 @@ Figure :numref:`ch06/ch06-opt-pass-CSE`. As such, E doesn't need to be
|
||||
computed again; it can be directly replaced with the expression result
|
||||
obtained from the preceding computation.
|
||||
|
||||
|
||||
|
||||
:label:`ch06/ch06-opt-pass-CSE`
|
||||
|
||||
Common subexpression elimination, like the elimination of dead code and
|
||||
|
||||
@@ -27,12 +27,11 @@ The learning objectives of this chapter include:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview_of_AI_Compilers
|
||||
Overview_of_AI_Compiler_Frontends
|
||||
Intermediate_Representation
|
||||
Automatic_Differentiation
|
||||
Type_Systems_and_Static_Analysis
|
||||
Frontend_Compilation_Optimization
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
ai_compiler_design_principle
|
||||
overview_of_frontend
|
||||
intermediate_representation
|
||||
ad
|
||||
type_system_and_static_analysis
|
||||
common_frontend_optimization_pass
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -28,7 +28,7 @@ analyzing and optimizing IRs, the optimizer enhances the extensibility
|
||||
of the compilation process and minimizes the impact that might be
|
||||
introduced during an optimization process on the frontend and backend.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-IR`
|
||||
|
||||
With the ongoing evolution of compiler techniques, the development of
|
||||
@@ -82,7 +82,7 @@ operands and one target). Figure
|
||||
:numref:`ch04/ch04-linearIR` illustrates the stack machine code
|
||||
and three-address code representations for the expression $a-b*5$.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-linearIR`
|
||||
|
||||
### Graphical Intermediate Representation
|
||||
@@ -104,7 +104,7 @@ shared by multiple parent nodes. By reusing subtrees, the DAG reduces
|
||||
the cost of the evaluation process, especially when the compiler can
|
||||
verify that the value of $a$ remains constant.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-AST_DAG`
|
||||
|
||||
### Hybrid Intermediate Representation
|
||||
@@ -127,7 +127,7 @@ control transfer between these blocks is implemented through edges. This
|
||||
combination of linear IR for basic blocks and graphical IR for control
|
||||
flow allows for a flexible and efficient representation in LLVM IR.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-LLVM_IR`
|
||||
|
||||
## Intermediate Representation in Machine Learning Frameworks
|
||||
@@ -340,7 +340,7 @@ that can be performed at two adjacent levels can be a conundrum for
|
||||
framework developers. Finally, defining distinct operator granularities
|
||||
at different levels might impact accuracy to a certain degree.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-tensorflow_ecosystem`
|
||||
|
||||
### Multi-Level Intermediate Representation
|
||||
@@ -464,7 +464,7 @@ ParameterNode signifies the function's formal parameter, and CNode
|
||||
(corresponding to a compound expression in ANF) indicates function
|
||||
invocation.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-MindIR`
|
||||
|
||||
The example provided below in Code 1 offers a deeper analysis of MindIR.
|
||||
|
||||
@@ -12,7 +12,7 @@ concentrates on IRs and automatic differentiation, and later provides a
|
||||
succinct introduction to basic compiler concepts, including type
|
||||
systems, static analysis, and frontend optimization.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/compiler_frontend_structure`
|
||||
|
||||
An **Intermediate Representation** is a data structure, or a form of
|
||||
|
||||
@@ -124,5 +124,5 @@ module, cache module, semantics inference module, and control flow
|
||||
processing module, as illustrated in
|
||||
Figure :numref:`ch04/ch04-compiler-frontend`.
|
||||
|
||||
|
||||
|
||||
:label:`ch04/ch04-compiler-frontend`
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Figure :numref:`intro/framework-architecture` shows the basic
|
||||
architecture of a typical, complete machine learning framework.
|
||||
|
||||
|
||||
|
||||
:label:`intro/framework-architecture`
|
||||
|
||||
1. **Programming interfaces:** A machine learning framework needs to
|
||||
|
||||
@@ -8,7 +8,7 @@ and execute machine learning applications. Figure
|
||||
:numref:`intro/system-ecosystem` provides an overview of the
|
||||
various application scenarios for machine learning systems.
|
||||
|
||||
|
||||
|
||||
:label:`intro/system-ecosystem`
|
||||
|
||||
1. **Federated learning:** Laws and regulations on user privacy
|
||||
|
||||
@@ -7,12 +7,12 @@
|
||||
|
||||
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Machine_Learning_Applications
|
||||
Design_Objectives_of_Machine_Learning_Frameworks
|
||||
Machine_Learning_Framework_Architecture
|
||||
Application_Scenarios_of_Machine_Learning_Systems
|
||||
Book_Organization_and_Intended_Audience
|
||||
```
|
||||
:maxdepth: 2
|
||||
|
||||
applications
|
||||
design
|
||||
architecture
|
||||
ecosystem
|
||||
readers
|
||||
```
|
||||
|
||||
@@ -24,13 +24,11 @@ The key aspects this chapter explores are as follows:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Conversion_to_Inference_Model_and_Model_Optimization
|
||||
Model_Compression
|
||||
Advanced_Efficient_Techniques
|
||||
Model_Inference
|
||||
Security_Protection_of_Models
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
model_deployment_introduction
|
||||
model_converter_and_optimizer
|
||||
model_compression
|
||||
model_inference
|
||||
model_security
|
||||
summary
|
||||
```
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ the memory usage during inference can be reduced, and the inference on
|
||||
processors that are good at processing low-precision operations can be
|
||||
accelerated.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/quant-minmax`
|
||||
|
||||
The number of bits and the range of data represented by different data
|
||||
@@ -288,7 +288,7 @@ quantized to represent weights using fewer bits. In addition, using
|
||||
Huffman coding can further reduce the memory cost of the deep neural
|
||||
network.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/deepcomp`
|
||||
|
||||
In addition to removing redundant neurons, a dictionary learning-based
|
||||
|
||||
@@ -56,7 +56,7 @@ performed (depending on the backend hardware support) once the
|
||||
compilation is complete. However, some optimization operations can only
|
||||
be performed in their entirety during the deployment phase.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/fusion-storage`
|
||||
|
||||
## Operator Fusion
|
||||
@@ -81,7 +81,7 @@ operations on the memory. Furthermore, operator fusion allows some
|
||||
computation to be completed in advance, eliminating redundant or even
|
||||
cyclic redundant computing during forward computation.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/conv-bn-fusion`
|
||||
|
||||
To describe the principle of operator fusion, we will use two operators,
|
||||
@@ -174,7 +174,7 @@ type of operators that have the same computational logic but are more
|
||||
suitable for online deployment. In this way, we can reduce the
|
||||
computation workload and compress the model.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/bn-replace`
|
||||
|
||||
Figure :numref:`ch-deploy/bn-replace` depicts the replacement of
|
||||
@@ -210,7 +210,7 @@ Common methods of operator reordering include moving cropping operators
|
||||
(e.g., Slice, StrideSlice, and Crop) forward, and reordering Reshape,
|
||||
Transpose, and BinaryOp.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/crop-reorder`
|
||||
|
||||
Crop is used to cut a part out of the input feature map as the output.
|
||||
|
||||
@@ -76,7 +76,7 @@ partitioned, and multiple threads are used to process different data
|
||||
partitions. This allows operators to be computed in parallel, thereby
|
||||
multiplying the operator performance.
|
||||
|
||||
|
||||
|
||||
:label:`ch09_parallel`
|
||||
|
||||
In Figure :numref:`ch09_parallel`, the matrix in the multiplication can be
|
||||
@@ -144,7 +144,7 @@ Figure :numref:`ch-deploy/register`, NEON register v0 can store 128
|
||||
bits, which is equal to the capacity of 4 float32, 8 float16, or 16
|
||||
int8.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/register`
|
||||
|
||||
The single instruction multiple data (SIMD) method can be used to
|
||||
@@ -157,7 +157,7 @@ multiple data values in the NEON register at a time. For example, the
|
||||
floating-point values in registers v1 and v2 are added to the value in
|
||||
v0.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/fmla`
|
||||
|
||||
**3) Assembly language optimization**
|
||||
@@ -217,7 +217,7 @@ Figure :numref:`ch-deploy/conv_nhwc` is a diagram of convolution. The
|
||||
input shape is (1, IH, IW, IC), the convolution kernel shape is (OC, KH,
|
||||
KW, IC), and the output shape is (1, OH, OW, OC).
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/conv_nhwc`
|
||||
|
||||
As shown in Figure
|
||||
@@ -227,7 +227,7 @@ on the right. The number of rows corresponds to the number of OH \* OW
|
||||
outputs. For a row vector, Img2col processes KH \* KW data points of
|
||||
each input channel in sequence, from the first channel to channel IC.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/img2col_input`
|
||||
|
||||
As shown in Figure
|
||||
@@ -240,7 +240,7 @@ convolution operation is converted into the multiplication of two
|
||||
matrices. In practice, the data rearrangement of Img2col and GEMM is
|
||||
performed simultaneously to save time.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/img2col_weight`
|
||||
|
||||
**(2) Winograd**
|
||||
@@ -342,7 +342,7 @@ $$\textit{\textbf{Y}}=\textit{\textbf{A}}^{\rm T}(\textit{\textbf{G}}g\textit{\t
|
||||
The logical process of Winograd can be divided into four steps, as shown
|
||||
in Figure :numref:`ch-deploy/winograd`.
|
||||
|
||||
|
||||
|
||||
:label:`ch-deploy/winograd`
|
||||
|
||||
To use Winograd of ***F***(2$\times$`<!-- -->`{=html}2,
|
||||
|
||||
@@ -40,10 +40,10 @@ The chapter aims to achieve the following learning objectives:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Machine_Learning_Workflow
|
||||
Neural_Network_Programming
|
||||
Functional_Programming
|
||||
Bridging_Python_and_C_C++_Functions
|
||||
Chapter_Summary
|
||||
development_history
|
||||
ml_workflow
|
||||
neural_network_layer
|
||||
c_python_interaction
|
||||
ml_programming_paradigm
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -125,5 +125,5 @@ for batch_idx, (data, target) in enumerate(testing_dataloader):
|
||||
# For debugging, you can print logs inside the training or evaluation loop, or use python debugger.
|
||||
```
|
||||
|
||||
|
||||
|
||||
:label:`ch03/workflow`
|
||||
|
||||
@@ -32,7 +32,7 @@ connected layer grows substantially --- from n$\times$m during the
|
||||
initial transformation to m$\times$p in the subsequent one.
|
||||
|
||||
<figure id="fig:ch03/fc_layer_1">
|
||||
<img src="../img/ch03/fc_layer_1.png" style="width:60.0%" />
|
||||
<img src="../img/ch02/fc_layer_1.svg" style="width:60.0%" />
|
||||
<figcaption>Fully connected layer illustration</figcaption>
|
||||
</figure>
|
||||
|
||||
@@ -147,7 +147,7 @@ for inserting/deleting parameters, adding/removing neural network
|
||||
layers, and retrieving neural network model information.
|
||||
|
||||
<figure id="fig:ch03/cell_abstract">
|
||||
<img src="../img/ch03/cell_abstract.png" style="width:90.0%" />
|
||||
<img src="../img/ch02/cell_abstract.svg" style="width:90.0%" />
|
||||
<figcaption>Abstraction technique of neural network base
|
||||
classes</figcaption>
|
||||
</figure>
|
||||
|
||||
@@ -112,7 +112,7 @@ synchronization, we'll examine Ekko. Figure
|
||||
architecture where replicas can be synchronized among decentralized
|
||||
parameter servers.
|
||||
|
||||
|
||||
|
||||
:label:`P2P replication`
|
||||
|
||||
To execute the peer-to-peer synchronization algorithm, Ekko first
|
||||
@@ -203,7 +203,7 @@ considered high priority; otherwise, it is deemed low priority. The
|
||||
value of *k* is user-defined, and the kth percentile is estimated using
|
||||
an existing algorithm based on historical priority data.
|
||||
|
||||
|
||||
|
||||
:label:`model update scheduler`
|
||||
|
||||
## Online Model State Management
|
||||
@@ -230,7 +230,7 @@ this model is redirected to another model in a healthy state. The
|
||||
corrupted model is then rolled back to a previous healthy state before
|
||||
being reintroduced online.
|
||||
|
||||
|
||||
|
||||
:label:`model state manager`
|
||||
|
||||
[^1]: The update amplitude could either be the gradient itself or the
|
||||
|
||||
@@ -34,12 +34,10 @@ This chapter has the following learning objectives:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
System_Components
|
||||
Recommendation_Pipeline
|
||||
Model_Update
|
||||
Supporting_Real-time_Machine_Learning
|
||||
Chapter_Summary
|
||||
Further_Reading
|
||||
system_architecture
|
||||
multi_stage_recommender_system
|
||||
model_update
|
||||
case_study
|
||||
summary
|
||||
```
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ quality of recommendation. A depiction of this offline model update
|
||||
process can be seen in Figure
|
||||
:numref:`offline update`.
|
||||
|
||||
|
||||
|
||||
:label:`offline update`
|
||||
|
||||
To break it down, when a model completes a training period, the
|
||||
|
||||
@@ -20,7 +20,7 @@ diminished accuracy. On the other hand, using a more complex model may
|
||||
provide more accurate results but deter users due to longer waiting
|
||||
times.
|
||||
|
||||
|
||||
|
||||
:label:`recommender pipeline`
|
||||
|
||||
To mitigate this, contemporary recommender systems typically deploy
|
||||
@@ -63,7 +63,7 @@ each representing a unique user or item. The two-tower model employs a
|
||||
scoring function to evaluate the similarity between user vectors and
|
||||
item vectors.
|
||||
|
||||
|
||||
|
||||
:label:`two tower model`
|
||||
|
||||
### Training
|
||||
@@ -180,7 +180,7 @@ Deep Learning Recommendation Model (DLRM). As depicted in Figure
|
||||
DLRM consists of embedding tables, multi-layer perceptrons (MLPs) that
|
||||
include two layers, and an interaction layer.[^2]
|
||||
|
||||
|
||||
|
||||
:label:`dlrm model`
|
||||
|
||||
Similar to the two-tower model, the DLRM initially uses embedding tables
|
||||
@@ -205,7 +205,7 @@ the input for the top MLP. After further processing by the top MLP, the
|
||||
final output score reflects the probability of a user clicking on the
|
||||
item.
|
||||
|
||||
|
||||
|
||||
:label:`interaction`
|
||||
|
||||
### Training Process
|
||||
|
||||
@@ -26,7 +26,7 @@ Inference servers handle user requests, procure the necessary model
|
||||
parameters from parameter servers based on these requests, and calculate
|
||||
the recommendation outcomes.
|
||||
|
||||
|
||||
|
||||
:label:`recommender systems`
|
||||
|
||||
# System Components
|
||||
@@ -87,7 +87,7 @@ store. When the training or inference module needs to access a specific
|
||||
user's features, all necessary features can be retrieved from the
|
||||
feature store using just the user ID.
|
||||
|
||||
|
||||
|
||||
:label:`feature store`
|
||||
|
||||
One significant advantage of utilizing feature stores is the potential
|
||||
@@ -142,7 +142,7 @@ space. The structure of an embedding table in a recommendation model
|
||||
bears resemblance to its counterpart in a natural language processing
|
||||
(NLP) model, though there are subtle distinctions.
|
||||
|
||||
|
||||
|
||||
:label:`recommendation models`
|
||||
|
||||
In NLP models, the majority of parameters are found within deep neural
|
||||
@@ -197,7 +197,7 @@ offered by the parameter server architecture greatly improves the
|
||||
efficiency of storage and computation resource management in
|
||||
recommendation systems.
|
||||
|
||||
|
||||
|
||||
:label:`parameter server in recommendation`
|
||||
|
||||
The parameter servers in a recommender system have a dual role. They
|
||||
|
||||
@@ -9,11 +9,9 @@ training intelligent systems to maximize cumulative reward over time.
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview
|
||||
Introduction_to_Reinforcement_Learning
|
||||
Single-Node_Reinforcement_Learning_System
|
||||
Distributed_Reinforcement_Learning_System
|
||||
Multi-agent_Reinforcement_Learning
|
||||
Multi-agent_Reinforcement_Learning_System
|
||||
Chapter_Summary
|
||||
rl_introduction
|
||||
single_node_rl
|
||||
marl
|
||||
marl_sys
|
||||
summary
|
||||
```
|
||||
|
||||
@@ -25,7 +25,7 @@ observations are the environment states. However, this is the least
|
||||
possible in the real world. In practice, agents usually have different
|
||||
observations on the environment.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-marl`
|
||||
|
||||
## Multi-agent RL
|
||||
@@ -120,7 +120,7 @@ converge to the objective we expect. Due to the possible existence of
|
||||
such a cycle, we need training methods that are more complex and methods
|
||||
that are designed for multiagent learning to achieve our objective.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-marl-sp`
|
||||
|
||||
Generally, multiagent reinforcement learning is more complex than
|
||||
@@ -140,7 +140,7 @@ an optimal strategy based on its opponent's historical average
|
||||
strategies, and vice versa. In this manner, players can converge to Nash
|
||||
equilibrium strategy in games like rock-paper-scissors.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-marl-fsp`
|
||||
|
||||
[^1]: Assume that the agents use the same reward discount factor.
|
||||
|
||||
@@ -36,7 +36,7 @@ type of method relies on a distributed system to implement multi-agent
|
||||
training and gaming, reflecting the dependency of multi-agent
|
||||
reinforcement learning on distributed computing.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-marl-train`
|
||||
|
||||
Now, let's look at the difficulties involved in building a multi-agent
|
||||
@@ -195,5 +195,5 @@ training. While this example describes a distributed multi-agent system
|
||||
in general terms, there may be many different designs for different game
|
||||
types and algorithm structures in real-world applications.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-marl-sys`
|
||||
|
||||
@@ -42,7 +42,7 @@ Figure :numref:`ch011/ch11-rl` shows the abstract process, which is the
|
||||
most common model description of reinforcement learning in the
|
||||
literature.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-rl`
|
||||
|
||||
Take video gaming as an example. A gamer needs to gradually become
|
||||
|
||||
@@ -67,7 +67,7 @@ discrete, continuous, or categorical. The three types of adapters are
|
||||
collectively referred to as adapters in Figure
|
||||
:numref:`ch011/ch11-rlzoo`.
|
||||
|
||||
|
||||
|
||||
:label:`ch011/ch11-rlzoo`
|
||||
|
||||
The policy networks and value networks constitute the core learning
|
||||
|
||||
@@ -13,10 +13,10 @@ chapter are as follows:
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
|
||||
Overview_of_Robotic_Systems
|
||||
Robot_Operating_System
|
||||
Case_Study
|
||||
Modern_Robot_Learning
|
||||
Chapter_Summary
|
||||
rl_sys_intro
|
||||
ros
|
||||
ros_code_ex
|
||||
robot_learning
|
||||
summary
|
||||
```
|
||||
|
||||
|
||||
@@ -42,7 +42,7 @@ decision strategy can be trained through re-parameterization. We will
|
||||
introduce the perception, planning, and control systems in the following
|
||||
subsections.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-learning_decision_module`
|
||||
|
||||
## Perception System
|
||||
@@ -100,7 +100,7 @@ frameworks have been proposed. TartanVO, which outperforms traditional
|
||||
geometry-based methods, is the first learning-based VO model that can be
|
||||
generalized to multiple datasets and real-world scenarios.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-orbslam3`
|
||||
|
||||
## Planning System
|
||||
@@ -136,7 +136,7 @@ Decision Process (POMDP) model for autonomous driving based on deep RL,
|
||||
covering important components such as the environment, reward, and
|
||||
agent.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-rl_ad`
|
||||
|
||||
## Control System
|
||||
@@ -188,7 +188,7 @@ a safe learning control system. Lyapunov functions can effectively
|
||||
evaluate the stability of nonlinear dynamical systems. Recently, neural
|
||||
Lyapunov has been proposed to take safety into account.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-safe_learning_control`
|
||||
|
||||
## Robot Safety
|
||||
|
||||
@@ -19,7 +19,7 @@ variation for a robot to expect to have an accurate model of its
|
||||
environment, the objects in it, or the skills required to manipulate
|
||||
them.
|
||||
|
||||
|
||||
|
||||
:label:`robot-framework`
|
||||
|
||||
## Robot Interaction Environments
|
||||
@@ -94,7 +94,7 @@ crucial for achieving successful transfer of learned policies from
|
||||
simulation to reality.
|
||||
|
||||
![Robot manipulation environments in real
|
||||
world [@geng2022end].](../img/ch13/realworld.pdf)
|
||||
world [@geng2022end].](../img/ch13/real-world.png)
|
||||
|
||||
### Hardware Considerations:
|
||||
:label:`hardware-considerations`
|
||||
@@ -237,7 +237,7 @@ an action in a given state.
|
||||
**Affordance Learning:**
|
||||
|
||||
![Affordance visualization results in robot manipulation
|
||||
tasks [@geng2022end].](../img/ch13/affordance.pdf)
|
||||
tasks [@geng2022end].](../img/ch13/affordance.png)
|
||||
|
||||
Affordance learning focuses on understanding the action possibilities
|
||||
that the environment offers to a
|
||||
|
||||
@@ -58,7 +58,7 @@ performance. The communication system of ROS 2 is based on the data
|
||||
distribution service (DDS), as shown in
|
||||
Figure :numref:`ch17/ch17-ROS2_arch`.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-ROS2_arch`
|
||||
|
||||
ROS 2 relies on combining workspaces using the shell environment.
|
||||
@@ -96,7 +96,7 @@ summarized as follows:
|
||||
3. Before a node goes offline, it also broadcasts the offline
|
||||
information to other nodes.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-ROS2_graph`
|
||||
|
||||
## ROS 2 Topics
|
||||
@@ -114,7 +114,7 @@ windows within rqt. Although we can run such tools in a traditional
|
||||
standalone manner, rqt makes it easier to manage the various types of
|
||||
windows on the screen simultaneously.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-ROS2_topics`
|
||||
|
||||
## ROS 2 Services
|
||||
@@ -131,7 +131,7 @@ providing a desired service and the service processes the request and
|
||||
generates a response, as shown in
|
||||
Figure :numref:`ch17/ch17-ROS2_services`.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-ROS2_services`
|
||||
|
||||
## ROS 2 Parameters
|
||||
@@ -158,7 +158,7 @@ an action goal can tell a robot to head for a position. The robot can
|
||||
send updates (i.e., feedback) while it navigates a path to the position,
|
||||
and then send a result message when it arrives at its destination.
|
||||
|
||||
|
||||
|
||||
:label:`ch17/ch17-ROS2_actions`
|
||||
|
||||
[^1]: https://docs.ros.org/en/foxy/Tutorials/Understanding-ROS2-Nodes.html
|
||||
|
||||
@@ -8,15 +8,16 @@ Machine Learning Systems: Design and Implementation (1st Edition)
|
||||
|
||||
```toc
|
||||
:maxdepth: 2
|
||||
:numbered:
|
||||
|
||||
chapter_preface/index
|
||||
|
||||
# Fundamentals
|
||||
chapter_introduction/index
|
||||
chapter_programming_interface/index
|
||||
chapter_computational_graph/index
|
||||
|
||||
chapter_preface_advanced/index
|
||||
|
||||
# Part I Framework Design
|
||||
[Overview](chapter_preface_advanced/index)
|
||||
chapter_frontend_and_ir/index
|
||||
chapter_backend_and_runtime/index
|
||||
chapter_accelerator/index
|
||||
@@ -24,18 +25,15 @@ chapter_data_processing/index
|
||||
chapter_model_deployment/index
|
||||
chapter_distributed_training/index
|
||||
|
||||
chapter_preface_extension/index
|
||||
|
||||
# Part II Application Scenarios
|
||||
[Overview](chapter_preface_extension/index)
|
||||
chapter_recommender_system/index
|
||||
chapter_federated_learning/index
|
||||
chapter_reinforcement_learning/index
|
||||
chapter_explainable_AI/index
|
||||
chapter_rl_sys/index
|
||||
|
||||
```
|
||||
|
||||
```toc
|
||||
:maxdepth: 1
|
||||
|
||||
# Appendix
|
||||
appendix_machine_learning_introduction/index
|
||||
```
|
||||
|
||||
|
||||
BIN
v1/img/ch07/7.5/distribute.png
Normal file
BIN
v1/img/ch07/7.5/distribute.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 73 KiB |
BIN
v1/img/ch08/distillation.png
Normal file
BIN
v1/img/ch08/distillation.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
Reference in New Issue
Block a user