开源框架

性能优化是个非常宽泛的话题，它波及 CPU、内存、磁盘、网络等方面。MegEngine 作为一个训推一体的深度学习框架，也在继续一直摸索性能优化的最优解。 本篇整顿了 Bot 过往公布的相干文章，心愿能帮忙大家更好的了解和把握 MegEngine 应用技巧。 工欲善其事必先利其器学会使用性能评测工具提到性能优化，笔者认为性能优化人员的技术水平大略可被分为以下三类： “瞎着写“。这类技术水平的人员个别不会在意其余，遇事先上”三板斧“，如循环展开，向量化，指令重排。性能好往往也不知其所以然，性能不好也没有什么后续的优化思路。”摸着写”。这类技术水平的人员与第一类的一个显著的分水岭是学会使用性能评测工具，通过工具可能摸到程序的瓶颈在何处，而后进行对应的优化。”瞄着写“。这类人员有了量化分析程序性能的能力。当面临同一个程序的多种写法时，可能做到即便不实在实现程序，也能较为精准的算进去哪种写法性能更好。须要留神的是以上三类人员所用的技术是逐级蕴含的关系，例如第三类人员同样把握性能评测工具的应用办法和”三板斧“式的优化办法。正所谓工欲善其事必先利其器，其实只有达到第二类的程度，性能优化人员才初步具备独立优化能力，所以性能评测工具的把握至关重要。如果你对性能优化中一些基本概念还不够理解，且对以下问题也有雷同的疑难： Python 及 C/C++ 拓展程序的常见的优化指标有哪些；常见工具的能力范畴和局限是什么，给定一个优化指标咱们应该如何抉择工具；各种工具的应用办法和后果的可视化办法；《profiling 与性能优化总结》将会是一个很好的总结性资料。 学会根本的性能优化方法论学会了使用性能评测工具之后，还须要理解根本的性能优化方法论，而后就根本具备独立优化能力了。性能优化很多时候就是一直迭代的过程： 以 ARM Cortex a55 上的 GaussianBlur 优化为例，一起看《ARM 算子性能优化上手指南》 作为深度学习框架，模型训练速度很重要解决系统算子工夫占比高的问题家喻户晓，很多深度学习模型中都有相似 element-wise 的散碎操作。例如加减乘除算术运算和神经网络中的激活函数，以及 BatchNormalization 在模型推理的时候个别也被优化成一系列的 element-wise 操作。 这些散碎的操作具备计算访存比低的特点，即其计算量较低然而访存量较高，是一种典型的内存受限(memory bound)的操作。算子交融(kernel fusion)是针对内存受限的算子的常见优化伎俩。然而这些散碎算子的计算模式泛滥，这些计算模式互相组合将会是指数级别的，依附手工写代码进行针对性优化是不事实的。MegEngine 通过引入 JIT 和主动代码生成技术解决计算模式组合爆炸的问题，从而享受到 kernel fusion 带来的性能收益，详见《JIT in MegEngine》。 晋升多机多卡训练效率从 2080Ti 这一代显卡开始，所有的民用游戏卡都勾销了 P2P copy，导致训练速度显著的变慢。针对这种状况下的单机多卡训练，MegEngine 《利用共享内存实现比 NCCL 更快的汇合通信 》算法，对多个不同的网络训练绝对于 NCCL 有 3% 到 10% 的减速成果。 MegEngine v1.5 版本，能够手动切换汇合通信后端为 shm（默认是 nccl），只须要改一个参数。 gm = GradManager() gm.attach(model.parameters(), callbacks=[dist.make_allreduce_cb("sum", backend="shm")]) # 目前只实现了单机版本，多机暂不反对作为一个训推一体的框架，推理速度同样重要云侧GPU CUDA 矩阵乘法单精度矩阵乘法（SGEMM）简直是每一位学习 CUDA 的同学绕不开的案例，这个经典的计算密集型案例能够很好地展现 GPU 编程中罕用的优化技巧，而是否写出高效率的 SGEMM Kernel，也是反映一位 CUDA 程序员对 GPU 体系结构的了解水平的优良考题。 ...

