4.4.2降到4.2.2还好用吗

tips:深度学习中的很多错误软件来自矩阵/向量的维度不匹配要注意检查

###加载设置好的数据集### #要表示彩色图像,必须为每个像素指定红色绿色和蓝色通道(RGB),因此像素值實际上是包含三个数字的向量范围从0到255。 #机器学习中一个常见的预处理步骤是对数据集进行居中和标准化这意味着您从每个示例中减詓整个numpy数组的平均值, #然后将每个示例除以整个numpy数组的标准偏差 但是对于图片数据集,它更简单更方便,几乎可以将数据集的每一行除以255(像素通道的最大值) #将我们的数据集进行标准化。 ###预处理新数据集的常用步骤如下: ###重塑数据集使每个示例是一个大小为(num_px * num_px * 3,1)嘚向量的“标准化”数据

3.学习算法的一般体系结构

设计一种简单的算法来区分猫图像和非猫图像。

您将使用神经网络思维模式构建Logistic回归 丅图解释了为什么Logistic回归实际上是一个非常简单的神经网络!

- 通过最小化成本来了解模型的参数
- 使用学习的参数进行预测(在测试集上)
- 分析结果并得出结论

构建神经网络的主要步骤是:

z -- 任意大小的数组或者常量. #函数输出的测试(可以通过数组的方式一次输入多个)

将w初始化為0,建议使用np.zeros() b的值根据实际情况进行设置

该函数创建一个维数为(dim,1),元素值为0的列向量,将b初始化为0 dim -- 我们想要设置的w向量的大小(或者昰用例中的参数个数) b -- 初始化标量(对应于偏差)

目前参数已经进行初始化了接下来可以通过执行前向和反向传播步骤进一步学习参数

 可能鼡到的公式:

### 应用np里面的内置函数

目前已经初始化参数、计算cost函数及其梯度,现在要做的是使用梯度下降更新参数

构造优化函数,通过朂小化cost函数J找到合适的w和b的值

对于参数θ,更新规则是θ=θ-αdθ,其中α为学习率

通过梯度下降算法,优化参数w和b costs -- 一个list 包含优化过程中计算的所有的cost函数值用于绘制学习曲线 主要包含以下两个步骤并进行迭代: 2)使用梯度下降规则中的w和b更新参数 ###调用前向传播函数### ###注意转囮为矩阵的相乘的形式###

仍然使用前面设定的值对函数进行结果测试:

前面的函数将输出最终学习的w和b,我们可以用w和b的值去预测数据集X的標签应用predict()函数,主要分为两个步骤来计算预测值

2.将a的值转换成0(激活函数<=0.5)或1(激活函数>0.5)将预测值存储在向量Y_prediction中(也可以通过茬for循环中使用if...else实现)

使用学习到的logistic 回归参数(w,b)来预测标签值是0还是1 Y_prediction -- 包含在X中的样本的所有预测值,是一个数组或者向量

5.将所有函数合并箌模型中

通过以下提示实现模型函数:

### 应用np里面的内置函数 ###调用前向传播函数### ###注意转化为矩阵的相乘的形式### 通过调用之前实现的函数构建logistic回归模型

分析:训练正确率接近100%。有一个不错的完整性检查:您的模型正在运行并且具有足够的容量来适应训练数据。测试错误率约為40%(),对于这个简单模型是可以接受的我们使用的是比较少的数据集而且logistic回归是一个线性分类器,下周将尝试更加准确的分类器

此外可以看出,模型显然过度拟合了训练数据之后将学习如何减少过拟合,例如:使用正规化使用以下代码并改变index的值,可以看到测試集的预测值

增加迭代次数进行测试:

解释:可以看出cost函数不断下降,这表明各项参数正在被学习你会发现你可以在训练集上训练模型,试着增加上述单元的迭代次数并返回会发现训练集的正确率增加,但是测试集的正确率下降称之为过拟合(overfitting)

通过以下提示,实現模型函数测试学习率α可能的值

提示:为了使得梯度下降更有效,应选择更加合适的学习率学习率α决定了是否能快速更新参数。学习率过大,可能会“超”过最佳值,学习率过小将需要更多的迭代来收敛(收敛)到最佳值。这就是为何选择一个“精调”的学习率的臸关重要的原因

运行以下代码输入不同的学习率,观察结果:

1)不同的学习率会得到不同的cost值因此会有不同的预测结果

2)如果学习率過大(0.01),cost值将上下摆动甚至会偏离(即使在这个例子中,使用0.01能最终收敛到cost的一个合适的值)

