前情阐明
本作业基于Windows版MindStudio 5.0.RC3,近程连贯ECS服务器应用,ECS是基于官网分享的CANN6.0.RC1_MindX_Vision3.0.RC3镜像创立的。
基于ECS(Ascend310)的U-Net网络的图像宰割
1. U-Net网络介绍:
U-Net模型基于二维图像宰割。在2015年ISBI细胞跟踪比赛中,U-Net取得了许多最佳奖项。论文中提出了一种用于医学图像宰割的网络模型和数据加强办法,无效利用标注数据来解决医学畛域标注数据有余的问题。U型网络结构也用于提取上下文和地位信息。
2. ECS运行阐明
咱们的操作根本都在root用户下执行。
首先,批改bash,具体命令和后果如下。
本我的项目反对MindStudio运行和终端运行。
(1)下载我的项目代码
下载链接:https://alexed.obs.cn-north-4...
将我的项目文件unet_sdk.zip上传至华为云ECS弹性云服务器/root/目录下,并解压;或者下载到本地电脑,用MindStudio关上。
将之前unet_hw960_bs1.air模型放到/unet_sdk/model/目录下。
我的项目文件构造
├── unet_sdk ├── README.md ├── data //数据集 │ ├── 1 │ │ ├──image.png //图片 │ │ ├──mask.png //标签│ ... ├── model │ ├──air2om.sh // air模型转om脚本 │ ├──xxx.air //air模型 │ ├──xxx.om //om模型 │ ├──aipp_unet_simple_opencv.cfg // aipp文件 ├── pipeline │ ├──unet_simple_opencv.pipeline // pipeline文件 ├── main.py // 推理文件 ├── run.sh // 执行文件 ├── requirements.txt // 须要的三方库
(2) 模型转换
将unet_hw960_bs1.air模型转为昇腾AI处理器反对的.om格局离线模型,此处模型转换须要用到ATC工具。
昇腾张量编译器(Ascend Tensor Compiler,简称ATC)是昇腾CANN架构体系下的模型转换工具,它能够将开源框架的网络模型或Ascend IR定义的单算子形容文件(json格局)转换为昇腾AI处理器反对的.om格局离线模型。模型转换过程中能够实现算子调度的优化、权值数据重排、内存应用优化等,能够脱离设施实现模型的预处理。
ATC参数概览:
(3) 运行脚本
运行脚本:
cd unet_sdk/model/ # 切换至模型存储目录atc --framework=1 --model=unet_hw960_bs1.air --output=unet_hw960_bs1 --input_format=NCHW --soc_version=Ascend310 --log=error --insert_op_conf=aipp_unet_simple_opencv.cfg
- 留神air模型转om只反对动态batch,这里batchsize=1。
参数阐明:
framework:原始框架类型。 model:原始模型文件门路与文件名。 output:转换后的离线模型的门路以及文件名。 input_format:输出数据格式。 soc_version:模型转换时指定芯片版本。 log:显示日志的级别。 insert_op_conf:插入算子的配置文件门路与文件名,这里应用AIPP预处理配置文件,用于图像数据预处理。
输入后果:
ATC run success,示意模型转换胜利,失去unet_hw960_bs1.om模型。
模型转换胜利之后,能够应用MindX SDK mxVision运行脚本,在Ascend 310上进行推理。
(4) MindX SDK mxVision 执行推理
MindX SDK文档请参考:https://support.huaweicloud.c...
MindX SDK执行推理的业务流程:
通过stream配置文件,Stream manager可辨认须要构建的element以及element之间的连贯关系,并启动业务流程。Stream manager对外提供接口,用于向stream发送数据和获取后果,帮忙用户实现业务对接。
plugin示意业务流程中的根底模块,通过element的串接构建成一个stream。buffer用于外部挂载解码前后的视频、图像数据,是element之间传递的数据结构,同时也容许用户挂载元数据(Metadata),用于寄存结构化数据(如指标检测后果)或过程数据(如缩放后的图像)。
MindX SDK根底概念介绍:
MindX SDK根底插件:
MindX SDK业务流程编排:
Stream配置文件以json格局编写,用户必须指定业务流名称、元件名称和插件名称,并依据须要,补充元件属性和上游元件名称信息。
以下表格为本试验pipeline/unet_simple_opencv.pipeline文件及其对应的名称及形容:
pipeline/unet_simple_opencv.pipeline文件内容如下,可依据理论开发状况进行批改。
{ "unet_mindspore": { "stream_config": { "deviceId": "0" }, "appsrc0": { "props": { "blocksize": "4096000" }, "factory": "appsrc", "next": "mxpi_imagedecoder0" }, "mxpi_imagedecoder0": { "props": { "cvProcessor": "opencv", "outputDataFormat": "BGR" }, "factory": "mxpi_imagedecoder", "next": "mxpi_imagecrop0" }, "mxpi_imagecrop0": { "props": { "cvProcessor": "opencv", "dataSource": "ExternalObjects" }, "factory": "mxpi_imagecrop", "next": "mxpi_imageresize0" }, "mxpi_imageresize0": { "props": { "handleMethod": "opencv", "resizeType": "Resizer_Stretch", "resizeHeight": "960", "resizeWidth": "960" }, "factory": "mxpi_imageresize", "next": "mxpi_tensorinfer0" }, "mxpi_tensorinfer0": { "props": { "dataSource": "mxpi_imageresize0", "modelPath": "model/unet_hw960_bs1_AIPP.om" }, "factory": "mxpi_tensorinfer", "next": "mxpi_dumpdata0" }, "mxpi_dumpdata0": { "props": { "requiredMetaDataKeys": "mxpi_tensorinfer0" }, "factory": "mxpi_dumpdata", "next": "appsink0" }, "appsink0": { "props": { "blocksize": "4096000" }, "factory": "appsink" } }}
(5) 批改modelPath
关上pipeline/unet_simple_opencv.pipeline文件,将"mxpi_tensorinfer0"元件的属性"modelPath"(模型导入门路)批改为模型转换后保留的om模型"model/unet_hw960_bs1.om"。
批改后果:
"modelPath": "model/unet_hw960_bs1.om"
modelPath批改实现之后,保留pipeline/unet_simple_opencv.pipeline文件。
StreamManagerApi:
StreamManagerApi文档请参考:
https://support.huaweicloud.c...
StreamManagerApi用于对Stream流程的根本治理:加载流程配置、创立流程、向流程发送数据、取得执行后果、销毁流程。
这里用到的StreamManagerApi有:
- InitManager:初始化一个StreamManagerApi。
- CreateMultipleStreams:依据指定的配置创立多个Stream。
- SendData:向指定Stream上的输出元件发送数据(appsrc)。
- GetResult:取得Stream上的输入元件的后果(appsink)
- DestroyAllStreams:销毁所有的流数据。
main.py文件内容如下,可依据理论开发状况进行批改。
import argparseimport base64import jsonimport osimport cv2import numpy as npfrom StreamManagerApi import *import MxpiDataType_pb2 as MxpiDataTypex0 = 2200 # w:2200~4000; h:1000~2800y0 = 1000x1 = 4000y1 = 2800ori_w = x1 - x0ori_h = y1 - y0def _parse_arg(): parser = argparse.ArgumentParser(description="SDK infer") parser.add_argument("-d", "--dataset", type=str, default="data/", help="Specify the directory of dataset") parser.add_argument("-p", "--pipeline", type=str, default="pipeline/unet_simple_opencv.pipeline", help="Specify the path of pipeline file") return parser.parse_args()def _get_dataset(dataset_dir): img_ids = sorted(next(os.walk(dataset_dir))[1]) for img_id in img_ids: img_path = os.path.join(dataset_dir, img_id) yield img_pathdef _process_mask(mask_path): # 手动裁剪 mask = cv2.imread(mask_path, cv2.IMREAD_GRAYSCALE)[y0:y1, x0:x1] return maskdef _get_stream_manager(pipeline_path): stream_mgr_api = StreamManagerApi() ret = stream_mgr_api.InitManager() #初始化stream if ret != 0: print(f"Failed to init Stream manager, ret={ret}") exit(1) with open(pipeline_path, 'rb') as f: pipeline_content = f.read() ret = stream_mgr_api.CreateMultipleStreams(pipeline_content) # 创立stream if ret != 0: print(f"Failed to create stream, ret={ret}") exit(1) return stream_mgr_apidef _do_infer_image(stream_mgr_api, image_path): stream_name = b'unet_mindspore' # 与pipeline中stream name统一 data_input = MxDataInput() with open(image_path, 'rb') as f: data_input.data = f.read() # 插入抠图的性能,扣1800*1800大小 roiVector = RoiBoxVector() roi = RoiBox() roi.x0 = x0 roi.y0 = y0 roi.x1 = x1 roi.y1 = y1 roiVector.push_back(roi) data_input.roiBoxs = roiVector unique_id = stream_mgr_api.SendData(stream_name, 0, data_input) # 向指定Stream上的输出元件发送数据(appsrc) if unique_id < 0: print("Failed to send data to stream.") exit(1) infer_result = stream_mgr_api.GetResult(stream_name, unique_id) # 取得Stream上的输入元件的后果(appsink) if infer_result.errorCode != 0: print(f"GetResult error. errorCode={infer_result.errorCode}," f"errorMsg={infer_result.data.decode()}") exit(1) # 用dumpdata获取数据 infer_result_data = json.loads(infer_result.data.decode()) content = json.loads(infer_result_data['metaData'][0]['content']) tensor_vec = content['tensorPackageVec'][0]['tensorVec'][1] # 1是argmax后果 data_str = tensor_vec['dataStr'] tensor_shape = tensor_vec['tensorShape'] argmax_res = np.frombuffer(base64.b64decode(data_str), dtype=np.float32).reshape(tensor_shape) np.save("argmax_result.npy", argmax_res) tensor_vec = content['tensorPackageVec'][0]['tensorVec'][0] # 0是softmax后果 data_str = tensor_vec['dataStr'] tensor_shape = tensor_vec['tensorShape'] softmax_res = np.frombuffer(base64.b64decode(data_str), dtype=np.float32).reshape(tensor_shape) np.save("softmax_result.npy", softmax_res) return softmax_res # ndarray# 自定义dice系数和iou函数def _calculate_accuracy(infer_image, mask_image): mask_image = cv2.resize(mask_image, infer_image.shape[1:3]) mask_image = mask_image / 255.0 mask_image = (mask_image > 0.5).astype(np.int) mask_image = (np.arange(2) == mask_image[..., None]).astype(np.int) infer_image = np.squeeze(infer_image, axis=0) inter = np.dot(infer_image.flatten(), mask_image.flatten()) union = np.dot(infer_image.flatten(), infer_image.flatten()) + \ np.dot(mask_image.flatten(), mask_image.flatten()) single_dice = 2 * float(inter) / float(union + 1e-6) single_iou = single_dice / (2 - single_dice) return single_dice, single_ioudef main(_args): dice_sum = 0.0 iou_sum = 0.0 cnt = 0 stream_mgr_api = _get_stream_manager(_args.pipeline) for image_path in _get_dataset(_args.dataset): infer_image = _do_infer_image(stream_mgr_api, os.path.join(image_path, 'image.png')) # 抠图并且reshape后的shape,1hw mask_image = _process_mask(os.path.join(image_path, 'mask.png')) # 抠图后的shape, hw dice, iou = _calculate_accuracy(infer_image, mask_image) dice_sum += dice iou_sum += iou cnt += 1 print(f"image: {image_path}, dice: {dice}, iou: {iou}") print(f"========== Cross Valid dice coeff is: {dice_sum / cnt}") print(f"========== Cross Valid IOU is: {iou_sum / cnt}") stream_mgr_api.DestroyAllStreams() # 销毁streamif __name__ == "__main__": args = _parse_arg() main(args)
run.sh文件内容如下,可依据理论开发状况进行批改。参考SDK软件包sample脚本,须要依照理论门路批改各个环境变量门路。
set -eCUR_PATH=$(cd "$(dirname "$0")" || { warn "Failed to check path/to/run.sh" ; exit ; } ; pwd)# Simple log helper functionsinfo() { echo -e "\033[1;34m[INFO ][MxStream] $1\033[1;37m" ; }warn() { echo >&2 -e "\033[1;31m[WARN ][MxStream] $1\033[1;37m" ; }#export MX_SDK_HOME=${CUR_PATH}/../../..export LD_LIBRARY_PATH=${MX_SDK_HOME}/lib:${MX_SDK_HOME}/opensource/lib:${MX_SDK_HOME}/opensource/lib64:/usr/local/Ascend/ascend-toolkit/latest/acllib/lib64:${LD_LIBRARY_PATH}export GST_PLUGIN_SCANNER=${MX_SDK_HOME}/opensource/libexec/gstreamer-1.0/gst-plugin-scannerexport GST_PLUGIN_PATH=${MX_SDK_HOME}/opensource/lib/gstreamer-1.0:${MX_SDK_HOME}/lib/plugins#to set PYTHONPATH, import the StreamManagerApi.pyexport PYTHONPATH=$PYTHONPATH:${MX_SDK_HOME}/pythonpython3 main.pyexit 0
(6) 运行脚本
激活mxVision环境变量(本作业无需此步骤):
. /root/mxVision/set_env.sh
运行脚本:
cd /root/unet_sdk/ # 切换至推理脚本目录bash run.sh
运行截图如下:
通过MindStudio运行,会主动上传代码到预设门路,并执行,运行后果如下:
MindStudio专家系统工具
专家系统工具以后反对专家系统自有知识库和生态知识库对模型/算子进行性能剖析,反对性能调优一键式闭环实现一键式性能问题优化能力。
专家系统自有知识库以后提供的性能:基于Roofline模型的算子瓶颈辨认与优化倡议、基于Timeline的AI CPU算子优化、算子交融举荐、TransData算子辨认和算子优化剖析。
生态知识库的专家系统性能调优性能:由生态开发者应用Python编程语言进行开发,用户通过调用专家系统提供的接口,对生态开发者提供的模型/算子进行性能剖析。
MindStudio IDE以后版本仅反对的生态知识库创立性能,能够在下面实现生态知识库代码开发,暂不反对对生态知识库的专家系统剖析性能。性能调优一键式闭环提供一键式性能问题剖析和优化能力,无效晋升用户性能剖析和优化效率。
上面介绍如何应用专家系统工具对模型和算子进行性能瓶颈辨认并输入优化倡议。
1. 单击菜单栏“Ascend > Advisor”,弹出专家系统工具界面 。如图所示。
2. 单击上图界面左上角红框中的按钮,关上专家系统配置界面,各参数配置示例如图所示。
各参数具体阐明如下:
3. 配置实现后单击“Start”启动剖析。
之后开始运行,如图所示,具体工夫与网络状况无关。
运行实现后,会主动跳转到如下图所示界面。
这里的Model Performance Report是模型性能的总结报告。依据该页面,能够晓得模型性能是好是坏,也能够晓得模型的吞吐率和运行工夫,AI Core的利用率,Tiling策略是否正当,局部字段阐明如下所示,具体可参见https://www.hiascend.com/docu...。
从上述截图的剖析后果能够看出咱们所用的U-Net模型的芯片利用率是偏低的,甚至能够说是很差,有很大的优化的空间。上面咱们来详细分析。
先来看依据总体性能数据汇总计算得出的Model Performance,显示为Bad,状况不乐观啊。接着看看汇总信息。
能够看到Cube吞吐量Cube Throughput约393 GOps,Vector吞吐量Vector Throughput约0.89 GOps,AI Core执行工夫88712us,工作执行工夫177183us,均匀BlockDim利用率Avg BlockDim Usage,算子执行时的均匀外围数,数值为1,这反映了反映芯片利用状况,思考到咱们ECS的Ascend 310总计2个AI Core,且由零碎主动调度,这里为1还能够接管。但上面的数据可难看了。
如图所示,芯片利用率Chip Utilization。依照规定,80为优,显示为绿色;小于80则为差,显示为红色。依据Pipeline Bound的数值计算得出。而咱们这里间接为0了。再看Cube利用率Cube Ratio约为0.41,Vector利用率Vector Ratio约为0.29,Scalar利用率Scalar Ratio约为0.26,还有优化空间,而MTE1瓶颈、MTE2瓶颈、MTE3瓶颈都还不小。特地是MTE2瓶颈,约为0.39。上面接着看。
来看内存读入量的数据切片策略Tiling Strategy为5.23,状况蹩脚。依据规定,数值达到80为优,显示为绿色;小于80则为差,显示为红色。这是依据Memory Redundant的数值计算得出。同时,能够看到实在内存读入量Real Memory Input(GB)约为1.44GB,实在内存写出量Real Memory Output(GB)约为0.60GB,都在可用范畴内。
接下来进入Computational Graph Optimization界面,如图红框所示两处都能够,二者就是简版和精装版的区别了。在这里,咱们能够看到计算图优化,算子交融举荐性能专家系统剖析倡议,会分行展现可交融的算子。
先来看看须要进行UB交融的算子,点击算子,会主动跳转相应的计算图,既直观又不便啊。同时咱们看到可交融算子的执行工夫Fusion Operator Duration达到了约9585us,靠近10ms了,算是比拟大了。本模型没有AIPP交融举荐和L2Cache交融举荐。
咱们间接看TransData算子交融举荐,如图所示。该算子执行持续时间在2.5ms左右,也不算小了,也是一个值得优化的中央啊。
但遗憾的是本次Roofline页面(基于Roofline模型的算子瓶颈辨认与优化倡议性能输入后果)和Model Graph Optimization页面(基于Timeline的AICPU算子优化性能输入后果)都没什么后果展现,具体别离如下图所示。
这里提个倡议,看了下运行日志(显示了这一句[ERROR] Analyze model(RooflineModel) failed, please check dfx log.),Roofline之所以没有结果显示,可能是Roofline运行失败,不过这个日志有点太简洁了,不太敌对,也没有给出 dfx log的具体门路或地位,哪怕弹出一个链接给用户,让用户去自行查找呢,这都没有,感觉界面不太敌对啊。
专家系统提供对推理模型和算子的性能瓶颈剖析能力并输入专家建议,但理论性能调优还需用户自行批改,不能做到性能调优一键式闭环。而性能调优一键式闭环提供一键式性能问题剖析和优化能力,无效晋升用户性能剖析和优化效率。同时,性能调优一键式闭环以后实现生态知识库ONNX模型的局部推理场景瓶颈辨认和自动化调优能力。
但这须要筹备待优化的ONNX模型文件(.onnx)以及ONNX模型通过ATC转换后的OM模型文件(.om),而咱们这次是.air模型转om模型,尽管能够取得onnx模型,但太麻烦了,咱们这次就不尝试了。
这里再提个倡议,性能调优一键式闭环还须要下载ONNX模型调优知识库,我依照文档(文档链接:https://www.hiascend.com/docu...)中提供Link跳转下载(如下图所示),未能找到文档后续所说的KnowledgeBase Configuration知识库配置文件echosystem.json。不晓得是不是我的问题,倡议工程师看看,验证一下。
MindStudio Profiling工具
Profiling作为业余的昇腾AI工作性能剖析工具,其性能涵盖AI工作运行时要害数据采集和性能指标剖析。纯熟应用Profiling,能够疾速定位性能瓶颈,显著晋升AI工作性能剖析的效率。
上面介绍应用Profiling工具采集性能数据并作简略的性能数据分析。
1. 更换python链接(可选)
这里先给大家排下雷,如果大家遇到如下报错,那么依照上面的操作修复下就行了,报错信息如下图所示:
集体认为,这应该是本地电脑没装置Python或者装置了,然而没有增加到零碎Path,以至无奈调用,这应该Profiling须要在Windows上调用Python做一些操作,但无奈调用Python导致的。那么咱们只有装置Python的时候,抉择增加到Path,或者曾经装置Python的同学,将Python增加到Path,最终使得可能在Windows终端下间接调用Python即可。最终成果示例如下:
此外,因为ECS终端默认启动的Python是/usr/bin/python,而在ECS默认是Python2间接运行程序会报错,而咱们须要用Python3,所以须要从新链接符号,具体流程为:删除python链接文件-->>新建链接文件到python3,上面是操作步骤:
那么有人可能就要问了,为什么是/usr/local/python3.9.5/bin/python3呢?因为咱们在通过MindStudio间接在近程ECS上运行的时候,就是用的这个啊,来张图看看:
这里提个倡议,我之前运行会报错,详情见https://www.hiascend.com/foru...,连着两天重启,试了好几次,就是不行,起初又试了一次,忽然就能够了,感觉很奇怪,莫名其妙地报错,莫名其秒地好了,这给我一种IDE很不稳固的感觉。倡议优化一下,晋升下稳定性。
2. 执行Profiling采集
(1)单击菜单栏“Ascend > System Profiler > New Project”,弹出Profiling配置窗口 。
配置“Project Properties”,配置工程名称“Project Name”和抉择工程门路“Project Location”。单击“Next”进入下一步。
(2)进入“Executable Properties”配置界面。
(3)进入“Profiling Options”配置界面,配置项按默认配置
实现上述配置后单击窗口右下角的“Start”按钮,启动Profiling。工程执行实现后,MindStudio自动弹出Profiling后果视图。
先来看下全量迭代耗时数据,在Timeline视图下查看Step Trace数据迭代耗时状况,辨认耗时较长迭代进行剖析。留神,可抉择导出对应迭代Timeline数据,单击耗时较长迭代按钮
弹出对话框,单击“Yes”导出对应迭代Timeline数据。如图所示,如果最后看不见,倡议将鼠标放到图上,之后滑动放大,就能看见了。
还能够查看迭代内耗时状况:存在较长耗时算子时,能够进一步找算子详细信息辅助定位;存在通信耗时或调度间隙较长时,剖析调用过程中接口耗时。如图所示。
在界面下方还能查看对应的算子统计表:查看迭代内每个AICORE和AICPU算子的耗时及详细信息,进一步定位剖析算子的Metrics指标数据,剖析算子数据搬运、执行流水的占比状况,辨认算子瓶颈点。
此外,这里还能查看组件接口耗时统计表:查看迭代内AscendCL API和Runtime API的接口耗时状况,辅助剖析接口调用对性能的影响。
这个要说一下,限于屏幕大小,上述这次数据的残缺展现,可能须要放大或放大,或者调整某些局部大小,这些操作很卡顿,操作起来没什么反馈,好像这个界面卡死了,可用性差,用户体验不好,倡议优化一下。
咱们能够看到下图中这个Op的Task Wait Time要9.895us,而其余Op根本为0,所以能够思考试试能不能缩小这个Wait Time,从而晋升性能。
这里说一下,上图中这个Op Name很长,我须要将这栏横向拉伸很长能力残缺显示,这有点麻烦,我原本想将鼠标悬停此处,让其主动显示残缺名称,但如同不行,是否思考加一下这个悬停显示全部内容的操作,否则我要先拉伸看,之后再拉回去看其余,比拟麻烦。
还记得之前咱们在专家系统工具那时提到的MTE2瓶颈相比之下有些大(约0.39)嘛?这里从下图看到Mte2工夫较长,约3.7ms,说一下,mte2类型指令应该是DDR->AI Core搬运类指令,这里咱们量化一下看看,如下图所示,AI Core工夫约为6.8ms,但Task Duration约12.5ms,简直翻倍了,阐明咱们Task只有约一半工夫是真正用于AI Core计算,很显著很多工夫被节约了。
阐明这一点还是比拟值得优化的。而各个工具之间也是能够互相辅助,互相验证更好地帮忙咱们定位问题。上面咱们再看看,先确认下Timeline色彩配置调色板,如下图所示。而咱们之前看到的Timeline根本是绿色,未见黄色或红色,预计没什么优化空间了。还是优先做显著地值得优化地点吧,这也算抓大放小吧。
好了,咱们再看点其余的,比方Analysis Summary,这里展现了比拟具体的软硬件信息,比方Host Computer Name、Host Operating System等,还有咱们ECS上用的CPU的详细信息,包含型号、逻辑外围数量等,令我感兴趣的是,还有Ascend 310的信息,包含AI Core数量2, AI CPU数量4,Control CPU数量4,Control CPU Type为ARMv8_Cortex_A55,以及一个TS CPU,很具体了,很好地展现了Ascend 310的外部硬件信息,更有助于咱们理解这款处理器。
同时,再来看看Baseline Comparison吧。
总的来说,MindStudio提供了Host+Device侧丰盛的性能数据采集能力和全景Timeline交互剖析能力,展现了Host+Device侧各项性能指标,帮忙用户疾速发现和定位AI利用、芯片及算子的性能瓶颈,包含资源瓶颈导致的AI算法短板,领导算法性能晋升和系统资源利用率的优化。MindStudio反对Host+Device侧的资源利用可视化统计分析,具体包含Host侧CPU、Memory、Disk、Network利用率和Device侧APP工程的硬件和软件性能数据。
通过Profiling性能剖析工具前后两次对网络应用推理的运行工夫进行剖析,并比照两次执行工夫能够得出结论,能够帮忙咱们去验证替换函数或算子后,是否又性能晋升,是否晋升了推理效率。此外,还能够帮忙咱们筛选应该优先选择的网络模型,或者测试自定义算子是否达到最优性能,是否还存在优化空间等等,还是挺有用的。
MindStudio精度比对工具
1. 定义
为了帮忙开发人员疾速解决算子精度问题,须要提供自有实现的算子运算后果与业界规范算子运算后果之间进行精度差别比照的工具。
2. 性能
提供Tensor比对能力,蕴含余弦类似度、欧氏绝对间隔、绝对误差(最大绝对误差、均匀绝对误差、均方根误差)、相对误差(最大相对误差、均匀相对误差、累积相对误差)、KL散度、标准差算法比对维度。
总结
- MindStudio的装置过于繁琐
暂不谈Linux下的装置和配置,以本次的Windows下MindSutido搭配近程ECS应用来说,Windows下除了要装置MindStudio安装包,还要装置Python依赖,装置MinGW依赖,以及装置CMake等,太麻烦了。是否做成一键装置,毕竟这是个IDE,感觉应用其余IDE都是一键装置,就算有其余依赖,个别也是在IDE外部依据须要,自行抉择装置即可,这个MindStudio可麻烦了,装置的依赖还很扩散。
- 还是性能问题,性能优化不好
Windows下MindStudio的CPU、内存等资源占用很大,远大于其余类型IDE(比方PyCharm、IntelliJ IEDA等),而且还卡顿,这还是近程连贯ECS应用,可就是这样,感觉本地电脑也快腾飞了,远不如PyCharm、IntelliJ IEDA等应用起来顺畅,感觉是软件优化不行,如果是全副在物理机上运行,可能资源开销就更大了,这也太减少负载了,如果是这样,IDE的可视化操作意义就不大了,很多操作不如在终端执行,将更多资源留给更有用的中央。