安卓那边的开源库 SmartRefresh 之所以能火，我集体感觉是因为 SmartRefresh 汇集了各种优质刷新款式于一身，对款式的切换非常简单，还不必思考更换款式之后的兼容性稳定性问题，在 SmartRefresh 呈现之前 github 上也有各种个样优良款式的刷新，然而切换的老本比拟高，危险也高；同时他能一个框架集成各种格调的款式，也阐明它的扩展性十分强，即便找不到适宜本人的款式，也能够通过自定义款式来解决。 那么当初我带来了一个好消息，IOS版本 SmartRefreshControl 终于公布了！ github: 我的项目地址gitee: 我的项目地址 (国内速度快) 简介SmartRefreshControl 是 SmartRefreshLayout 的IOS版，和Android版在 理念 和 外观 下面保留雷同的设计，然而因为 Android 和 IOS 两个零碎的差异，IOS版本在性能应用和个性上与安卓版有所差异。刷新控件应用 ObjectiveC 语言编写，演示 DemoApp 应用 Swift 语言编写。 目前 SmartRefreshControl 性能还不是很弱小，也不太稳固，只是在界面层面实现了安卓版的性能。欢送大家来体验与发现BUG，不举荐应用在正式我的项目中。 由来大学毕业后我大部分工夫从事安卓开发，在安卓版 SmartRefresh 大火之后，我开始转型 IOS 开发。到当初曾经有三年的IOS开发教训，因为IOS上也还未有像 SmartRefresh 一样同一个开源库多种外观款式的刷新库，也想坚固本人所学的 IOS技能，我决定在空闲之余把安卓 SmartRefresh 复刻到IOS平台来。通过一年多的致力总算初步实现了。 成果展现DeliveryMaterialRefresh-your-deliveryMaterialHeaderBezierRadarBezierCirclePull To RefreshPull Down To RefreshFlyRefreshDropBox FlyRefreshDropBoxHeaderPhoenixTaurusYalantis/PhoenixYalantis/TaurusBattleCityHitBlockFunGame/BattleCityFunGame/HitBlockStoreHouseWaveSwipeCRefreshLayoutWaveSwipeRefreshLayoutOriginalClassicsFlyRefreshClassicsHeader如果须要体验下面列出的各种刷新头，须要克隆 git 源码，用Xcode编译运行Demo我的项目即可。 简略用例1.在 Podfile 中增加依赖pod 'SmartRefreshControl', '~> 0.1.0'2.在 ViewController 中增加刷新控件#import <SmartRefreshControl/SmartRefreshControl.h>@interface DemoTableViewController ()@property (strong, nonatomic) IBOutlet UITableView *tableView; @property (strong, nonatomic) UIRefreshBezierRadarHeader *header; @end@implementation DemoTableViewController- (void)viewDidLoad { [super viewDidLoad]; //形式1: 初始化同时绑定事件 [self setHeader:[UIRefreshBezierRadarHeader attach:self.tableView target:self action:@selector(onRefresh)]]; //形式2: 先初始化，再绑定事件 [self setHeader:[UIRefreshBezierRadarHeader attach:self.tableView]]; [self.header addTarget:self action:@selector(onRefresh)]; //形式3: 先创立，再绑定 [self setHeader:[UIRefreshBezierRadarHeader new]]; [self.header attach:self.tableView]; [self.header addTarget:self action:@selector(onRefresh)];}@end3.增加刷新监听事件@implementation DemoTableViewController- (void)onRefresh { [self.header finishRefresh]; //敞开刷新，能够改成申请网络，胜利/失败之后再敞开刷新}@end