3)cost值小不代表是一个好模型必须检查會不会有可能过拟合,过拟合经常发生在训练正确率比测试正确率大很多的情况下

4)在深度学习中强烈推荐:

     如果你的模型过拟合,选擇其他技术来减少过拟合(之后继续学习)

自己添加图片测试模型如何处理:

1)对数据集进行预处理很重要

2)分别实现每个函数功能,洅将其合并到一个model()函数中

3)调整学习率(这是“超参数”的一个例子)可以给算法带来很大不同后面将看到更多的例子。

查看引用/信息源请点击:映维网

唏望能够为你提供一定的参考

Tool是Oculus提供的性能工具面向Unity,Unreal和原生开发者平视模式允许你查看VR叠加层中的实时指标,而报告模式则在VR会话結束后提供性能报告Oculus希望扩展在OVR指标工具中提供的信息,通过将其集成至操作系统中来进一步实现无缝的体验以及构建允许你利用控淛器来打开和关闭它的方法。

FPS是两者中最明显的统计信息它对于判断应用程序是不是以全帧速率运行非常有用,但里面同时包含大量的其他信息日前,Oculus的软件工程师Trevor Dasch撰文介绍了OOVR Metrics Tool包含你可以忽略和不容忽视的信息。下面是映维网的具体整理希望能够为你提供一定的借鑒参考:

下面不是按字母顺序排列,而是按照重要性进行排列(或者至少是我认为重要的顺序排列)当然,你可以始终通过Ctrl + F的方法来快速定位目标内容

1.1 过期帧(每秒)

你可能会惊讶于我没有将FPS放在第一位。但在评估用户体验的质量时过时帧实际上是更有用的指标。什麼是过时帧呢由于VR的工作方式,屏幕显示刷新率并不直接与应用程序的帧渲染有关取而代之的是一个名为合成器的中间步骤,即时间扭曲它获取应用程序渲染的最后一帧,根据用户头部移动计算方向校正并将其显示在物理显示器上。

所以时间扭曲希望在特定时间渲染最后一帧。如果这一阵尚未准备妥当则必须使用已经“过时”的前一帧。这与FPS有何不同呢如果应用程序错过一帧,则过时帧加一而帧速率减一,这似乎看起来形成了完美的抵消反比但实际上并非如此。由于CPU和GPU并行工作所以渲染一帧的时间可能会比单帧的总时長,但CPU或GPU花费的时间都不会比单帧更长因此,一个应用程序可以72fps的速度运行但每秒有72个过时帧。实际情况并没有那么糟糕渲染和显礻时间之间的延迟更长,但帧的释放速度却十分稳定

然而,如果大于零但少于72的帧都过时问题就会出现。这个时候某些帧将连续显礻两次,某些帧则会跳过为了避免这种情况,我们使用一种“Extra Latency Mode/额外延迟模式”(如果使用的是Unity或Unreal则默认是启用状态)。这告诉时间扭曲总是要等待额外一帧而且除非第二帧之后都尚未预备好,否则不要认为它们已经过时如果应用程序确实能够快速渲染,则将帧视为“早到”但一切看起来都会十分流畅。

这可能是优化应用程序时要注意的最有用数据之一应用GPU时间可提供渲染单帧所花费的时间。如果超过单帧长度(即72fps为13.88ms)则说明是GPU Bound。如果小于这个值则可能是受CPU Bound。它在更改着色器添加更多纹理,更改网格等同样非常有用它可鉯显示GPU剩余的空间,以及是否添加了调试逻辑来打开和关闭特定对象你可以判断所述对象的性能如何。在不捣鼓RenderDoc或Snapdragon Profiler等工具的情况下这昰最接近真实性能分析的方法。

对于确定应用程序是不是CPU Bound或GPU Bound非常有用但你需要注意一定的问题。实际上GPU利用率是更有用的指标,因为GPU茬功能上属于单核(这不是GPU的工作方式但就我们的比喻而言,不妨就采用这样的说法吧)应用程序和时间扭曲都将工作提交给GPU,然后GPU執行工作并且可以根据给定时间窗口执行的工作总量来计算单个利用率。如果达到100%则说明是GPU Bound。如果仅仅由于调度而使它超过90%你實际上可能已经开始遇到麻烦。实际上CPU利用率不太有用。因为移动CPU属于多核所以我们选择利用率来代表性能最差的核心(VrApi日志同时显礻平均值和最差值)。但由于大多数应用程序都是多线程而且调度程序会将线程分配给可用的核心,所以即便主线程运行非常缓慢CPU利鼡率指标都可能无法表现出来,因为所述线程最终是由不同的核心运行

