You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tvm.apache.org by GitBox <gi...@apache.org> on 2021/01/22 05:24:43 UTC
[GitHub] [tvm] tmoreau89 opened a new pull request #7326: [Tutorial] Autoscheduler on ARM devices
tmoreau89 opened a new pull request #7326:
URL: https://github.com/apache/tvm/pull/7326
This tutorial adapts the x86 autoscheduler tutorial to work over RPC and target aarch64-based Rapsberry Pi.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562814613
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
Review comment:
Excellent point, I'm fixing this. I also fixed the device typo, it should be 4b actually!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562840117
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
We can use this https://github.com/apache/tvm/blob/6787d7494f8815bce9523906935169f6385b9d93/python/tvm/auto_scheduler/utils.py#L242 for now.
Lifting them to a common place is a better soltuion later.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
We can use this https://github.com/apache/tvm/blob/6787d7494f8815bce9523906935169f6385b9d93/python/tvm/auto_scheduler/utils.py#L242 for now.
Lifting them to a common place is a better solution later.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766495174
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563202991
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.080 | 0.05 | 9 |
+# | 1 | 1.059 | 1.94 | 9 |
+# | 2 | 0.052 | -0.00 | 9 |
+# | 3 | 9.418 | 10.92 | 9 |
+# | 4 | - | - | 9 |
Review comment:
It means no valid schedules are found.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] comaniac commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
comaniac commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562972265
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.080 | 0.05 | 9 |
+# | 1 | 1.059 | 1.94 | 9 |
+# | 2 | 0.052 | -0.00 | 9 |
+# | 3 | 9.418 | 10.92 | 9 |
+# | 4 | - | - | 9 |
Review comment:
nit: might be better to explain what this dash means and when it may happen.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 edited a comment on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 edited a comment on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766495174
@merrymercy Verified autotuning vs. autoscheduling on mobilenet model from gluon model zoo: AutoTVM performance (1500 trials per task) is 78.06ms. Autoscheduler performance (20000 trials total) is 42.52ms.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] FrozenGene commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
FrozenGene commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563269092
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
The comment is not correct now. Should be if you want to use ndk tools to cross compile, set it be true. And we should add one line of code os.environ[“TVM_NDK_TOOLS”]. We could refer mali tutorials how about setting it. Sorry I don’t list it here, because I am using mobile phone to reply.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
The comment is not correct now. Should be if you want to use ndk tools to cross compile, set it be true. And we should add one line of code os.environ[“TVM_NDK_TOOL”]. We could refer mali tutorials how about setting it. Sorry I don’t list it here, because I am using mobile phone to reply.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562946754
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
Thanks @merrymercy I am now using this request_remote, there is no dependence of the autotvm lib in this tutorial anymore!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] comaniac commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
comaniac commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562801935
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
- It's a bit weird to see `autotvm` here. Maybe we should lift the common modules up to the top-level so that it can serve autotvm, auto_schedueler, and deployments.
- I didn't find the corresponding code of launching an RPC server at `0.0.0.0:9191` in this tutorial. How does this line work on the CI?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562840117
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
use this https://github.com/apache/tvm/blob/6787d7494f8815bce9523906935169f6385b9d93/python/tvm/auto_scheduler/utils.py#L242
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766614308
Thanks @tmoreau89 @leandron @comaniac @FrozenGene . It is merged.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766496099
@leandron @merrymercy @FrozenGene I've addressed your comments, please take a look
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563428964
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
Thank you I've addressed the issue, please take a look
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562816483
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
Review comment:
Thanks it now matches!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563224208
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
Review comment:
Thank you good point.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
Review comment:
Thank you I'll make the change.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
Review comment:
That will streamline it, thanks!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy merged pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy merged pull request #7326:
URL: https://github.com/apache/tvm/pull/7326
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] FrozenGene commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
FrozenGene commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563031514
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
Review comment:
I suggest naming `use_android` into `use_ndk`. Because for embed devices, we could still cross compile. In our mali tutorial, you could refer a bit more in our mali tutorial: https://tvm.apache.org/docs/tutorials/auto_scheduler/tune_network_mali.html
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
Review comment:
I think this will bring a bit confuse to users. I suggest we replace `using` into `sharing`.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
Review comment:
I think we could unify the `tune` and `compile` functions like we have done in the mali tutorial: https://tvm.apache.org/docs/tutorials/auto_scheduler/tune_network_mali.html
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562820343
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
Thank you @comaniac for the input! Great point with lifting common modules up from autotvm here. @merrymercy do you have opinions on this?
And great catch on requesting a remote in the tutorial, this code won't run in CI. I've commented it out so it doesn't run in CI.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766184383
Let us address comments from @FrozenGene and verify the performance. Then we can merge this.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] FrozenGene commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
FrozenGene commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563269092
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
The comment is not correct now.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563428964
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
Thank you I've addressed the issue, please take a look
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] FrozenGene commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
FrozenGene commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563269092
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,419 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_ndk` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# FIXME(tmoreau89, merrymercy): We leave '-device=arm_cpu' out of the target string
+# because we're sharing x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
Review comment:
The comment is not correct now. Should be if you want to use ndk tools to cross compile, set it be true. And we should add one line of code os.environ of TVM NDK Tool path. We could refer mali tutorials how about setting it. Sorry I don’t list it here, because I am using mobile phone to reply.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562998116
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.080 | 0.05 | 9 |
+# | 1 | 1.059 | 1.94 | 9 |
+# | 2 | 0.052 | -0.00 | 9 |
+# | 3 | 9.418 | 10.92 | 9 |
+# | 4 | - | - | 9 |
Review comment:
Good point, @merrymercy do you have suggestions here?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563202991
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.080 | 0.05 | 9 |
+# | 1 | 1.059 | 1.94 | 9 |
+# | 2 | 0.052 | -0.00 | 9 |
+# | 3 | 9.418 | 10.92 | 9 |
+# | 4 | - | - | 9 |
Review comment:
It means no valid schedules are found. All schedules are invalid or timeout.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] leandron commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
leandron commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562527228
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
Review comment:
I think it would be good to add a quick note on which OS are you using, plus a vital information for the toolchain - whether the OS is 32 or 64 bits.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
Review comment:
The mention here to `aarch64-linux-gnu` needs a bit more context, as there is no mention to it later.
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
Review comment:
The key for the example device, defined on line 218 is `rasp4b-64`, so this probably needs to match?
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
Review comment:
You mention Raspberry Pi 3 (line 207) in the comment above, maybe this need to encode that info, hence `rasp3b` maybe?
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
Review comment:
To keep the example coherent, it would be good also to update here when the key is updated.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562815223
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
Review comment:
Great catch I'm fixing the target here, which should have been `tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766495174
@merrymercy Verified autotuning vs. autoscheduling on mobilenet model from gluon model zoo: AutoTVM performance (1500 trials per task) is 78ms. Autoscheduler performance (20000 trials total) is 42.52ms.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 edited a comment on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 edited a comment on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766495174
@merrymercy Verified autotuning vs. autoscheduling on mobilenet model from gluon model zoo: AutoTVM performance (1500 trials per task) is 78.06ms. Autoscheduler performance (20000 trials total) is 42.52ms.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562815910
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
Review comment:
Yeah great point, I'm fixing this
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r563202991
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,431 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rasp4b-64
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 4B with 64bit OS, and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rasp4b-64 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 4b 4GB board
+# as example with a 64bit OS (Ubuntu 20.04). In your setting, you should modify the target
+# and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+# We leave '-device=arm_cpu' out because we're using x86 op strategy.
+target = tvm.target.Target("llvm -mtriple=aarch64-linux-gnu -mattr=+neon")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key,
+ host="0.0.0.0",
+ port=9191,
+ timeout=30,
+ repeat=1,
+ min_repeat_ms=200,
+ enable_cpu_cache_flush=True,
+ ),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.080 | 0.05 | 9 |
+# | 1 | 1.059 | 1.94 | 9 |
+# | 2 | 0.052 | -0.00 | 9 |
+# | 3 | 9.418 | 10.92 | 9 |
+# | 4 | - | - | 9 |
Review comment:
It means no valid schedules are found. All schedules are invalid or time out.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766274581
@merrymercy Thanks, I can run the eval of the mobilenet model on RPi4b between autoTVM and Ansor and report the results. Please give me a day or two to collect the results.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-765742685
Marking the PR as ready to review, thank you for the input so far @leandron @comaniac @merrymercy
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#issuecomment-766614308
Thanks @tmoreau89 @leandron @comaniac @FrozenGene . It is merged.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] tmoreau89 commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
tmoreau89 commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562816620
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
Review comment:
Yes, fixed, thank you!
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy merged pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy merged pull request #7326:
URL: https://github.com/apache/tvm/pull/7326
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [tvm] merrymercy commented on a change in pull request #7326: [Tutorial] Autoscheduler on ARM devices
Posted by GitBox <gi...@apache.org>.
merrymercy commented on a change in pull request #7326:
URL: https://github.com/apache/tvm/pull/7326#discussion_r562840117
##########
File path: tutorials/auto_scheduler/tune_network_arm.py
##########
@@ -0,0 +1,420 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+"""
+Auto-scheduling a Neural Network for ARM CPU
+=============================================
+**Author**: `Thierry Moreau <https://github.com/tmoreau89, Lianmin Zheng <https://github.com/merrymercy>>`_
+
+Auto-tuning for specific devices and workloads is critical for getting the
+best performance. This is a tutorial on how to tune a whole neural
+network for ARM CPU with the auto-scheduler via RPC.
+
+To auto-tune a neural network, we partition the network into small subgraphs and
+tune them independently. Each subgraph is treated as one search task.
+A task scheduler slices the time and dynamically allocates time resources to
+these tasks. The task scheduler predicts the impact of each task on the end-to-end
+execution time and prioritizes the one that can reduce the execution time the most.
+
+For each subgraph, we use the compute declaration in :code:`tvm/python/topi` to
+get the computational DAG in the tensor expression form.
+We then use the auto-scheduler to construct a search space of this DAG and search
+for good schedules (low-level optimizations).
+
+Different from the template-based :ref:`autotvm <tutorials-autotvm-sec>` which relies on
+manual templates to define the search space, the auto-scheduler does not require any
+schedule templates. In other words, the auto-scheduler only uses the compute declarations
+in :code:`tvm/python/topi` and does not use existing schedule templates.
+
+Note that this tutorial will not run on Windows or recent versions of macOS. To
+get it to run, you will need to wrap the body of this tutorial in a :code:`if
+__name__ == "__main__":` block.
+"""
+
+import numpy as np
+
+import tvm
+from tvm import relay, auto_scheduler, autotvm
+import tvm.relay.testing
+from tvm.contrib import graph_runtime
+from tvm.contrib.utils import tempdir
+
+#################################################################
+# Define a Network
+# ----------------
+# First, we need to define the network with relay frontend API.
+# We can load some pre-defined network from :code:`tvm.relay.testing`.
+# We can also load models from MXNet, ONNX, PyTorch, and TensorFlow
+# (see :ref:`front end tutorials<tutorial-frontend>`).
+#
+# For convolutional neural networks, although auto-scheduler can work correctly
+# with any layout, we found the best performance is typically achieved with NHWC layout.
+# We also implemented more optimizations for NHWC layout with the auto-scheduler.
+# So it is recommended to convert your models to NHWC layout to use the auto-scheduler.
+# You can use :ref:`ConvertLayout <convert-layout-usage>` pass to do the layout conversion in TVM.
+
+
+def get_network(name, batch_size, layout="NHWC", dtype="float32"):
+ """Get the symbol definition and random weight of a network"""
+
+ # auto-scheduler prefers NHWC layout
+ if layout == "NHWC":
+ image_shape = (224, 224, 3)
+ elif layout == "NCHW":
+ image_shape = (3, 224, 224)
+ else:
+ raise ValueError("Invalid layout: " + layout)
+
+ input_shape = (batch_size,) + image_shape
+ output_shape = (batch_size, 1000)
+
+ if name.startswith("resnet-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name.startswith("resnet3d-"):
+ n_layer = int(name.split("-")[1])
+ mod, params = relay.testing.resnet.get_workload(
+ num_layers=n_layer,
+ batch_size=batch_size,
+ layout=layout,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "mobilenet":
+ mod, params = relay.testing.mobilenet.get_workload(
+ batch_size=batch_size, layout=layout, dtype=dtype, image_shape=image_shape
+ )
+ elif name == "squeezenet_v1.1":
+ assert layout == "NCHW", "squeezenet_v1.1 only supports NCHW layout"
+ mod, params = relay.testing.squeezenet.get_workload(
+ version="1.1",
+ batch_size=batch_size,
+ dtype=dtype,
+ image_shape=image_shape,
+ )
+ elif name == "inception_v3":
+ input_shape = (batch_size, 3, 299, 299) if layout == "NCHW" else (batch_size, 299, 299, 3)
+ mod, params = relay.testing.inception_v3.get_workload(batch_size=batch_size, dtype=dtype)
+ elif name == "mxnet":
+ # an example for mxnet model
+ from mxnet.gluon.model_zoo.vision import get_model
+
+ assert layout == "NCHW"
+
+ block = get_model("resnet50_v1", pretrained=True)
+ mod, params = relay.frontend.from_mxnet(block, shape={"data": input_shape}, dtype=dtype)
+ net = mod["main"]
+ net = relay.Function(
+ net.params, relay.nn.softmax(net.body), None, net.type_params, net.attrs
+ )
+ mod = tvm.IRModule.from_expr(net)
+
+ return mod, params, input_shape, output_shape
+
+
+#################################################################
+# Start RPC Tracker
+# -----------------
+# TVM uses RPC session to communicate with ARM boards.
+# During tuning, the tuner will send the generated code to the board and
+# measure the speed of code on the board.
+#
+# To scale up the tuning, TVM uses RPC Tracker to manage distributed devices.
+# The RPC Tracker is a centralized controller node. We can register all devices to
+# the tracker. For example, if we have 10 phones, we can register all of them
+# to the tracker, and run 10 measurements in parallel, accelerating the tuning process.
+#
+# To start an RPC tracker, run this command on the host machine. The tracker is
+# required during the whole tuning process, so we need to open a new terminal for
+# this command:
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_tracker --host=0.0.0.0 --port=9190
+#
+# The expected output is
+#
+# .. code-block:: bash
+#
+# INFO:RPCTracker:bind to 0.0.0.0:9190
+
+#################################################################
+# Register Devices to RPC Tracker
+# -----------------------------------
+# Now we can register our devices to the tracker. The first step is to
+# build the TVM runtime for the ARM devices.
+#
+# * For Linux:
+# Follow this section :ref:`build-tvm-runtime-on-device` to build
+# the TVM runtime on the device. Then register the device to tracker by
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.rpc_server --tracker=[HOST_IP]:9190 --key=rk3399
+#
+# (replace :code:`[HOST_IP]` with the IP address of your host machine)
+#
+# * For Android:
+# Follow this `readme page <https://github.com/apache/tvm/tree/main/apps/android_rpc>`_ to
+# install the TVM RPC APK on the android device. Make sure you can pass the android rpc test.
+# Then you have already registered your device. During tuning, you have to go to developer option
+# and enable "Keep screen awake during changing" and charge your phone to make it stable.
+#
+# After registering devices, we can confirm it by querying rpc_tracker
+#
+# .. code-block:: bash
+#
+# python -m tvm.exec.query_rpc_tracker --host=0.0.0.0 --port=9190
+#
+# For example, if we have 2 Huawei mate10 pro, 11 Raspberry Pi 3B and 2 rk3399,
+# the output can be
+#
+# .. code-block:: bash
+#
+# Queue Status
+# ----------------------------------
+# key total free pending
+# ----------------------------------
+# mate10pro 2 2 0
+# rk3399 2 2 0
+# rpi3b 11 11 0
+# ----------------------------------
+#
+# You can register multiple devices to the tracker to accelerate the measurement in tuning.
+
+###########################################
+# Set Tuning Options
+# ------------------
+# Before tuning, we should apply some configurations. Here I use a Raspberry Pi 3b 4GB board
+# as example. In your setting, you should modify the target and device_key accordingly.
+# set :code:`use_android` to True if you use android phone.
+
+#### DEVICE CONFIG ####
+
+# Replace "aarch64-linux-gnu" with the correct target of your board.
+# This target is used for cross compilation. You can query it by :code:`gcc -v` on your device.
+target = tvm.target.arm_cpu("rasp4b64")
+
+# Also replace this with the device key in your tracker
+device_key = "rasp4b-64"
+
+# Set this to True if you use android phone
+use_android = False
+
+#### TUNING OPTION ####
+network = "mobilenet"
+batch_size = 1
+layout = "NHWC"
+dtype = "float32"
+log_file = "%s-%s-B%d-%s.json" % (network, layout, batch_size, target.kind.name)
+
+#################################################################
+# Extract Search Tasks
+# --------------------
+# Next, we extract the search tasks and their weights from a network.
+# The weight of a task is the number of appearances of the task's subgraph
+# in the whole network.
+# By using the weight, we can approximate the end-to-end latency of the network
+# as :code:`sum(latency[t] * weight[t])`, where :code:`latency[t]` is the
+# latency of a task and :code:`weight[t]` is the weight of the task.
+# The task scheduler will just optimize this objective.
+
+# Extract tasks from the network
+print("Extract tasks...")
+mod, params, input_shape, output_shape = get_network(network, batch_size, layout, dtype=dtype)
+tasks, task_weights = auto_scheduler.extract_tasks(mod["main"], params, target)
+
+for idx, task in enumerate(tasks):
+ print("========== Task %d (workload key: %s) ==========" % (idx, task.workload_key))
+ print(task.compute_dag)
+
+
+#################################################################
+# Begin Tuning
+# ------------
+# Now, we set some options for tuning and launch the search tasks
+#
+# * :code:`num_measure_trials` is the number of measurement trials we can use during the tuning.
+# You can set it to a small number (e.g., 200) for a fast demonstrative run.
+# In practice, we recommend setting it around :code:`800 * len(tasks)`,
+# which is typically enough for the search to converge.
+# For example, there are 29 tasks in resnet-50, so we can set it as 20000.
+# You can adjust this parameter according to your time budget.
+# * In addition, we use :code:`RecordToFile` to dump measurement records into a log file,
+# The measurement records can be used to query the history best, resume the search,
+# and do more analyses later.
+# * see :any:`auto_scheduler.TuningOptions`,
+# :any:`auto_scheduler.LocalRunner` for more parameters.
+#
+
+
+def run_tuning():
+ print("Begin tuning...")
+ tuner = auto_scheduler.TaskScheduler(tasks, task_weights)
+ tune_option = auto_scheduler.TuningOptions(
+ num_measure_trials=200, # change this to 20000 to achieve the best performance
+ runner=auto_scheduler.RPCRunner(
+ device_key, host='0.0.0.0', port=9191,
+ timeout=30,
+ repeat=10,
+ enable_cpu_cache_flush=True),
+ measure_callbacks=[auto_scheduler.RecordToFile(log_file)],
+ )
+
+ tuner.tune(tune_option)
+
+
+# We do not run the tuning in our webpage server since it takes too long.
+# Uncomment the following line to run it by yourself.
+
+# run_tuning()
+
+
+######################################################################
+# .. note:: Explain the printed information during tuning
+#
+# During the tuning, a lot of information will be printed on the console.
+# They are used for debugging purposes. The most important info is the output
+# of the task scheduler. The following table is a sample output.
+#
+# .. code-block:: c
+#
+# ----------------------------------------------------------------------
+# ------------------------------ [ Task Scheduler ]
+# ----------------------------------------------------------------------
+# | ID | Latency (ms) | Speed (GFLOPS) | Trials |
+# -------------------------------------------------
+# | 0 | 0.010 | 0.40 | 64 |
+# | 1 | 0.087 | 47.19 | 64 |
+# | 2 | 0.008 | -0.00 | 64 |
+# | 3 | 0.177 | 582.07 | 64 |
+# | 4 | 0.268 | 862.37 | 256 |
+# | 5 | 0.166 | 621.13 | 128 |
+# | 6 | 0.170 | 605.10 | 128 |
+# | 7 | 0.128 | 403.20 | 64 |
+# | 8 | 0.189 | 545.71 | 64 |
+# | 9 | 0.231 | 1001.01 | 448 |
+# | 10 | 0.155 | 664.80 | 256 |
+# | 11 | 0.155 | 662.86 | 256 |
+# | 12 | 0.119 | 434.08 | 64 |
+# | 13 | 0.199 | 522.13 | 64 |
+# | 14 | 0.235 | 986.56 | 320 |
+# | 15 | 0.149 | 689.13 | 128 |
+# | 16 | 0.155 | 664.80 | 192 |
+# | 17 | 0.151 | 340.64 | 64 |
+# | 18 | 0.176 | 597.55 | 128 |
+# | 19 | 0.220 | 1054.37 | 192 |
+# | 20 | 0.150 | 686.01 | 128 |
+# | 21 | 0.159 | 650.88 | 128 |
+# | 22 | 0.073 | 358.19 | 64 |
+# | 23 | 0.031 | 70.63 | 64 |
+# | 24 | 0.251 | 947.73 | 128 |
+# | 25 | 0.157 | 652.47 | 128 |
+# | 26 | 0.215 | 954.84 | 128 |
+# | 27 | 0.237 | 868.92 | 128 |
+# | 28 | 0.266 | 774.06 | 128 |
+# -------------------------------------------------
+# Estimated total latency: 10.016 ms Trials: 3992 Used time : 1131 s Next ID: 15
+#
+# This table lists the latency and (estimated) speed of all tasks.
+# It also lists the allocation of measurement trials for all tasks.
+# The last line prints the total weighted latency of these tasks,
+# which can be a rough estimation of the end-to-end execution time
+# of the network.
+# The last line also prints the total number of measurement trials,
+# total time spent on auto-tuning and the id of the next task to tune.
+#
+# There will also be some "dmlc::Error"s errors, because the
+# auto-scheduler will try some invalid schedules.
+# You can safely ignore them if the tuning can continue, because these
+# errors are isolated from the main process.
+#
+
+######################################################################
+# .. note:: Terminate the tuning earlier
+#
+# You can terminate the tuning earlier by forcibly killing this process.
+# As long as you get at least one valid schedule for each task in the log file,
+# you should be able to do the compilation (the secion below).
+#
+
+
+#################################################################
+# Compile and Evaluate
+# --------------------
+# After auto-tuning, we can compile the network with the best schedules we found.
+# All measurement records are dumped into the log file during auto-tuning,
+# so we can read the log file and load the best schedules.
+
+# Compile with the history best
+print("Compile...")
+with auto_scheduler.ApplyHistoryBest(log_file):
+ with tvm.transform.PassContext(opt_level=3, config={"relay.backend.use_auto_scheduler": True}):
+ lib = relay.build(mod, target=target, params=params)
+
+# Export library
+tmp = tempdir()
+if use_android:
+ from tvm.contrib import ndk
+
+ filename = "net.so"
+ lib.export_library(tmp.relpath(filename), ndk.create_shared)
+else:
+ filename = "net.tar"
+ lib.export_library(tmp.relpath(filename))
+
+# Upload module to device
+print("Upload...")
+remote = autotvm.measure.request_remote(device_key, "0.0.0.0", 9191, timeout=10000)
Review comment:
We can use this https://github.com/apache/tvm/blob/6787d7494f8815bce9523906935169f6385b9d93/python/tvm/auto_scheduler/utils.py#L242 for now.
Lift them to a common place is a better soltuion later.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org