From 00d04b7b6ef6bfa1cdb8f2ab74dbcb03a2592471 Mon Sep 17 00:00:00 2001 From: huan <3174348550@qq.com> Date: Mon, 14 Jul 2025 17:27:10 +0800 Subject: [PATCH] modify contents in files --- tutorials/source_en/beginner/save_load.md | 2 +- tutorials/source_en/compile/operators.md | 14 +++++------ .../compile/python_builtin_functions.md | 2 +- tutorials/source_en/compile/static_graph.md | 4 ++-- .../static_graph_expert_programming.md | 24 +++++++++---------- .../static_graph_expert_programming.ipynb | 16 ++++++------- 6 files changed, 31 insertions(+), 31 deletions(-) diff --git a/tutorials/source_en/beginner/save_load.md b/tutorials/source_en/beginner/save_load.md index 434f7ce05a..c3e1c75b16 100644 --- a/tutorials/source_en/beginner/save_load.md +++ b/tutorials/source_en/beginner/save_load.md @@ -27,7 +27,7 @@ def network(): ## Saving and Loading the Model Weight -Saving model by using the [mindspore.save_checkpoint](https://www.mindspore.cn/docs/en/master/api_python/mindspore/mindspore.save_checkpoint.html) interface, and the specified saving path of passing in the network: +Save model by using the [mindspore.save_checkpoint](https://www.mindspore.cn/docs/en/master/api_python/mindspore/mindspore.save_checkpoint.html) interface, and specify the saving path by passing in the network: ```python model = network() diff --git a/tutorials/source_en/compile/operators.md b/tutorials/source_en/compile/operators.md index c880450848..9dd6bb53e0 100644 --- a/tutorials/source_en/compile/operators.md +++ b/tutorials/source_en/compile/operators.md @@ -12,9 +12,9 @@ Arithmetic operators and assignment operators support the `Number` and `Tensor` | `-` | `Number`, `Tensor`, `COOTensor`, `CSRTensor`, taking negative values. | | `~` | `Tensor` with `bool` data type, members take negation one by one. | -notes: +Notes: -- In native python the `~` operator get the bitwise inversion of its integer argument; in MindSpore the `~` redefined to get logic not for `Tensor(Bool)`. +- In native python, the `~` operator get the bitwise inversion of its integer argument; in MindSpore, the `~` redefined to get logic not for `Tensor(Bool)`. ## Binary Arithmetic Operators @@ -79,7 +79,7 @@ Constraints: Restrictions: -- The left operand of operator `and`, `or` must be able to be converted to boolean value. For example, left operand can not be Tensor with multiple elements. If the left operand of `and`, `or` is variable `Tensor`, the right operand must also be single-element `Tensor` with the same type. Otherwise, there is no requirement for right operand. +- The left operand of operator `and` or `or` must be able to be converted to boolean value. For example, left operand can not be Tensor with multiple elements. If the left operand of `and` or `or` is variable `Tensor`, the right operand must also be single-element `Tensor` with the same type. Otherwise, there is no requirement for right operand. ## Compare Operators @@ -98,8 +98,8 @@ Restrictions: Restrictions: -- For operators `<`, `<=`, `>`, `>=`, `!=`, if all operators are `number` type, value of Number can't be `bool`. -- For operators `<`, `<=`, `>`, `>=`, `!=`, `==`, if all operands are `number` type, operations between `float64` and `int32` are not supported. -- For operators `<`, `<=`, `>`, `>=`, `!=`, `==`, if either operand is `tensor` type, left and right operands can't both be `bool` value. -- For operator `==`, if all operands are `number` type, support both `number` have `bool` value, not support only one `number` has `bool` value. +- For operators `<`, `<=`, `>`, `>=`, `!=`, if all operators are of `number` type, value of Number can't be `bool`. +- For operators `<`, `<=`, `>`, `>=`, `!=`, `==`, if all operands are of `number` type, operations between `float64` and `int32` are not supported. +- For operators `<`, `<=`, `>`, `>=`, `!=`, `==`, if either operand is of `tensor` type, left and right operands can't both be `bool` value. +- For operator `==`, if all operands are of `number` type, support both `number` have `bool` value, not support only one `number` has `bool` value. - For operators `!=`, `==`, all supported types but `mstype` can compare with `none`. diff --git a/tutorials/source_en/compile/python_builtin_functions.md b/tutorials/source_en/compile/python_builtin_functions.md index 311948c99c..d155cc0af3 100644 --- a/tutorials/source_en/compile/python_builtin_functions.md +++ b/tutorials/source_en/compile/python_builtin_functions.md @@ -60,7 +60,7 @@ Function: Return the floating-point number based on the input number or string. Calling: `float(x=0)`. -Input parameter: `x` - the object need to be converted to floating number, the valid type of x includes `int`, `float`, `bool`, `str`, `Tensor` and third-party object (such as `numpy.ndarray`). +Input parameter: `x` - the object need to be converted to floating number, the valid types of x include `int`, `float`, `bool`, `str`, `Tensor` and third-party object (such as `numpy.ndarray`). Return value: the converted floating-point number. diff --git a/tutorials/source_en/compile/static_graph.md b/tutorials/source_en/compile/static_graph.md index b90993c9cc..40264e0861 100644 --- a/tutorials/source_en/compile/static_graph.md +++ b/tutorials/source_en/compile/static_graph.md @@ -84,7 +84,7 @@ nodes at compile time. Constants and variables are distinguished by their true v print(ret) ``` - In the above code, enter `a`, `b`, `c` are constants. + In the above code, the inputs `a`, `b`, `c` are constants. - The result of the constant operation is constant. For example: @@ -105,7 +105,7 @@ nodes at compile time. Constants and variables are distinguished by their true v print(ret) ``` - In the above code, enter `a`, `b`, `c` are constants. + In the above code, the inputs `a`, `b`, `c` are constants. - Constant operations obtain a constant result. For example: diff --git a/tutorials/source_en/compile/static_graph_expert_programming.md b/tutorials/source_en/compile/static_graph_expert_programming.md index 96809c4524..de0a0b2ae7 100644 --- a/tutorials/source_en/compile/static_graph_expert_programming.md +++ b/tutorials/source_en/compile/static_graph_expert_programming.md @@ -8,7 +8,7 @@ This chapter introduces some commonly used advanced programming techniques for s ### Using lazy_inline Decorator -The compilation process for neural network models often uses the default inline approach, which eventually unfolds the hierarchical code representation into a flat computational graph, seeking maximize compilation optimization, and simplifying the automatic differentiation as well as the logic of execution. The computational graph formed after inline contains all the computational nodes, which can be optimized in a larger scope, such as constant folding, node fusion, parallel analysis. It can also be better implemented for memory allocation, reducing memory requests and performance overhead. Although inline optimization helps much in runtime performance improvement, excessive inline also brings burden in compilation period. For example, as the number of computational graph nodes swells, the time consumption for executing pass grows dramatically. +The compilation process for neural network models often uses the default inline approach, which eventually unfolds the hierarchical code representation into a flat computational graph, seeking to maximize compilation optimization, as well as simplifying the automatic differentiation and the logic of execution. The computational graph formed after inline contains all the computational nodes, which can be optimized in a larger scope, such as constant folding, node fusion, and parallel analysis. It can also be better implemented for memory allocation, reducing memory requests and performance overhead. Although inline optimization greatly helps runtime performance, excessive inlining also brings a burden during the compilation period. For example, as the number of computational graph nodes swells, the time consumption for executing pass grows dramatically. In order to mitigate the loss of compilation performance caused by inline, we provide a Lazy Inline mechanism to reduce compilation time for scenarios where the same computation unit is called repeatedly (typically, different instances of the same Cell class are called in a for loop). @@ -37,7 +37,7 @@ class PipelineCell(nn.Cell): If we think of the loop body as a subgraph that is called frequently, and tell the compiler to defer inline processing by marking it as Lazy Inline, then we can achieve performance gains by drastically reducing the number of computational graph nodes during most phases of compilation. For example, the code above can preserve the subgraph structure of the `network` instance without inlining or without early inline, for which we provide the `@lazy_inline` decorator to implement delayed inlining. -Taking the Pangu_alpha network as an example, the `network` handled in the `PipelineCell` function body is an instance of the `PanGUAlphaWithLoss` class. In order to implement a delayed inline, a `@ lazy_inline` decorator is added to the `__init__` function of the `PanGUAlphaWithLoss` class to mark that the subgraph structure of the `PanGUAlphaWithLoss` class needs to be preserved without inlining or with delayed inlining. as shown below: +Taking the Pangu_alpha network as an example, the `network` handled in the `PipelineCell` function body is an instance of the `PanGUAlphaWithLoss` class. In order to implement a delayed inline, a `@lazy_inline` decorator is added to the `__init__` function of the `PanGUAlphaWithLoss` class to mark that the subgraph structure of the `PanGUAlphaWithLoss` class needs to be preserved without inlining or with delayed inlining. As shown below: ```python from mindspore import nn @@ -57,7 +57,7 @@ Still taking the Pangu 13B network as an example, after applying the Lazy Inline #### More General Scenarios -`@lazy_inline` is a decorator for `Cell::__init__`, which generates the attribute value of the Cell `cell_init_args` with all the parameters of `__init__`, and the same value of `cell_init_args` indicates that the Cell class name and the values of the initialization parameters are the same. And for instances of the same Cell class, their weights may also be different, so for a network structure defined with `construct(self, x)`, at actual compile time we can convert to `construct(x, self.cell_init_args, self.trainable_ parameters())`. For different instances of the same Cell class, if `cell_init_args` is the same, both instances can reuse the same network structure as follows: +`@lazy_inline` is a decorator for `Cell::__init__`, which generates the attribute value of the Cell `cell_init_args` with all the parameters of `__init__`, and the same value of `cell_init_args` indicates that the Cell class name and the values of the initialization parameters are the same. And for instances of the same Cell class, their weights may also be different, so for a network structure defined with `construct(self, x)`, at actual compile time we can convert to `construct(x, self.cell_init_args, self.trainable_parameters())`. For different instances of the same Cell class, if `cell_init_args` is the same, both instances can reuse the same network structure as follows: ```python def construct(self, x) @@ -223,14 +223,14 @@ y = ms.Tensor([2], dtype.float32) start_time = time.time() out = func(x, y) end_time = time.time() -print("Disable comile_cache cost time:", end_time - start_time) +print("Disable compile_cache cost time:", end_time - start_time) ``` The above test sample is to close the compilation cache state, execute the above test sample two times. The first time consumption and the second time consumption is as follows (the actual time consumption is related to the hardware environment, the following data is for reference only): ```text -Disable comile_cache cost time: 0.5485098361968994 -Disable comile_cache cost time: 0.4614279270172119 +Disable compile_cache cost time: 0.5485098361968994 +Disable compile_cache cost time: 0.4614279270172119 ``` It can be seen that when the compilation cache is turned off, the 2nd execution of the sample takes a little less time than the 1st. This is because the operator compilation cache is turned on by default and the 2nd execution of the sample is able to utilize the previous operator compilation cache. @@ -256,14 +256,14 @@ start_time = time.time() out = func(x, y) end_time = time.time() os.environ['MS_COMPILER_CACHE_ENABLE'] = '0' -print("Enable comile_cache cost time:", end_time - start_time) +print("Enable compile_cache cost time:", end_time - start_time) ``` The above test sample is to enable the compilation cache, execute the above test sample two times. The first time and the second time consumption is as follows (the actual time consumption is related to the hardware environment, and the following data is for reference only): ```text -Enable comile_cache cost time: 0.6357541084289551 -Enable comile_cache cost time: 0.09379792213439941 +Enable compile_cache cost time: 0.6357541084289551 +Enable compile_cache cost time: 0.09379792213439941 ``` As you can see, when compilation cache is enabled, the 2nd execution of the sample takes only about 1/7th of the time for the first execution. @@ -294,7 +294,7 @@ When a user defines a class in a network script, it can be written as a class in - a class decorated by `@jit_class` - The `@jit_class` decorator is provided in order to balance the user Python usage habits with the performance benefits of static graph compilation. After modifying the `@jit_class` decorator for a custom class, the function code of the class will be compiled into a static computational graph. Based on graph optimization, and static graph sinking, the compiler can globally optimize for the computational graph to obtain better execution performance. + The `@jit_class` decorator is provided in order to balance the user Python usage habits with the performance benefits of static graph compilation. After modifying the `@jit_class` decorator for a custom class, the function code of the class will be compiled into a static computational graph. Based on graph optimization and static graph sinking, the compiler can globally optimize for the computational graph to obtain better execution performance. In static graph mode, by modifying a custom class with `@jit_class`, the user can create, call instances of the class, and get its attributes and methods. @@ -348,7 +348,7 @@ The error message is as follows: TypeError: Decorator jit_class is used for user-defined classes and cannot be used for nn.Cell: Net<>. ``` -jit_class supports scenarios where custom classes are used nested, and custom classes are used nested with `Cell`. It should be noted that when class inherition occurs, if the parent class uses jit_class, the child class will also have the capabilities of jit_class. +jit_class supports scenarios where custom classes are used nested, and custom classes are used nested with `Cell`. It should be noted that when class inheritance occurs, if the parent class uses jit_class, the child class will also have the capabilities of jit_class. ```python import numpy as np @@ -522,7 +522,7 @@ Usage scenario: `Select` operator is used to replace if control flow statements, When writing networks, you will often use if statements, if the condition of the if statement is a variable condition, each if statement will generate additional subgraphs. In static graph mode, the higher the number of subgraphs, the longer the compilation takes, so some scenarios can be optimized for compilation performance by replacing the if statement equivalently with the `Select` operator. -Note that using the `Select` operator to replace the if statement affects the performance of the network. On the one hand, the `Select` operator executes both the true branch and the false branch, whereas the if statement executes only one of its branches, so the time comsuption with if decreases compared to that with the `Select` operator; on the other hand, the `Select` operator outperforms the control-flow operator generated by the if statement, and the time comsuption with if increases compared to that with the `Select` operator. operator. Combining the above two factors, the final runtime performance changes need to be judged according to the actual situation. Generally speaking, when the number of operators in a branch is small, it is recommended to use `Select` operator, while when the number of operators in a branch is large, it is recommended to use if statement. +Note that using the `Select` operator to replace the if statement affects the performance of the network. On the one hand, the `Select` operator executes both the true branch and the false branch, whereas the if statement executes only one of its branches, so the time consumption with if decreases compared to that with the `Select` operator; on the other hand, the `Select` operator outperforms the control-flow operator generated by the if statement, and the time consumption with if increases compared to that with the `Select` operator. Combining the above two factors, the final runtime performance changes need to be judged according to the actual situation. Generally speaking, when the number of operators in a branch is small, it is recommended to use `Select` operator, while when the number of operators in a branch is large, it is recommended to use if statement. A code sample that uses the `Select` operator instead of an if statement to optimize compilation performance is shown below: diff --git a/tutorials/source_zh_cn/compile/static_graph_expert_programming.ipynb b/tutorials/source_zh_cn/compile/static_graph_expert_programming.ipynb index 6ee7a4685e..9849ea0d98 100644 --- a/tutorials/source_zh_cn/compile/static_graph_expert_programming.ipynb +++ b/tutorials/source_zh_cn/compile/static_graph_expert_programming.ipynb @@ -283,7 +283,7 @@ "name": "stdout", "output_type": "stream", "text": [ - "Disable comile_cache cost time: 0.5485098361968994\n" + "Disable compile_cache cost time: 0.5485098361968994\n" ] } ], @@ -306,7 +306,7 @@ "start_time = time.time()\n", "out = func(x, y)\n", "end_time = time.time()\n", - "print(\"Disable comile_cache cost time:\", end_time - start_time)" + "print(\"Disable compile_cache cost time:\", end_time - start_time)" ] }, { @@ -317,8 +317,8 @@ "上述测试样例是关闭编译缓存状态，执行上述测试样例2次，第1次耗时和第2次耗时如下（实际耗时与硬件环境有关，以下数据仅供参考）：\n", "\n", "```text\n", - "Disable comile_cache cost time: 0.5485098361968994\n", - "Disable comile_cache cost time: 0.4614279270172119\n", + "Disable compile_cache cost time: 0.5485098361968994\n", + "Disable compile_cache cost time: 0.4614279270172119\n", "```" ] }, @@ -340,7 +340,7 @@ "name": "stdout", "output_type": "stream", "text": [ - "Enable comile_cache cost time: 0.6357541084289551\n" + "Enable compile_cache cost time: 0.6357541084289551\n" ] } ], @@ -365,7 +365,7 @@ "out = func(x, y)\n", "end_time = time.time()\n", "os.environ['MS_COMPILER_CACHE_ENABLE'] = '0'\n", - "print(\"Enable comile_cache cost time:\", end_time - start_time)" + "print(\"Enable compile_cache cost time:\", end_time - start_time)" ] }, { @@ -376,8 +376,8 @@ "上述测试样例是开启编译缓存状态，执行上述测试样例2次，第1次耗时和第2次耗时如下（实际耗时与硬件环境有关，以下数据仅供参考）：\n", "\n", "```text\n", - "Enable comile_cache cost time: 0.6357541084289551\n", - "Enable comile_cache cost time: 0.09379792213439941\n", + "Enable compile_cache cost time: 0.6357541084289551\n", + "Enable compile_cache cost time: 0.09379792213439941\n", "```\n", "\n", "可以看到，开启编译缓存时，第2次执行样例耗时只有第一次执行耗时的1/7左右。\n", -- Gitee