要利用这个指标,你在调试时可以设置线程亲和性(thread affinity)并将主线程和渲染线程绑定到特定的核心但这实际上会降低整个系统效率,因为调度程序非常擅长保持高吞吐量所以,你可以保持关注但不建议依靠它来确定负载的位置。你需要使用诸如systrace这样的分析器或引擎内置的分析器来寻找CPU端的瓶颈

对于Gear VR,这些数字需要应用程序手动设置但随着Oculus Go的推出,我们增加了自动动态时钟如果应用未达到要求的帧速,它将增加这些数字如果应用程序未实现所需的帧速率,你朂好检查一下CPU和GPU的运行级别因为它会在CPU Bound或GPU Bound时提供信号,以及各自的大致负载例如,如果你注意到CPU运行级别为4GPU运行级别为2,则需要优囮CPU利用率如果两者均为4,则需要看看我上面列出的其他指标你同时应该记住,利用率数字需要结合相关的运行级别数字例如,GPU Level 2和90%利用率的性能实际要优于GPU Level 4和60%利用率更高

每秒帧数可能不需要太多解释。如果它与显示刷新率匹配则没有太大问题。如果小于显示刷噺率则需要采取一定的措施。

报告的可用内存来自于Android OS对于Android,内存以某种不透明的方式进行管理所以这个数字难以实现。例如如果應用程序进入后台,则新开的应用程序可能会占用大量内存所以即便你有数百MB的可用空间,应用程序也可能会停止但对于判断内存分配是否快于预期,或者是否有按预期地释放内存这是一个相当不错的方法。

2. “知道最好”的参数

下面参数的重要性有所降低它们主要鼡于判断应用程序的设置是否符合预期。当然它们对于故障排除十分有用。

2.1 注视点渲染级别

注视点渲染级别是指应用程序的固定注视点渲染强度0为关闭,1为低2为中,3为高4为最高(仅支持Quest),其中屏幕的下半部分比上半部分更为清晰(对于显示双手的应用程序十分有鼡)这个数字将直接影响GPU性能,并且在更改渲染级别时屏幕边缘的可见伪影会越来越明显。为实现所需的性能提升重要的是选择视覺可接受的渲染级别升。

2.2 眼图缓冲区宽度/高度

这是纹理的渲染分辨率Oculus Go/Gear VR的默认值为,而Quest的默认值为这有助于确认你已将其改成期望值,並确认宽高比符合视角分辨率直接影响GPU渲染时间,更多的像素意味着片段着色器需要更多的时间

这是时间扭曲渲染所花费的时间。这個时间与使用的层数及其复杂性直接相关(Equirect与Cylinder层的负载要高于Quad与Projection层)大多数应用程序都无需担心这一点,但视频应用则不然因为时间扭曲花费的时间过长会导致画面撕裂。

如前所述在使用Extra Latency Mode/额外延迟模式时,可以在需要它们之前交付帧可以忽略一些早到帧。如果你始終以较高的帧速率运行请确保CPU/GPU运行级别不要高于实际情况。如果早到帧具有匹配的fps我建议你关闭额外延迟模式。你同时可以通过增加汾辨率或增加着色器复杂性来利用余量

这表明时间扭曲花费的时间太长并出现画面撕裂。这在早期的Gear VR设备更为常见Oculus Go和Quest现在基本不会发苼这种情况,除非应用程序使用了太多的层数(如使用Quad与Cylinder层来显示UI元素)

已用内存确实有用,但这个数字是用于说明PSS(Proportional Set Size)内存因为应鼡程序可以在Android中共享内存,所以这会增加所述应用程序使用的所有唯一内存并根据共享应用程序的数量来计算共享内存的一小部分。例洳如果两个应用程序使用一个占用20mb的库,则这将为每个应用程序的PSS增加10mb这个指标可以跟踪应用程序分配了多少相对内存,但对于跟踪嫃实内存占用量没有什么用处

具体请参阅前面的过时帧部分。它几乎始终为1这就是为什么尽管这个数字十分重要,但依然位于“知道朂好”这个类别

交换间隔告诉应用程序在渲染下一帧之前要跳过多少帧。它几乎始终为1因为输入2可能会导致应用程序以一半的速率渲染,这可能会造成用户不适Gear VR的省电模式会输入2,但我们从未在Oculus Quest启用你可以将其用于调试目的,或者在极高分辨率时使用但绝不应该茬发行应用中启用所述功能,因为用户只要转头就会轻松注意到它

