executorch->ExecuTorch, other nits (#953)

lucylq · facebook-github-bot · commit 39c7e61df9e1 · 2023-10-16T15:33:05.000-07:00
Summary: Pull Request resolved: #953 ^ Reviewed By: larryliu0820 Differential Revision: D50329761 fbshipit-source-id: c3c2718eba5af987b17935a2a515fb7e05db6229
diff --git a/docs/source/concepts.md b/docs/source/concepts.md
@@ -259,7 +259,7 @@ A quantization technique where the model is quantized after it has been trained
 
 Models may lose accuracy after quantization. QAT enables higher accuracy compared to eg. PTQ, by modeling the effects of quantization while training. During training, all weights and activations are ‘fake quantized’; float values are rounded to mimic int8 values, but all computations are still done with floating point numbers. Thus, all weight adjustments during training are made ‘aware’ that the model will ultimately be quantized. QAT applies the quantization flow during training, in contrast to PTQ which applies it afterwards.
 
-## Quantization
+## [Quantization](./quantization-overview.md)
 
 Techniques for performing computations and memory accesses on tensors with lower precision data, usually `int8`. Quantization improves model performance by lowering the memory usage and (usually) decreasing computational latency; depending on the hardware, computation done in lower precision will typically be faster, e.g. `int8` matmul vs `fp32` matmul. Often, quantization comes at the cost of model accuracy.
 
diff --git a/docs/source/quantization-overview.md b/docs/source/quantization-overview.md
@@ -1,16 +1,16 @@
 # Quantization Overview
-Quantization is a process that reduces the precision of computations and lowers memory footprint in the model. To learn more, please visit the [ExecuTorch concepts page](./concepts.md#quantization). This is particularly useful for edge devices, which typically have limited resources such as processing power, memory, and battery life. By using quantization, we can make our models more efficient and enable them to run effectively on these devices.
+Quantization is a process that reduces the precision of computations and lowers memory footprint in the model. To learn more, please visit the [ExecuTorch concepts page](./concepts.md#quantization). This is particularly useful for edge devices including wearables, embedded devices and microcontrollers, which typically have limited resources such as processing power, memory, and battery life. By using quantization, we can make our models more efficient and enable them to run effectively on these devices.
 
 In terms of flow, quantization happens early in the ExecuTorch stack:
 
-![ExecuTorch Entry Points](/_static/img/executorch-entry-points.png).
+![ExecuTorch Entry Points](/_static/img/executorch-entry-points.png)
 
 A more detailed workflow can be found in the [ExecuTorch tutorial](./tutorials/export-to-executorch-tutorial).
 
 Quantization is usually tied to execution backends that have quantized operators implemented. Thus each backend is opinionated about how the model should be quantized, expressed in a backend specific ``Quantizer`` class. ``Quantizer`` provides API for modeling users in terms of how they want their model to be quantized and also passes on the user intention to quantization workflow.
 
-Backend developers will need to implement their own ``Quantizer`` to express how different operators or operator patterns are quantized in their backend. This is accomplished via [Annotation API](https://pytorch.org/tutorials/prototype/pt2e_quantizer.html) provided by quantization workflow. Since Quantizer is also user facing, it will expose specific APIs for modeling users to configure how they want the model to be quantized. Each backend should provide their own API documentation for their ``Quantizer``.
+Backend developers will need to implement their own ``Quantizer`` to express how different operators or operator patterns are quantized in their backend. This is accomplished via [Annotation API](https://pytorch.org/tutorials/prototype/pt2e_quantizer.html) provided by quantization workflow. Since ``Quantizer`` is also user facing, it will expose specific APIs for modeling users to configure how they want the model to be quantized. Each backend should provide their own API documentation for their ``Quantizer``.
 
-Modeling user will use the ``Quantizer`` specific to their target backend to quantize their model, e.g. ``XNNPACKQuantizer``.
+Modeling users will use the ``Quantizer`` specific to their target backend to quantize their model, e.g. ``XNNPACKQuantizer``.
 
-For an example quantization flow with ``XNPACKQuantizer``, more docuemntations and tutorials, please see ``Performing Quantization`` section in [ExecuTorch tutorial](./tutorials/export-to-executorch-tutorial).
+For an example quantization flow with ``XNPACKQuantizer``, more documentation and tutorials, please see ``Performing Quantization`` section in [ExecuTorch tutorial](./tutorials/export-to-executorch-tutorial).
diff --git a/docs/source/running-a-model-cpp-tutorial.md b/docs/source/running-a-model-cpp-tutorial.md
@@ -133,7 +133,7 @@ assert(execute_error == Error::Ok);
 
 ## Retrieve Outputs
 
-Once our inference completes we can retrieve our output. We know that our model only returns a single output tensor. One potential pitfall here is that the output we get back is owned by the `Method`. Users should take care to clone their output before performing any mutations on it, or if they need it to have a lifespan seperate from the `Method`.
+Once our inference completes we can retrieve our output. We know that our model only returns a single output tensor. One potential pitfall here is that the output we get back is owned by the `Method`. Users should take care to clone their output before performing any mutations on it, or if they need it to have a lifespan separate from the `Method`.
 
 ``` cpp
 EValue output = method->get_output(0);
diff --git a/runtime/core/memory_allocator.h b/runtime/core/memory_allocator.h
@@ -33,7 +33,7 @@ namespace executor {
  *   MemoryAllocator allocator(100, memory_pool)
  *   // Pass allocator object in the Executor
  *
- *   Underneath the hood, ExecuTorch will
+ *   Underneath the hood, ExecuTorch will call
  *   allocator.allocate() to keep iterating cur_ pointer
  */
 class MemoryAllocator {
@@ -46,8 +46,8 @@ class MemoryAllocator {
   static constexpr size_t kDefaultAlignment = alignof(void*);
 
   /**
-   * Constructs a new memory allocator of a given 'size', starting at the
-   * provided 'base_address'.
+   * Constructs a new memory allocator of a given `size`, starting at the
+   * provided `base_address`.
    *
    * @param[in] size The size in bytes of the buffer at `base_address`.
    * @param[in] base_address The buffer to allocate from. Does not take
@@ -121,7 +121,7 @@ class MemoryAllocator {
   }
 
   /**
-   * Allocates 'size' number of chunks of type T, where each chunk is of size
+   * Allocates `size` number of chunks of type T, where each chunk is of size
    * equal to sizeof(T) bytes.
    *
    * @param[in] size Number of memory chunks to allocate.
diff --git a/runtime/executor/memory_manager.h b/runtime/executor/memory_manager.h
@@ -93,7 +93,7 @@ class MemoryManager final {
   }
 
   /**
-   * Returns the allocator to use to allocate temporary data during kernel or
+   * Returns the allocator to use for allocating temporary data during kernel or
    * delegate execution.
    *
    * This allocator will be reset after every kernel or delegate call during
diff --git a/runtime/executor/program.h b/runtime/executor/program.h
@@ -175,23 +175,23 @@ class Program final {
       const char* method_name = "forward") const;
 
   /**
-   * Describes the presence of an executorch program header.
+   * Describes the presence of an ExecuTorch program header.
    */
   enum HeaderStatus {
     /**
-     * An executorch program header is present, and its version is compatible
+     * An ExecuTorch program header is present, and its version is compatible
      * with this version of the runtime.
      */
     CompatibleVersion,
 
     /**
-     * An executorch program header is present, but its version is not
+     * An ExecuTorch program header is present, but its version is not
      * compatible with this version of the runtime.
      */
     IncompatibleVersion,
 
     /**
-     * An executorch program header is not present.
+     * An ExecuTorch program header is not present.
      */
     NotPresent,
 
@@ -207,10 +207,10 @@ class Program final {
   static constexpr size_t kMinHeadBytes = 64;
 
   /**
-   * Looks for an executorch program header in the provided data.
+   * Looks for an ExecuTorch program header in the provided data.
    *
    * @param[in] data The data from the beginning of a file that might contain
-   *     an executorch program.
+   *     an ExecuTorch program.
    * @param[in] size The size of `data` in bytes. Must be >= `kMinHeadBytes`.
    *
    * @returns A value describing the presence of a header in the data.

Original file line number	Diff line number	Diff line change
`@@ -93,7 +93,7 @@ class MemoryManager final {`
`93`	`93`	`}`
`94`	`94`
`95`	`95`	`/**`
`96`		`- * Returns the allocator to use to allocate temporary data during kernel or`
	`96`	`+ * Returns the allocator to use for allocating temporary data during kernel or`
`97`	`97`	`* delegate execution.`
`98`	`98`	`*`
`99`	`99`	`* This allocator will be reset after every kernel or delegate call during`