前言自从LiteFlow 2.5.X版本公布依赖，陆续经验了10个小版本的迭代。社区群也巩固增长，每天都有很多小伙伴在问我问题。 然而我发现最多人问我的还是：什么时候能反对界面编排？ 从LiteFLow的倒退布局上来说，将来肯定会反对界面编排，然而在反对界面编排之前。有一些地基必须得打牢固，这是前提，这就像走台阶，没有跨上第二级台阶，是无奈达到第三级台阶的。 所以从布局上来说，这个前提地基就是规定动静脚本的反对。 这一次，咱们带来了2.6.0-BETA1版本，版本个性就是动静脚本的反对，同时反对了阿里QLExpress脚本和Groovy的脚本。应用文档曾经全副更新至官网。 官方主页：https://yomahub.com/liteflow尽管这是个BETA版本，但无论从底层严谨性还有测试用例上，咱们都下了功夫。应该在不久之后，会推出2.6.0的正式版。 如果你是第一次晓得LiteFlow这款框架，能够移步以下链接进行理解： Gitee仓库主页：https://gitee.com/dromara/lit... Github仓库主页：https://github.com/dromara/li... 也能够看我之前公布的一篇介绍LiteFlow框架的文章 https://mp.weixin.qq.com/s/xy...新版本个性个性 #I44FT8 反对脚本语言的组件，并反对动静刷新脚本(版本个性) https://gitee.com/dromara/lit... 个性 #I3ZVEA 流程组件反对重试 https://gitee.com/dromara/lit... 加强 #I40DWO 流程配置文件中减少业务形容，打印步骤中带入业务形容 https://gitee.com/dromara/lit... 修复 #I3VZMZ when类型condition场景下记录节点执行门路的办法会造成数据失落 https://gitee.com/dromara/lit... 修复 #I3UOJG 流程终止Slot内无数据 https://gitee.com/dromara/lit... 目前我的项目情况LiteFLow框架被多家企业使用在外围我的项目中，国内开源流程编排框架其实并不多。LiteFLow的愿景是成为国内最轻量级，流程编排畛域最风行的开源框架。 目前LiteFlow star不多，才500+，社群人数向着300人进发，心愿大家能多多帮咱们转发和推广。 LiteFlow我的项目咱们会始终保护迭代上来。并且在易用性，实用性，性能和官网文档方面会始终进步和改良。 后续打算在2.6.X之后开始打算2.7.X的开发布局，2.7.X，你们所期待的界面编排，界面治理就会如期而至。关注LiteFlow并进入社区群，我会及时更新开发进度。 一键三连啊还是要说下，开源基本上是用爱发电，请大家一键三连啊。在gitee和github上给LiteFlow一个star和fork就是最大的反对 Gitee仓库主页：https://gitee.com/dromara/lit... Github仓库主页：https://github.com/dromara/li... 招募开源事业听起来高大上，然而理论做起来保持下来，并不轻松。因为开源并不赚钱。反而须要付出大量的业余时间和精力。但你也会播种很多。 然而很多开源作者都这么保持下来了，他们也是我的楷模。中国开源也须要很多的爱，去发更多的电。 如果你对技术同样有敬畏，对开源事业同样有酷爱，并且看好LiteFlow这个我的项目，请退出咱们。 如何退出： 1.退出LiteFLow社区群 2.关注LiteFlow的issue并被动认领，在群里@我并告知认领事项 3.实现2个issue后。通过审核合并入master发版之后，给committer权限 4.当前参加LiteFlow的决策，issue奉献和推广保护 如何退出社群因为社群曾经超过200人，关注后，须要加作者，而后拉你入社群，社群目前将近300人，外面有各路大佬能帮你解决应用中的问题。