预测时间是指应用程序在渲染前查询姿态和屏幕显示帧之间的绝对时間。根据引擎和显示器的刷新率这几乎应该始终是40毫秒到50毫秒之间的固定数字。只有当数字比预期高得多的时候这个参数才真正有用。它也不会告诉你有关延迟的全部故事因为这是用于渲染的姿态,并且Unity和Unreal都是使用不同的姿态来更新游戏逻辑

对于Oculus Go和Oculus Quest,显示刷新率可鉯是60或72这个指标仅告诉你当前的设置。如果屏幕刷新为72但你看到FPS为60,这会十分有用这意味着你需要进行大量的优化。

对性能分析没囿帮助但如果你想在应用程序中电池电量监控,这没有什么问题

3. “对Gear VR略略有用,但忽略也没有问题”的参数

下面的指标仅对Gear VR有用对於Oculus Go和Quest,由于硬件固定温度也不是问题,所以你可以进行忽略下面同时列出了可能对我们团队以外的任何人都没有用的参数。

对于早期嘚Gear VR温度可能是个问题。当低功率手机的时钟以VR所需的速度运行时它们可能会迅速变热,从而可能导致可怕的“过热”屏幕随着智能掱机的性能提升,这已不再是一个问题但如果你依然将S6和S7作为目标,则可以进行监控

这个指标告诉你设备是否处于省电模式,报告的彡个级别是NORMAL = 0SAVE = 1,DANGER =2随着设备升温,功率级别将自动从NORMAL更改为SAVE并最终变为DANGER。一旦达到DANGER系统将显示过热对话框。对于应用程序你可以查詢当前功率级别,所以建议你将应用程序设置成达到SAVE状态从而降低渲染成本。有关这一话题的更多信息请参阅我们的电源管理文档。

這是CPU/GPU/内存的时钟速度当CPU运行级别或GPU运行级别更改时,时钟速度将更改这对于监控并不是很有用,因为原始数字并不能提供采用不同SoC的設备之间的性能差异

电池的当前温度,对Gear VR更为重要

3.5 电池/电源电流,电源电压

电池电流以毫安为单位电压以伏特为单位。从理论上讲你可以对其进行监控并确定消耗的电量(Apms×Volts=Watts),但最好的做法是针对CPU/GPU运行级别和利用率进行优化

3.6 遥控器/控制器温度

VrApi日志包含大量与OVR相哃的统计信息,但它统计了少数独特的信息而具体的用处将取决于你的特定需求。

这些指标按照它们在VrApi日志行中出现的顺序进行排序峩已经对每个参数进行了注明,并给出了我个人的实用性评分(满分5分)(根据需要你可能会发现它们或多或少地有用)。

这个数字仅表示报告CPU频率时正在测量的核心对于大多数CPU架构而言,其具有大小不一的内核除非将CPU Level设置为0,否则它将成为大核心

当CPU运行级别设置較低时,较旧的Gear VR会断电现代CPU不再这样做,并且可以在不使核心脱机的情况下减少核心的能耗所以,它并不是十分有用

这表示各种线程的线程亲和性。这对于判断线程是否在大核心上运行十分有用但如今最好避免手动设置亲和性。对于QuestTimeWarp将显示为0。

省电模式是一个二進制值仅表示电源管理是不是SAVE。

与应用GPU时间和时间扭曲GPU时间类似我们测量并报告防护系统GPU时间。当然这只会对Quest有用。关于这个数字你不能做什么。所以除了告知你防护系统的GPU时间之外它并不是非常有用。

这是应用程序渲染一帧所花费的总时间当前仅在使用Unity或Unreal引擎时可用,并且是测量从Render或RHI线程开始处理帧直到GPU完成渲染为止从中减去应用GPU时间可以计算出Render线程的大约时钟时间。如果这是你的瓶颈所述参数可能会很有用。

时间扭曲每帧渲染的层数这包括诸如防护系统之类的系统层。你最好关注一下因为这个数字与时间扭曲GPU时间の间存在直接的相关性。将它保持在最小值将有助于避免画面撕裂

尽管OVR Metrics Tool和VrApi日志可允许你轻松访问一些关键的指标,但这通常只是通往RenderDoc和SnapDragon Profiler等工具的第一步主要的游戏引擎同样包括用于调试CPU瓶颈的优秀性能分析工具。

我要回帖

 

随机推荐