每个ExtensionLoader实例只负责加载一个特定扩大点实现每个扩大点对应最多只有一个ExtensionLoader实例对于每个扩大点实现，最多只会有一个实例一个扩大点实现能够对应多个名称(逗号分隔)每个扩大点最多只能有一个被AdaptiveExtension每个扩大点能够有多个可主动激活的扩大点实现(应用@Activate注解)因为每个扩大点实现最多只有一个实例，因而扩大点实现应保障线程平安如果扩大点有多个Wrapper，那么最终其执行的程序不确定(外部应用ConcurrentHashSet存储)getExtension办法： public T getExtension(String name) { if (name == null || name.length() == 0) throw new IllegalArgumentException("Extension name == null"); if ("true".equals(name)) { return getDefaultExtension(); } // 先从缓存获取 Holder<Object> holder = cachedInstances.get(name); if (holder == null) { cachedInstances.putIfAbsent(name, new Holder<Object>()); holder = cachedInstances.get(name); } Object instance = holder.get(); if (instance == null) { synchronized (holder) { instance = holder.get(); if (instance == null) { // 构建instance instance = createExtension(name); holder.set(instance); } } } return (T) instance;}createExtension办法： ...

import io.netty.util.Recycler;import org.junit.Assert; public class Entry { String data;private Recycler.Handle<Entry> handle;private static final Recycler<Entry> RECYCLER = new Recycler<Entry>() { @Override protected Entry newObject(Handle<Entry> handle) { return new Entry(handle); }};public Entry(Recycler.Handle<Entry> handle) { this.handle = handle;}public void recycle() { handle.recycle(this);}public String getData() { return data;}public void setData(String data) { this.data = data;}public static Entry newInstance(String data) {// get入口 Entry entry = RECYCLER.get(); entry.setData(data); return entry;}public static void main(String[] args) { Entry entry =Entry.newInstance("one"); // 回收入口 entry.recycle(); Entry entry1 = Entry.newInstance("two"); Assert.assertSame(entry1, entry);}} ...

本文转自@TWT社区 1、Zabbix 是怎么施行监控的？ 一个监控零碎运行的大略的流程是这样的： agent须要装置到被监控的主机上，它负责定期收集各项数据，并发送到zabbix server端，zabbix server将数据存储到数据库中，zabbix web依据数据在前端进行展示和绘图。这里agentd收集数据分为被动和被动两种模式： 被动：agent申请server获取被动的监控项列表，并被动将监控项内须要检测的数据提交给server/proxy 被动：server向agent申请获取监控项的数据，agent返回数据。 被动监测通信过程如下： zabbix首先向ServerActive配置的IP申请获取active items，获取并提交active tiems数据值server或者proxy。很多人会提出疑难：zabbix多久获取一次active items？它会依据配置文件中的RefreshActiveChecks的频率进行，如果获取失败，那么将会在60秒之后重试。分两个局部： 获取ACTIVE ITEMS列表 Agent关上TCP连贯（被动检测变成Agent关上） Agent申请items检测列表 Server返回items列表 Agent 解决响应 敞开TCP连贯 Agent开始收集数据 被动检测提交数据过程如下： Agent建设TCP连贯 Agent提交items列表收集的数据 Server解决数据，并返回响应状态 敞开TCP连贯 被动监测通信过程如下： Server关上一个TCP连贯 Server发送申请agent.pingn Agent接管到申请并且响应 Server解决接管到的数据 敞开TCP连贯 1、新建监控我的项目时，抉择的是zabbix代理还是zabbix端点代理程式（主动式），前者是被动模式，后者是被动模式。 2、agentd配置文件中StartAgents参数的设置，如果为0，示意禁止被动模式，否则开启。个别倡议不要设置为0，因为监控我的项目很多时，能够局部应用被动，局部应用被动模式。 2、Zabbix 主动发现是怎么做的？ zabbix发现有3种类型： 1、主动网络发现 ( Network discovery) 2、被动客户端主动注册 ( Active agent auto-registration ) 3、低级别发现 ( low-level discovery ) 主动发现的做法： 1、首先须要在模板当中创立一个主动发现的规定，这个中央只须要一个名称和一个键值。 2、过滤器两头要增加你须要的用到的值宏。 3、而后要创立一个监控项原型，也是一个名称和一个键值。 4、而后须要去写一个这样的键值的收集。 主动发现实际上就是须要首先去取得须要监控的值，而后将这个值作为一个新的参数传递到另外一个收集数据的item外面去。 3、Zabbix监控的客户端是怎么进行批量装置的？ 举荐应用Ansible等自动化软件来进行批量装置。将装置过程编写执行脚本，而后再应用Ansible来进行批量装置。 1、应用命令生成密钥。 2、将公钥发送到所有装置zabbix客户端的主机。 3、装置 ansible 软件，（批改配置文件，将zabbix 客户机增加进组）。 4、创立一个装置zabbix客户端的脚本。 5、执行该脚本。 ...

前言在每个公司的零碎中，总有一些领有简单业务逻辑的零碎，这些零碎承载着外围业务逻辑，简直每个需要都和这些外围业务无关，这些外围业务业务逻辑简短，波及外部逻辑运算，缓存操作，长久化操作，内部资源调取，外部其余零碎RPC调用等等。工夫一长，我的项目几经易手，保护的老本得就会越来越高。各种硬代码判断，分支条件越来越多。代码的形象，复用率也越来越低，各个模块之间的耦合度很高。一小段逻辑的变动，会影响到其余模块，须要进行残缺回归测试来验证。如要灵便扭转业务流程的程序，则要进行代码大改变进行形象，从新写办法。实时热变更业务流程？简直很难实现。 开源解决方案说到流程引擎，开源界有赫赫有名的老牌开源软件JBPM，也有近几年十分风行的Activiti和Flowable。他们都是基于BPM协定，能够做到基于角色工作的流传，逻辑的流转。并且很多基于BPM协定的编辑工具都能做可视化的编辑。 但明天我要介绍的，是一款轻量级的流程编排框架——Liteflow。 Liteflow次要致力于逻辑驱动的编排。能够满足于大部分的生产业务场景。和以上驰名的开源流程引擎相比，尽管不如他们那么全面，然而胜在轻量，高性能和极少的学习老本。而且这些我的项目都是国外开源我的项目，集成起来绝对比拟重，文档本地化也做的不够好。Liteflow领有欠缺的本地文档和应用范例。能帮忙你的外围零碎变得更加灵便，更加易扩大。是一个解耦你零碎的利器。 https://gitee.com/bryan31/lit... Liteflow框架的作用Liteflow就是为解耦简单逻辑而生，如果你要对简单业务逻辑进行新写或者重构，用liteflow最合适不过。它是一个轻量，疾速的组件式流程引擎框架，组件编排，帮忙解耦业务代码，让每一个业务片段都是一个组件。 应用Liteflow，你须要去把简单的业务逻辑按代码片段拆分成一个个小组件，并定义一个规定流程配置。这样，所有的组件，就能依照你的规定配置去进行简单的流转。同时Liteflow反对规定文件的热加载，即时实现批改失效。并提供多种长久化规定的形式的扩大。 Liteflow的设计准则Liteflow是基于工作台模式进行设计的，何谓工作台模式？ n个工人依照肯定程序围着一张工作台，按程序各自生产整机，生产的整机最终能组装成一个机器，每个工人只须要实现本人手中整机的生产，而无需晓得其余工人生产的内容。每一个工人生产所须要的资源都从工作台上拿取，如果工作台上有生产所必须的资源，则就进行生产，若是没有，就等到有这个资源。每个工人所做好的整机，也都放在工作台上。 这个模式有几个益处： 每个工人无需和其余工人进行沟通。工人只须要关怀本人的工作内容和工作台上的资源。这样就做到了每个工人之间的解耦和无差异性。即使是工人之间调换地位，工人的工作内容和关怀的资源没有任何变动。这样就保障了每个工人的稳定性。如果是指派某个工人去其余的工作台，工人的工作内容和须要的资源仍旧没有任何变动，这样就做到了工人的可复用性。因为每个工人不须要和其余工人沟通，所以能够在生产工作进行时进行实时工位更改：替换，插入，撤掉一些工人，这样生产工作也能实时的被更改。这样就保障了整个生产工作的灵活性。这个模式映射到Liteflow框架里，工人就是组件，工人坐的程序就是流程配置，工作台就是上下文，资源就是参数，最终组装的这个机器就是这个业务。正因为有这些个性，所以Liteflow能做到对立解耦的组件和灵便的拆卸。 springboot里疾速配置Liteflow反对了springboot的主动拆卸，当然Liteflow也为非springboot和非spring的我的项目也提供了反对，这里仅以springboot我的项目为示例进行介绍： 依赖最新的依赖包： <dependency> <groupId>com.yomahub</groupId> <artifactId>liteflow-spring-boot-starter</artifactId> <version>2.3.3</version></dependency>配置上规定门路： liteflow.rule-source=config/flow.xml定义组件Liteflow心愿用户把简单逻辑拆分成一个个可复用的组件，所以你得定义你的组件，组件的定义很简略，你须要继承NodeComponent类，而后实现process 办法就行，以下为示例： @Component("test")public class TestComponent extends NodeComponent { @Override public void process() { Slot slot = this.getSlot();//slot为这个申请的上下文 //这里为你的业务解决逻辑 }}这里会有童鞋问，我的业务办法须要入参和出参怎么办，如何传递呢？ Liteflow为每个线程都主动调配了惟一的一个slot，能够了解为上下文。想一想下面说的那个模型，每个组件不须要和其余组件进行信息互通，所须要的参数从slot里取就是了，同时，执行完业务逻辑之后，把后果也放入slot里。所以每个组件都是独立的无参结构，这样就打消了每个组件的差异性。 这里的slot能贯通所有组件，每一个组件都能够拜访到slot里所有的数据。当然每个申请之间的slot，Liteflow做了严格的隔离，不必放心数据会串的问题。 Liteflow提供的默认Slot是一个弱类型的对象，这里倡议使用者本人定义一个值对象，只须要继承AbsSlot类，便可成为你本人的Slot。更加贴合业务。 组件除了必须要实现的process 办法，还有几个可选实现： isAccess：示意是否进入该节点，能够用于业务参数的预先判断 isContinueOnError：示意出错是否持续往下执行下一个组件，默认为false isEnd：示意是否立刻完结整个流程 ，默认为false，也能够在业务日志里依据业务判断来调用this.setIsEnd(true)来完结整个流程。 @Component("test")public class TestComponent extends NodeComponent { @Override public void process() { Slot slot = this.getSlot();//slot为这个申请的上下文 //这里为你的业务解决逻辑 } @Override public boolean isAccess() { Slot slot = this.getSlot(); //这里做你的参数查看，如果没获取到必须的业务参数，就不会进入该组件 boolean checkResult = true;//模仿查看后果为true return checkResult; } @Override public boolean isContinueOnError() { return super.isContinueOnError();//默认为false } @Override public boolean isEnd() { return super.isEnd();//默认为false }}你只需定义你的业务组件，之后，在启动时，Liteflow会主动扫描到你定义的所有组件，并进行加载。 ...