精华内容
下载资源
问答
  • 方舟编译器

    千次阅读 2019-09-10 08:27:23
    华为方舟编译器是华为公司专门为软件厂商研发的统一编程平台,包含编译器、工具链、运行时等关键部件。该编译器支持多种编程语言、多种芯片平台的联合编译与运行,能够有效解决安卓程序“边解释边执行”的低效率问题...

    华为方舟编译器是华为公司专门为软件厂商研发的统一编程平台,包含编译器、工具链、运行时等关键部件。该编译器支持多种编程语言、多种芯片平台的联合编译与运行,能够有效解决安卓程序“边解释边执行”的低效率问题

    2019年8月31日,华为方舟编译器开源官网正式上线。

    中文名

    华为方舟编译器

    外文名

    HuaWei Ark Compiler

    类    型

    静态编译

    运行平台

    HarmonyOS,android

    研发背景

    编译器是连接人类世界与机器世界之间的一座桥梁,任何在手机上的程序都需要经历软件开发的过程,软件开发使用的语言是易于程序员理解的高级语言,程序在手机上运行需要转换成可以高效执行的机器码,这样的转换过程就是由编译器完成的。可以说编译器是用来生成软件的软件,是连接软件与芯片的桥梁,其性能,效率直接影响到最基础的消费者体验。 

    发展历程

    方舟编译器架构示意图

    2019年4月,在华为P30系列国内发布会上,华为首次宣布了华为方舟编译器技术。 

    2019年8月31日,华为方舟编译器开源官网正式上线。 

    技术特点

    安卓系统使用Java作为编程语言,易于开发,但是不会将代码直接编译成机器语言,程序运行时有相当一部分代码还需要通过手机上的虚拟机临时同步编译,影响程序执行的效率。华为方舟编译器采取了静态编译的方式,是首个取代了安卓虚拟机模式的静态编译器。 

    性能效果

    方舟编译器采用全程执行机器码高效运行程序,架构进一步得到优化,可供开发者在开发环境一次性的将高级语言编译为机器码,手机安装应用程序后可全速运行程序,带来效率上的极大提升。根据华为实验室的测试数据,EMUI 9.1在仅仅对系统组件System Server应用了华为方舟编译器后,就带来了系统操作流畅度提升24%,系统响应性能提升44%。

    开源计划

    在方舟编译器面世之时,华为就宣布未来将这一技术开源,希望更多的APP厂商,高校,安卓手机厂商,开源社区的开发者能一同加入进来。 

    华为计划在2020年将方舟编译器完整开源,帮助开发者构建完整的工具链。届时华为还将提供代码调优工具,开发者可以选择根据工具的优化建议来调整自己的代码,和方舟编译器配合获得更优的执行效果。 

    截至2019年,已经有40多个顶级应用通过方舟的编译上架到华为应用商城,未来将有更多的第三方使用方舟编译器。同时,方舟编译器所有代码也将开源给业界。 

    展开全文
  • 我们在2020年9月发布了10.4悉尼发行版和10.4.1,主要关注质量和对10.4中提供的功能的进一步改进,特别是新添加的Delphi LSP支持。10.4.1包括800多项质量改进,其中包括针对Embarcadero的Quality Portal中公开报告的...

    介绍

    Embarcadero RAD Studio产品管理团队会定期更新Delphi,C ++ Builder和RAD Studio的产品开发路线图。您可以在我们的官方路线图博客文章中看到,我们刚刚发布了该路线图的新版本,其中涵盖了我们计划在接下来的12个月中使用的主要功能。除了正式的路线图幻灯片之外,我们还希望通过这篇额外的博客文章提供更多详细信息,信息和见解。您可能会发现打开幻灯片供参考,同时阅读我们在此处提供的扩展信息很有用。

    在我们的路线图中,您可以找到我们为2021日历年计划的主要功能。在了解更新后的路线图的细节之前,我们想回顾一下到目前为止已交付的内容。

    今年年初,我们发布了10.4 Sydney。10.4版本受到了客户的好评,其中包括我们完全重写的Delphi Code Insight引擎的首次交付,该引擎现在基于Language Server协议体系结构,C ++ Win64的新调试器,可以满足长期的客户需求,以及新的Delphi语言功能,例如自定义托管记录。我们还支持HighDPI监视器和每个控件样式,从而大大扩展了VCL样式的用例。

    我们在2020年9月发布了10.4悉尼发行版和10.4.1,主要关注质量和对10.4中提供的功能的进一步改进,特别是新添加的Delphi LSP支持。10.4.1包括800多项质量改进,其中包括针对Embarcadero的Quality Portal中公开报告的问题的500多项质量改进。

    在我们详细介绍10.4.2和10.5版本之前,我们想强调一下10.4 / 10.4.1迄今为止是我们最受欢迎的版本之一,与10.3和10.2相比下载量更多。在COVID-19中,这尤其令人印象深刻。我们将成功归功于发布和我们与技术合作伙伴的更多参与,后者继续与我们的团队合作以升级和开发新功能。我们也要感谢您的客户,我们一直以来向产品团队提供的宝贵反馈,包括您希望看到的新增功能以及您希望我们专注于质量的方面以及您的参与在我们的Beta版计划中(这是订阅的好处之一)。

    目前,我们正在开发10.4.2版本,计划在2021日历年的第一年发布,并在路线图和此评论性博客文章中进行了详细说明。在发布之前,我们希望邀请RAD Studio,Delphi和C ++ Builder客户进行有效的更新订阅,以加入即将发布版本的Beta测试。10.4.2测试版将是NDA测试版,要求参与者在参与测试之前必须签署我们的保密协议。能够加入测试版并参与在开发周期的早期向产品管理提供反馈是最新订阅的好处之一。

    对于10.5,我们计划为Delphi,macOS ARM(基于Apple Silicon CPU)引入一个新的目标平台,围绕IDE HighDPI支持,C ++工具链扩展以及许多其他附加功能和质量增强进行大量工作。请参阅下面的更多细节。  

    RAD Studio路线图时间表

    在详细了解开发团队正在开发的功能或研究未来的功能之前,让我们看一下即将发布的时间表,如路线图的主幻灯片所示: 

    David Millington对10.4.2计划的评论

    Delphi代码见解

    正如Marco在上面所述,在10.4.1中,我们非常注重质量。这种情况在10.4.2中继续存在,其中一项重要工作是新的Delphi Code Insight(又名Delphi LSP)。10.4.2不仅包括许多修复和调整,而且还包括我们不曾使用的不常用的代码见解功能。包含在初始版本中,但还包括一些新的或显着改进的代码完成功能。例如,我们计划在“继承”上添加ctrl单击,并在“使用”子句中添加返工完成。

    C ++代码见解

    C ++继续以持续的质量工作为主题,重点放在两个领域。

    使用Clang编译器时,对所有C ++客户来说,最引人注目的将是C ++代码完成的完整版本。在10.3中,当我们升级到C ++ 17时,我们不得不替换IDE使用的代码完成技术。自推出以来,我们一直在增强每个发行版中的代码完成能力,以解决特定的代码模式或项目设置可能会导致完成问题的用例。

    对于10.4.2,我们决定对C ++的代码完成进行全面检查,以提供客户所需的开发人员生产力。C ++客户应该发现代码完成和导航工作可靠且良好。

    我们甚至一直在解决一些更困难的情况,例如在头文件中提供完成(比.cpp文件要难得多)!最终结果应该是您要求我们提供的所有信息。

    C ++质量和异常处理

    10.4.2中C ++的另一个重要质量关注点是异常处理。

    异常处理是一个复杂的领域,需要编译器和RTL之间的紧密互操作才能正常工作。对于异常,有一些通用约定,例如,永远不允许异常越过模块边界(例如,抛出到DLL中但被EXE捕获),但是并非总是遵循这些约定,有时是出于很好的理由。在C ++中,我们需要处理C ++异常,OS异常和SEH,同时不要忘记Delphi的异常处理。

    在10.4.2中,我们对异常处理系统进行了大修。随着我们越来越接近发布,我们期待有一篇博客文章详细介绍我们支持的方案。在内部,我们目前看到一些重大改进!

    集成开发环境IDE

    除了专注于两种语言的代码完成之外,IDE还计划了10.4.2的其他工作。

    在10.3版中,我们介绍了当前的两个主题,浅色和深色样式(实际上,深色样式虽然有很大的不同,但在10.2.3中首次引入。这是我们最受欢迎的功能之一。)浅色样式主要是淡蓝。在此版本中,我们添加了第三种样式,该样式使用传统的灰色而不是蓝色作为主要颜色。对于喜欢IDE在2010-XE7时代的外观的人来说,可以将它视为一种复古风格,这是对经典外观的回调。我们还认为,它对于那些需要特殊视力调节的人可能会有用。

    我们还计划围绕桌面布局,多显示器布局,表单设计和类似区域进行进一步的质量工作。这包括允许您在打开该表单的代码的同时在表单设计器中设计表单。从反馈中得知,这是使用旧的,没有对接的设计器的最常见原因,我们已在10.4.1中删除了该设计器,我们很高兴让您使用现代设计器在表单单元中进行代码和设计。

    最后,我们想增强设置迁移工具,以帮助将RAD Studio设置从一个版本移动到另一个版本(例如从10.3到10.4),并在转移到更新版本(例如从10.4.1到10.4.2)时更好地保留您的配置。 )。我们计划为每种方案添加特定的预设配置,并且除了今天考虑的注册表设置之外,还包括配置文件。

    Marco Cantu对10.4.2计划的评论

    目标操作系统方面,我们目前专注于改进10.4.x支持的现有平台,而针对10.4.2我们正在致力于两个重点领域。 

    首先是我们持续关注Windows作为主要目标的一部分。在Microsoft操作系统上,我们正在密切关注Microsoft当前通过Project Reunion统一WinRT API和传统Win API的方向。Project Reunion(https://github.com/microsoft/ProjectReunion)包含不同的技术,最初的技术是WinUI 3,WebView2和MSIX。WebView2控件是嵌入Edge Chromium的新Windows平台组件。TEdgeBrowser VCL组件在10.4中提供了对此功能的支持。 

    第二个构建块将是对我们计划用于10.4.2的MSIX打包格式的支持。MSIX是APPX的后继产品,APPX是RAD Studio IDE桌面桥接器集成中目前提供的目标,适用于Microsoft Store和企业部署。

    我们对Windows平台(特别是对VCL应用程序)的改进支持的另一个方面是增加了两个新控件,旨在帮助我们的客户现代化和改进其应用程序的用户体验。我们正在开发新的VCL本机Windows控件,以便您可以为客户提供更现代的UI:

    • 一种是高度优化的虚拟列表视图,它使您可以通过文本和图形的灵活组合来显示大量项目。该控件将宽松地基于现有DBCtrlGrid控件的方法,但是不需要数据源。它将支持使用实时绑定。
    • 我们要添加的另一个新的VCL组件是一个数字输入控件,类似于WinUI NumberBox平台控件。该控件考虑了不同的格式(整数,浮点数,货币值),还包括简单的表达式求值,从而提供了更轻松,更流畅的数字输入。

    我们改进的第二部分着眼于当前支持的目标平台。我们计划在RAD Studio 10.4.1推出后与Apple和Google发行的新版本操作系统完全兼容。尽管您今天可以针对这些平台,但仍有一些未解决的问题需要我们正确解决(而不是通过变通办法)。目标是为以下方面提供全面支持:

    • iOS 14和iPadOS 14(Delphi和C ++)
    • macOS 11.0 Big Sur(英特尔)(Delphi)
    • Android 11(Delphi)

    质量方面,我们将继续在10.4.2中继续努力提高稳定性,性能和质量(就像我们在10.4.1中所做的那样)。我们计划解决客户报告的问题,并支持产品许多方面的升级。除了David先前列出的工具和库之外,我们特别关注的工具和库还包括:

    • Delphi编译器(适用于所有平台)可提高其健壮性和向后兼容性,但它特别注重于编译器(和链接器)的性能,以减少大型项目的编译时间,并加快LSP引擎的速度(使用编译器分析源代码)。
    • SOAP客户端库和WSDL导入工具一起使用,该工具生成用于与SOAP服务器接口的客户端代码
    • 并行编程库(PPL),从任务,期货和并行for循环方面提供了不同平台和多核CPU线程功能的出色抽象
    • RAD Studio的多层Web服务解决方案部分,对RAD Server和较旧的DataSnap引擎进行了改进,并对HTTP和REST客户端库进行了常规改进。我们还将继续关注我们的Azure和AWS云支持。
    • VCL样式和HighDPI样式将与VCL一起受到更多关注
    • 对于FireMonkey库,我们将继续改进TMemo组件(在平台版本和样式版本中),10.4中引入的Metal GPU库驱动程序以及Android上的返工传感器管理,以为各种Android设备提供更好的支持。

    RAD Studio 10.5

    供参考,以下是主要路线图幻灯片:

    David Millington对10.5计划的评论

    用户体验

    我们提供了许多很棒的新功能,许多客户都希望将这些功能计划为10.5。

    首先,我们计划在IDE中全面支持DPI。VCL现在已经支持了两个版本的高DPI,并且主要使用VCL的RAD Studio IDE现在也将支持高DPI。这样可以确保在所有现代高分辨率屏幕上清晰呈现,包括在不同分辨率和比例的屏幕上移动窗口时。

    VCL表单设计器是创建应用程序时使用的关键工具之一。设计师的重点是快速构建一个UI,使其外观接近运行应用程序时的外观,而UI工具仅以文本形式描述UI,并且不提供即时反馈/迭代循环。在10.5中,我们计划通过向设计者添加VCL样式支持来扩展外观元素,使其与应用程序运行时的外观相似,因此,当对任何控件进行样式设置时,您也会在设计器中看到它们的样式。

    当您构建跨平台应用程序时,FMX表单设计器同样是关键工具。我们计划提供VCL设计器具有的一些设计工具,例如对齐指南,以确保设计器具有所需的生产力功能。

    我们还计划将重点放在IDE的源代码控制集成上,以帮助您的团队进行协作。此外,我们计划对首次运行IDE的方式进行一些增强,以帮助那些不熟悉Delphi和C ++ Builder的人上手。

    最后,许多客户在专用的构建服务器上使用Delphi或C ++ Builder。除了源代码控制,测试和类似做法外,最好的做法是在特定计算机或VM上进行正式构建。当前,要为构建服务器安装RAD,您需要安装完整的IDE –但这不是必需的,因为构建仅需要命令行工具。我们计划专门针对构建服务器的安装程序方案。

    C ++ Builder

    在10.4.0中,我们为C ++ Win64引入了一个新的调试器。这满足了客户的共同要求,特别是因为我们包含了“格式化程序”,这是一种轻松评估STL容器或任何数据结构(包括您自己的数据)内容的方法。这是一个全新的调试器,而不是我们先前使用的调试器的新版本。在10.5中,我们计划对另一个核心工具链接器进行类似的新替换。像调试器一样,这将用于Win64。

    您会在这里注意到对64位Windows的关注。许多客户都在使用Clang来定位Win64,我们希望确保我们的工具与经典编译器所使用的工具处于同等水平或更好。另外,许多人开始专门研究64位,升级了32位应用程序,而新应用程序仅是64位。

    Visual Assist是Visual C ++惊人的生产力扩展,可提供代码完成,重构等功能。我们一直在研究将其集成到C ++ Builder中的各种方法,并计划在10.5中做到这一点。

    最后,我们还计划改善Delphi / C ++互操作性。能够使用两种语言极大地提高了生产率,并且是使用C ++ Builder或RAD Studio的主要原因之一,而这是改善这种集成的工作。它应该提供与RTL功能的更平滑的集成。

    Delphi调试器

    在10.4中,我们为基于LLDB的C ++ Win64(如上所述)引入了一个全新的调试器。最终,我们的目标是在所有平台上使用相同的调试器–今天,我们混合使用了不同的调试器。这样做的关键是在LLDB中添加Delphi语言前端,这使您可以在“评估/修改”对话框中评估Delphi语法。我们计划在10.5中引入第一个使用LLDB的平台以及这个新的前端。

    Marco Cantu对10.5计划的评论

    平台类

    关于Windows平台,如前所述,我们计划为Microsoft Project Reunion的各种技术提供支持。特别是,在RAD Studio 10.5版本中,我们期待通过WinUI 3库集成对现代Windows UX的支持。根据Microsoft对该库的路线图,应该有可能在基于经典API的本机应用程序中使用该库的组件,并混合使用不同类型的表单和控件。实际的细节将取决于库在与本机应用程序集成方面将提供什么,但是我们当前的计划是将该库与新的特定控件集成到VCL中。

    说到平台,我们想为Delphi应用程序添加一个新目标:一个新的编译器,用于基于ARM的macOS操作系统版本,并带有由Apple Silicon CPU驱动的Apple硬件。您可以运行英特尔应用程序,但目标是为新一代Mac提供本机ARM应用程序。

    这将是Delphi的重要扩展,包括新的编译器,对运行时库和各种高级库的更新。我们还计划扩展所有平台的Delphi语言语法,并提高编译器在Windows上生成的数学处理代码的性能,从而使应用程序在数字处理方面更快。

    我们还将继续致力于整体产品质量,并计划选择一些子系统以进行关注,这是我们通过评估客户对当前版本和即将进行的更新的反馈来做出的决定。

    概要

    我们为即将发布的Delphi,C ++ Builder和RAD Studio制定了一些伟大的计划!从激动人心的更改到两种语言的代码完成,再到高DPI IDE,在编码和设计时提高生产率,Windows UI和新的VCL组件,Delphi调试,对Delphi的Apple Silicon(M1)支持,对编译器,Delphi和C ++ RTL,SOAP,多层等等,是C ++的新链接器-即将发布的版本包含一些非常令人兴奋的工作。我们等不及要把它们交给您!

    注意: 这些计划和路线图代表了我们截至目前的意图,但是我们的发展计划和优先级可能会发生变化。因此,我们无法提供任何承诺或其他形式的保证,即我们将最终按计划的时间表或所描述的顺序或根本不发布任何或所有上述产品。这些开发进度表或“产品路线图”的一般说明不应被解释或解释为任何形式的承诺,我们客户对升级,更新,增强和其他维护版本的权利仅在适用的软件许可协议中阐明。 。、

     

    附录:欢迎加入Delphi开发局QQ群:32422310  Delphi控件源码下载网站  

    完整的开发路线图PPT

     

     

    展开全文
  • 2020年大前端发展趋势

    万次阅读 多人点赞 2019-11-25 11:14:03
    2019 年已步⼊尾声,2020 年前端发展的关键词⼜将有哪些呢?发展的方向又会是什么呢?参考2019年大前端的发展,不出意外,前端依旧会围绕⼩程序、超级APP、跨端开发、前端⼯程化以及新技术运用等几个方面进行展开...

    迅速发展的前端开发,在每⼀年,都为开发者带来了新的关键词。2019 年已步⼊尾声,2020 年前端发展的关键词⼜将有哪些呢?发展的方向又会是什么呢?参考2019年大前端的发展,不出意外,前端依旧会围绕⼩程序、超级APP、跨端开发、前端⼯程化以及新技术运用等几个方面进行展开(可以参考2019年大前端技术趋势深度解读)。

    小程序

    在⼩程序⽅⾯,今年仍然是⼩程序突⻜猛进的⼀年,各⼤主流的 App 都上线了⼩程序能⼒的⽀持,各前端团队也都有了专⻔的⼩程序开发团队,以适应更快的⼩程序开发需求。同时App 中很多关键的功能都被⼩程序所替代,甚⾄有些 App 已经变成 Native ⼩程序壳,上层的应⽤实现全部是⼩程序。

    在微信小程序出现以前,大家在谈 Hybird、ReactNative,但终归只是技术层面的狂欢,始终没有业务属性的注入。小程序的出现,一方面告诉业界在当前设备上 Webview 也没差到哪去,另外一方面告诉业界如何让有能力的商家在超级 APP上进行私域运营。

    另一方面,从技术角度说,在上层 DSL 的严格限制下,超级 APP 就可定义符合自己诉求的 Web 标准,弥补当前 Web 标准的不足,最后和客户端配合,结合离线、预加载、定制Webview 能产出类似于 NSR 等各种酷炫的技术模型,让 Web 在端内低成本达到 Native 版的体验,端外也不会像 Weex 一样有点小别扭。

    不过由于需要依赖超级APP(微信、支付宝、百度、美团、头条等),由于各家平台采用的具体方案的差异,造成目前小程序的落地方案也不一样,有时候需要开发多套代码。

    跨端开发

    跨端开发⽅⾯,RN ⽣态已经⾮常成熟,或者说看不到太多发展前景,因为目前还停留在0.61版本,似乎1.0版本仍然遥遥无期。因此,今年很多团队转战⾕歌⽣态的 Flutter,特别是 Flutter for Web 的第⼀个 Release,⼜让 Web 前端重燃希望、跃跃欲试。

    同时,苹果公司也发布了全新的 UI 系统——SwiftUI,同时,开源社区中 SwiftUI for Web已经在路上了,SwiftUI for Android 还会远吗?

    跨端开发⽅⾯,Flutter 仍会快速发展,并且会有更多的开发者,Flutter on JS、SwiftUIfor Web&Android 也将是开源⽣态值得期待的事情,毕竟跨端仍没有⼀个完美的解决⽅案。

    前端工程化

    在前端⼯程化⽅⾯,开发者最重要的基本素养就是通过⼯具提升效率,⽽前端开发者在这⽅⾯会持续迭代和优化。

    曾经我们谈 Yoman,谈 CLI 等系列构建工具,但在团队大了之后始终觉得差点什么。反观 Java 同学,从没听说过 Spring Boot 配置工程师。今年很多团队都在建设完整的前端 DevOps 流程⼯具集,⼀些团队之间也开始协作共建,不管是 Web 还是⼩程序项⽬,从新建项⽬、开发、联调(tiao)、部署、测试、发布、运维到监控统计,都有完善的⼯具做保障和提效,今后前端⼯程也会越⾛越标准化。

    展望2020年前端的发展,前端工程体系一定会更加闭环,不再是一个脚手架这么简单,而是会结合 IDE,打通业务属性,从项目初始化、到编写代码、到 CI、到灰度、到发布 形成一个完成的闭环。

    Serverless

    Serverless 的⽕爆⼏乎可以归因于前端。因为 Serverless 能够较完美的⽀持Node.js,使⽤ Serverless 帮助前端开发者解决了使⽤Node.js 过程中的诸多问题。

    当前的前端工程师大多都是科班出身,虽不能和正宗的服务端开发同学比,但也可写很多服务端层的业务逻辑。当前已经有很多公司在做 BFF 层,来满足这部分诉求,但依旧摆脱不掉运维、机器分配 这条拦路虎。随着 Serverless 的逐步落地,BFF 这层的代码会摆脱运维、机器分配等复杂的问题,同时大概率会由前端同学写这部分代码,服务端同学专注中台系统的实现。从业务上说,业务的试错成本也会大幅度降低。

    随着 Node.js 成为前端开发者必备技能之后,云计算的不断普及会让Serverless 触⼿可及。当越来越多的开发者尝到研发⾼效的甜头之后,Serverless 必将对前端的研发模式产⽣变⾰。

    同时,使用Serverless的同学一定会使用 TS。这也意味着,2020 不写 TS 可能真的就 Out 了。

    WebAssembly

    WebAssembly 是一种新的字节码格式,目前主流浏览器都已经支WebAssembly。 和 JS 需要解释执行不同的是,WebAssembly 字节码和底层机器码很相似,可以快速装载运行,因此性能相对于 JS 解释执行而言有了极大的提升。 也就是说WebAssembly 并不是一门编程语言,而是一份字节码标准,需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行, 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机。

    有了 WebAssembly,在浏览器上可以跑任何语言。从 Coffee 到 TypeScript,到 Babel,这些都是需要转译为 js 才能被执行的,而 WebAssembly 是在浏览器里嵌入 vm,直接执行,不需要转译,执行效率自然高得多。

    举个例子,AutoCAD 软件是由美国欧特克有限公司(Autodesk)出品的一款自动计算机辅助设计软件,可以用于绘制二维制图和基本三维设计。使用它时,无需懂得编程,即可自动制图,因此它在全球被广泛应用于土木建筑、装饰装潢、工业制图、工程制图、电子工业、服装加工等诸多领域。

    AutoCAD 是由大量 C++ 代码编写的软件,经历了非常多的技术变革,从桌面到移动端再到 web。之前,InfoQ 上有一个演讲,题目是《AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web》,即通过 WebAssembly,让很多年代久远的 C++ 代码在 Web 上可以运行,并且保证了执行效率。

    WebAssembly 的核心 JavaScript 引擎 V8 目前已包含了 Liftoff 这一新款 WebAssembly baseline 编译器。Liftoff 简单快速的代码生成器极大地提升了 WebAssembly 应用的启动速度。2019年,很多的公司都开始投入人力进行WebAssembly的学习个改造,相信2020年WebAssembly会经历爆发式期。

    5G

    2019年一个绕不开的话题就是5G。⾸先,5G 带宽的⼤幅提升带来传统 Web ⻚⾯复杂度的进⼀步提升,如同 2G 到 4G 变⾰过程中⻚⾯从 WAP 的纯⽂本超链接时代变⾰到 4G 全图⽚视频时代。5G 对于⻚⾯的变⾰必将是巨⼤的,但肯定不会⼀蹴⽽就。因为相应的配套设施也需要逐步完善,如硬件性能和浏览器的处理速度。⽽服务端渲染(SSR)肯定是其中⼀个捷径,轻前端重后台,5G 是桥梁,把渲染放后台,不像同构那么简单,需要关注和优化渲染性能。WebAssembly 或许会在这个机遇下得到快速发展,因为它可以⽆缝对接后台多种语⾔,⽽后台渲染的优化也会带来前端⻚⾯研发模式和技术架构的变⾰。

    其次,5G 带来的万物互联,⼜将带来有别于智能⼿机和普通 PC 的多样化的应⽤场景,VR、可穿戴设备、⻋载系统、智能投影、智能交互等⼜会把 Web 带⼊各种各样的垂直领域,这也意味着前端将有更多⼴阔的空间。相信随着5G的大规模商业,会诞生一批新的互联网巨头。

    展开全文
  • AI与传统编译器

    2021-09-22 05:52:09
    AI与传统编译器 至于TVM,现在有很多框架(TF,Pytorch),然后会部署到不同平台(CPU、GPU、TPU),神经网络编译器呢就是把不同框架里写的东西编译成一样的格式再生成到某一平台的代码 再来看传统编译器(更偏向于...

    AI与传统编译器
    至于TVM,现在有很多框架(TF,Pytorch),然后会部署到不同平台(CPU、GPU、TPU),神经网络编译器呢就是把不同框架里写的东西编译成一样的格式再生成到某一平台的代码
    再来看传统编译器(更偏向于LLVM),现在有许多语言(C、ObjC、C++),也有许多平台(x86、arm),编译器做的就是把不同语言编译到同样的中间代码再生成某一平台的代码
    这两个就是把前端的表示进行统一再生成硬件相关的程序,只不过一个前端表示的是神经网络,一个是大家都熟悉的代码,结构类似但实际内部工作大相径庭

    传统编译器:输入高级语言输出低级语言
    神经网络编译器:输入计算图/算子,输出低级语言
    相同点是都做了类似语言转换的工作
    不同点
    传统编译器解决的主要问题是降低编程难度,其次是优化程序性能
    神经网络编译器解决的主要问题是优化程序性能,其次是降低编程难度
    问题

    1. 对于神经网络编译器,如果没有体系结构相关信息的输入是否能生成高效代码(涉及完全自动化的问题)
    2. 当前的技术投入比来看,神经网络编译器和人工算子实现的哪个性价比更高

    神经网络编译器,编译时考虑神经网络有关的特性来优化程序。
    程序优化,解释器vs编译器,JVM,JIT,llvm, Halide,TensorFlow, XLA, ONNX, TVM, MLIR

    AI编译器和传统编译器的本质是一样的,都是一类能够将不同的编程语言所表达code进行转换的program。这也是AI编译器之所以被称之为“编译器”的原因。

    两者的联系
    因为AI编译器出现的比较晚,所以在设计的时候往往会借鉴传统编译器的思路:
    • 两者的理念比较类似。两者都力求通过一种更加通用,更加自动化的方式进行程序优化和代码生成,从而降低手工优化的effort。
    • 两者的软件结构比较类似。一般都分成前端,IR,后端等模块。其中前端负责讲不同的语言的描述转换成统一的IR表述,后端通常会对IR表示进行优化,最终生成可执行的code。IR层用来解耦前端和后端,降低集成的effort。
    • 两者的优化方式比较类似。通常编译器都会对code进行一系列的优化,从而提高performance或者减少memory footprint等。AI编译器和传统编译器都是通过在IR上面,run各种各样的pass,进行优化的。而且,AI编译器往往还会借鉴传统编译器中的一些pass,比如constant folding, dead code elimination等
    • AI编译器通常会依赖于传统编译器。AI编译器在IR上面,对model进行优化之后,通常会有lowering的过程,将优化后的high-level IR转换成传统编译器的low-level IR,然后依赖传统编译器,做最终的机器码生成。
    两者的区别
    两者最根本的区别是应用场景的区别:
    • AI编译器是把一个深度学习模型转换成executable。这里可以把一个深度学习模型理解成一段用DSL(Domain Specific Language)描述的code,而executable就是一段用硬件能理解的机器码描述的code。这正好能对应到compiler的定义。
    • 传统编译器是把一段用高级语言编写的code转换成executable。这里的高级语言可能是C/C++等。这也能够对应到compiler的定义。
    应用场景的区别导致了两者在设计上不同:
    • 两者的IR表达层次有区别。AI编译器一般会有一套high-level的IR,用来更抽象的描述深度学习模型中常用的high-level的运算,比如convolution,matmul等。而传统编译器的IR更偏low-level,用于描述一些更加基本的运算,比如load,store,arithmetic等。有了high-level的IR,AI编译器在描述深度学习模型的时候会更加方便。
    • 两者的优化策略有区别。AI编译器因为是面向AI领域的,在优化时,可以引入更多领域特定的先验知识,从而进行更加high-level,更加aggressive的优化。比如说:
    o AI编译器可以在high-level的IR上面做operator fusion等,而传统编译器在做类似的loop fusion的时候往往更加保守。
    o AI编译器可以降低计算的精度,比如int8, bf16等,因为深度学习模型对计算精度不那么敏感。但传统编译器一般不会做这种优化。
    对神经网络优化,尽量减少逻辑判断,一算到底是最好的。对内存要尽可能优化,降低内存占用。
    神经网就是一组矩阵计算。神经网编译器就是将这组计算针对平台尽可能加速。
    编译神经网络,把一张张计算图编译成cpu的gpu的,或者是某些专用的AI计算设备,比如google 的TPU的指令集合。具体说来就是先来个图剪枝,再来个拓扑序遍历计算图,一边遍历,一边映射为中间表示。
    后面从中间表示到指令集就大同小异了。
    神经网络编译器大概有TVM/Glow/TensorRT/TensorComprehension/XLA/Tiramisu。这些针对的都是神经网络模型推理阶段的优化,从神经网络模型到机器代码的编译。一般过程是 神经网络模型->图优化->中间代码生成(例如Halide)->中间代码优化(例如TC/Tiramisu使用多面体模型进行变换)->机器代码。编译的是神经网络的模型,优化的是网络模型本身,各层数据数据存储的方式(如分块存储,nchw,nhcw),各个算子(如mlp,conv)的计算方式(如向量化,分块)等等。
    传统编译器(GCC,Clang这些)的编译范围更广,是从源代码到机器代码的编译,输入是一段完整的代码,经过了词法分析,语法分析,语义分析,中间代码生成,优化,最后到机器代码。
    联系:
    首先是神经网络编译器,从中间代码到机器代码的过程,可能就对应了传统编译器的整个编译过程,比如Halide->机器代码
    然后,目标都是都要针对目标处理器进行的优化。无论是什么代码/模型,最后的优化,就是如何最大化利用硬件,比如cache的命中率,计算速度啥的,最终目标都是生成好的机器代码。
    神经网络编译器,可以对应用做很多很强的假设,主要以嵌套循环的计算为主,所以可以针对性的进行优化。
    传统编译器的前端也非常厚重,都是以编程语言为输入来生成IR的。而神经网络编译器的主要问题,还是性能优化和适配,所以基本都不做前端,直接用代码手动构造IR。
    针对deep learning的编译器,把应用限制在tensor operator上,做domain specific optimization。传统编译器面向的程序更加general。前者更偏上层,只需要考虑deep models,流行的deep models基本算子就卷积和矩阵乘,后者更偏底层。
    以TVM和LLVM举例,TVM拿到模型的计算图,先用Relay做一下图切分,算子融合,conv-bn-relu之类的,也有人做multiple conv fusion,这一步是graph-level的优化;之后再到算子层面,现在的deep compiler侧重于循环优化,这部分在传统编译器里研究的很多,即使是deep learning领域,能做的domain specific的优化也没多少,auto tuning做的主要还是tiling的参数 (AutoTVM / FlexTensor (ASPLOS 2020) / Ansor (OSDI 2020))。做完operator-level的优化,TVM IR转成LLVM IR,再借助LLVM的各种后端生成可执行代码。
    要部署一个模型,后端可以选择使用手调库,比如厂商库,MKLDNN, CuDNN,某些厂商的,或者第三方的Blas库,算子库,比如阿里的MNN;另外一条路就是选择deep compilers,做代码生成。
    先说deep compiler的缺点。首先编译器能做的工作比较有限,实际的部署,要考虑到模型设计,模型压缩之类的。另外因为比较偏上层,代码生成部分交给了black-box compiler, 很难做到汇编级的调优,能在tuning中避免shared memory bank conflicts,但是,并不能优化掉register bank conflicts,在现有的DSL中也缺乏底层的表达,相比于某些手调库,最终性能不太行。比如说,某些人专门做Winograd Conv的优化,性能都快接近理论极限了 (ppopp 2020)。能想到的缺点都非常细节,觉得未来很容易解决,比如GPU的prefetch,现在TVM里面,用prefetch怎么选它的size和offset基本都会导致性能变差。
    但是,手调库的缺点更加明显,除了耗费人力外,做的优化也是general的,无法cover到具体的input configuration。即使是针对某些input,选择调用不同的kernel,也非常有限。比如MKL-DNN,CuDNN虽然是厂商库,代表了手调的state-of-the-art,可能对3 * 3的卷积做了特殊优化,但对于某些大的feature map或者大的kernel size性能就很差。在某个具体网络上,通过auto-tuning,超过MKL-DNN和CuDNN并不难。AMD的就更不用说了,性能太差了,针对CUDA做的调优,用hipify工具转到ROCm上,性能都强。
    自动调优最重要的是调优之后的性能,其次是调优的时间。
    对TVM了解比较深,对其他的deep compiler了解不多。至少相比于主流框架Torch/TensorFlow来看,当然考虑了这些框架用的底层库,在某个网络上,比如ResNet-18,针对Input大小为(1, 3, 224, 224)做调优,超过还不算太难。因为做的就是inference optimization,实际部署模型的时候,input size都是运行时不再变的,所以这条路可行。
    调优时间上,Ansor调一个网络大概一天左右,比较短了。Facebook有工作做贪心搜索,能把调优时间降到一分钟以内,最终性能也不算差。
    如果指的是针对神经网络的编译器,相对传统编译器最大的不同,引入了multi-level IR。
    传统编译器里分为前端,优化和后端,其中前端和语言打交道,后端和机器打交道,现代编译器的的前端和后端分的很开,共同桥梁就是IR。IR可以说是一种胶水语言,注重逻辑,去掉了平台相关的各种特性,这样为了支持一种新语言或新硬件都会非常方便。
    由于神经网络结构领域的特殊性,这类编译器不光要解决跨平台,还有解决对神经网络本身的优化问题,原先一层的IR就显得远远不够,原因在于如果设计一个方便硬件优化的low level的语言,几乎很难从中推理一些NN中高阶的概念进行优化。比如说LLVM,很难把一连串的循环理解成卷积。一个完善的High level IR,至少需要包括对计算图的表示(DAG, let binding),满足对tensor和operator的支持。
    在这里插入图片描述

    神经网络编译器或者深度学习编译器(下称 DL 编译器),属于一种领域特定编译器,专门用于将神经网络的训练/推理部署到 CPU、GPU、NPU 上。与传统的编译器有着类似的结构,有很多共用的部分,同时也有自己的侧重点。
    关于 DL 编译器,更多谈一下 edge 端 DL 编译器。

    1. DL 编译器产生的背景
      早期神经网络部署的侧重点在于框架和算子库。神经网络可以由数据流图来表示,图上的节点就是算子(比如 Conv2D、BatchNorm、Softmax),节点之间的连接代表 Tensor。由于数据流图很直观,很多框架的 Runtime 采用了类似 Caffe 的方式,运行时通过一定的顺序(例如直接 Post order DFS)分配 Tensor、调用算子库就行了。优化重点在于优化算子库的性能。
      但随着时间的发展,这种直观的部署方式也逐渐暴露出一些问题。
      • 越来越多的新算子被提出,算子库的开发和维护工作量越来越大
      比如提出一个新的 Swish,算子库就要新增 Swish 的实现,还要有优化、测试。Swish由一些基础的一元二元算子组成。
      • NPU 的爆发导致性能可移植性成为一种刚需
      大多数 NPU 作为一种 ASIC 在神经网络场景对计算、存储和 data movement 做了特殊优化,对能效比相对 CPU、GPU 要好很多。在移动端和 edge 端,越来越多的 NPU 开始出现。同时 NPU 的 ISA 千奇百怪,一般也缺乏 GCC、LLVM 等工具链,使得已有的针对 CPU 和 GPU 优化的算子库,很难短期移植到 NPU 上,充分利用硬件的能力达到较好的性能。
      • 更多可优化的点得到关注
      早期 CPU 和 GPU 上带宽问题不是很明显,大家更多关注单个算子的性能。但在移动端和 edge 端的应用中,逐渐遇到了带宽跟不上算力的问题,在这些 target 上增大带宽,意味着功耗和成本的上升,利用算子间的 fusion 和调度,节省带宽开始被重视起来。
    2. 与传统编译器前端的异同
      传统编译器多接受文本类型的编程语言,通过 lexer 和 parser 构造 token 和 AST。
      DL 编译器接收的一般是 DL 框架的模型文件,例如 TensorFlow 的 pb、PyTorch 的 pth,还有 ONNX 等。DL 编译器一般把模型的导入模块叫做 importer,将 DL 框架的模型转换为 DL 编译器的 IR,只跟模型文件格式和 IR 表示耦合,要支持新的框架,只需要新增一个 importer 就行了。
    3. 与传统编译器中后端的异同
      DL 编译器和传统编译器一样,使用 Constant Folding、DCE、CSE 等对 IR 进行优化。
      除此之外,DL 编译器还会有一些领域特定的图优化:
      • 合并冗余、消除无意义的 Transpose、Reshape、Pad
      • 合并 BatchNorm 到 Conv2D、MatMul
      • 对于先 Add 后激活的残差结构,可以将一路输入作为另一路 Conv2D 的初始值
      目前大多数图优化,还是根据经验人工编写 rules,同样有着工作量越来越大,容易陷入局部最优的问题。有一些研究已经开始解决这些问题。应用了传统编译器界研究了很多年的 Equality Saturation 技术。
      图优化之后 DL 编译器,还要进行一些 ISA 相关的优化:
      • Layout
      选择 NCHW 还是 NHWC 还是 NCHW16c 等等,对于算子在特定 ISA 上的效率,会产生影响,需要纳入 cost-model
      • Tiling
      一些 NPU 利用高速片上内存进行计算,容量一般都很有限,编译器需要对大块的计算进行 tiling。对于 Conv2D 这类数据复用很多的计算,如何进行 tiling 对性能和带宽,也有很大影响,选择 tiling 参数,也需要纳入 cost-model
      • Fusion
      一些 NPU 可以 fusion Conv2D 和激活,甚至 fusion 一段一元二元算子组成的计算图。编译器需要根据硬件,提供的能力和 cost-model 选择合适的 fusion 区域,如果贪心去匹配,也容易产生次优结果。
      • Partition
      对于 CPU、DSP、GPU、NPU 组成的异构系统,编译器需要考虑算力、带宽、数据交换的代价,对计算图进行合理地切分。
      这几个优化有时候也需要同时考虑,比如 fusion 多层 Conv2D 时的 tiling 和单层又有不同。
      很多场景下计算图中的 Shape 是已知的,在方便了上述优化的同时,还解锁了下面几个优化:
      • 峰值最小的内存分配
      因为分配释放序列和每次分配的 Buffer 大小已知,可以找到每个 Buffer 的最优分配位置,使得内存峰值占用最小
      • Concat 消除
      对于一些特殊情况,可以通过将几个算子输出的 Buffer 分配到一起,从而避免运行时 Concat 的发生。比较常见的是 densenet 中 Concat 的消除。
    4. DL 编译器特别的地方
      DL 编译器因为领域特定,还包含一些特别的功能。
      • 稀疏
      稀疏存储 Tensor 可以降低带宽。一些 NPU 还可以通过跳过无用计算的方式加速稀疏 Tensor 的计算。
      DL 编译器需要根据数据、Weights 的分布合理选择,对某个 Tensor 是否进行稀疏。
      • 量化
      很多场景下神经网络的推理,不需要太高的数据精度。int8 甚至 int4 已经在工业界落地。模型量化分为训练感知量化(QAT)和训练后量化(PTQ)。大部分用户使用 PTQ,编译器需要利用用户提供的校准集(calibration dataset),得出需要量化的 Tensor 的数据分布,选择非饱和或者饱和量化。
      为了简化,将”面向神经网络的编译器“简称为"AI编译器"。
    5. 关于AI编译器和传统编译器的区别和联系,从形式上可以理解为是输入和输出的区别。AI编译器的输入是建模的DSL描述(可能是python,比如TensorFlow/PyTorch,也可能是Lua,比如上一代的Torch,还可能是Caffe时代的PB描述文件,如果自己手写一个AI框架的自定义DSL),输出通常是传统编译器的输入(LLVM IR也可以视为是广义的传统编译器的输入)。传统编译器的输入是传统编程语言描述的代码,输出的是硬件可执行码。
    6. 透过形式,再深究一下背后的东西。AI编译器和传统编译器的优化原理,有很多共通的地方,比如:
      • 计算图层面的循环不变量优化(Loop Invariant Node Motion),高级语言层面的循环不变量优化(Loop Invariant Code Motion)。
      • 计算图层面的常量折叠和高级语言层面的常量折叠。
      • 计算图层面的peep hole optimization(模板匹配),高级语言层面的peep hole optimization。
      • 计算图层面的strength reduction优化(比如针对Transformer模型的冗余padding计算消除优化,在LightSeq,Faster Transformer的开源代码里都可以看到),高级语言层面的strength reduction优化。
      • 将大量计算零碎算子进行fusion&codegen优化,减少AI框架和访存overhead的优化,将多条高级语言指令进行融合,减少中间变量的访存操作,通过寄存器中转优化,目的上是相似的(细节原理上是不同的)
      • 还有类似TASO这样的工作等等。
      本质上都是在一种或多种表达形式上进行变换,变换的目的是为了优化,优化的标的可能是性能、显存/内存,通信量、功耗等等,在计算图上面结合不同的约束条件,进行变换工作。从这个层面来看,大量的传统编译领域技术,在AI编译领域的应用,只是施加的层次不同。
    7. 与此同时,也会存在一些细节层面的区别。最大的一个区别,AI编译器作为一个domain specific的compiler,其实多了不少可以利用这个domain特性使巧劲的地方,举几个例子:
      • 自动分布式并行。自动分布式并行,可以在不同层面来进行推进,一种方式是在更靠近编译的IR层(比如HLO IR以及TorchScript的IR)来完成自动并行策略的探索。另一种方式是在更靠近建模层的图表示层来做,比如TF Graph/JAX Graph/PyTorch NN module。从系统极致角度来考虑,前者更为究竟,这是看到G-shard,MindSpore的作法,从实现的工程量/效果回报速度来看,后者更为practical,这是看到Horovod/DeepSpeed/Megatron的作法。
      • 关于算子优化,也有不同的作法。一种是通过自动codegen的作法,进行批量化生成,另一种是通过手写(或半手工,类似ATLAS这种计算库里的作法)开发精细的kernel,获得极致的性能。如果AI workload高度diversified,前者更有效率,如果AI workload呈现半收敛态,其实后者反而效率更高。对于新硬件,多出了show case和长尾case的不同考虑,让这个问题变得更复杂了。
      • 结合一些workload甚至业务层面的特点,可以起到“四两拨千斤”的优化效果。几个比较具体的例子,推荐类模型涉及到ID类特征的处理,可能涉及到对字符串类源特征的处理,提前在预处理环节对字符串做ID化,还是在模型里做ID化,对性能影响会非常明显,而这个优化其实不需要复杂的系统优化技术就能达到。另一个例子,如果能够对一些重要的建模库进行干预,在模型写法上,对后端AI框架更为友好,实际上能大大简化后端优化的复杂性,Google开源出的Transformer的代码其实就有TPU-friendly的痕迹。
      这些巧劲得以发挥的一个关键原因,当视野集中在AI domain的关键workload时,可以结合这些workload的特性做一些看起来"overfit",但实现效率更高的设计妥协。而传统编译器,因为打击的workload多样性更强(通用域编译器和domain-specific编译器的区别),所以在leverage workload特性上会更为谨慎,通常会以workload-agnostic的角度来提供优化手段,workload-specific的优化就往往上推到各自domain里了,比如在数据库领域利用编译思想进行JIT优化的工作。
      4.应该如何看待AI编译器在AI系统中的地位和作用。观点是"no silver bullet"。这就好比传统系统领域,存在编译器、库(STL/glibc/…),运行时这若干个component进行组合协同一样,当然可以不使用STL,期望编译器足够的优秀,对于一个普通版本的STL alike的实现,能通过编译手段获得极致性能,但这样决策涉及到在编译器上投入的effort,是否值得就要仔细考虑了。在AI system领域,同样会有类似的分工。对于一个workload,一族workload,整个AI worload的全场景,应该如何在AI编译器、AI底层库、运行时、AI建模库之间进行职能划分,很考验系统设计能力的事情。如果再有机会对硬件设计也有干预,影响到programming model,device compiler的设计,更具挑战,也更有意思的事情了。
      对于社区AI编译领域的一些作法,比如需要用户手工打标签,标识哪段子图可以进行JIT优化是有些diss的,时过境迁,现在觉得这种作法和AI编译的通用优化,不是互斥矛盾的,反而可能是另一种看到了整体工作复杂性以后的trade-off考虑罢了。从系统设计的角度来说,对MLIR的设计理念的认同度也更高了,当然MLIR社区里的声音不够清晰统一。
      1.神经网络编译器背景和历史
      1、早期深度学习框架,重点是框架和库,与编译器关系相对较弱
      比如Tensorflow早期版本,在神经网络/深度学习的编程模型上,主要进行了graph/图和op/算子两层抽象
      • 图层通过声明式的编程方式,然后通过静态图的方式进行执行,这里其实也做了一些编译器的事情,这里包括硬件无关和硬件相关的优化:硬件无关的优化包括编译器通用的优化,如表达式化简、常量折叠,也包括与深度学习/神经网络强相关的,如自动微分等;硬件相关的优化包括简单的算子融合、内存分配优化等。
      • 算子层通常采用手写的方式,比如GPU上基于CUDA/cuDNN。
      这种方式遇到几个问题:
      • 表达上,语法不是Python原生的,算法工程师使用的易用性不够好
      • 更多的Transform出现,比如并行、量化、混合精度等
      • 算子粒度和边界提前确定后,无法充分发挥硬件的性能
      • 硬件厂商提供的算子库也不一定是性能最优的,在SIMT和SIMD的架构中,scheduling、tilling都是有很大的空间,在具体到一个模型,shape确定的情况下,开发者还有可能开发出性能更高的算子。
      • AI专用芯片出现(Google TPU、华为Ascend等),3与4的情况加剧。
      2、后期引入大量编译器的技术进行改进
      • 表达上的改进(Pytorch/TorchScript、JAX)
      Pytorch的Eager Model是一种解决易用性的方案,虽然基本上还是图层和算子两层的抽象,但是整个语法基本上是Python Native的,让算法工程师比较容易上手;不过这个方案在运行的时候,基于Python解释器的能力,不是一种高性能的解决方案,本身与神经网络的编译器关系不大;但是其表达的方式成为后面框架参考的标杆,图层的神经网络编译器主要就是考虑如何把这样表达转换到图层的IR进行优化,目前主要有两种方式:
      AST-Based:以Pytorch TorchScript为例,主要通过Python的修饰符,把Python代码的AST拿到,然后变换成图层的IR,进行编译优化。
      Tracing-Based:以JAX为例,主要把Python代码假执行一遍,保存执行序列,基于执行序列,变换到图层IR进行编译优化。
      两种方案各有优缺点,第一种方案实现复杂,第二种方案在一些处理上有限制(比如控制流的处理)。
      • 性能上的优化(XLA/TVM/TC)
      性能上的优化思路其实比较统一,就是打开图和算子的边界,进行重新组合优化。
      XLA:基本上的思路,把图层下发的子图中的算子全部打开成小算子,然后基于这张小算子组成的子图,进行编译优化,包括buffer fusion、水平融合等,这里的关键是大算子怎样打开、小算子如何重新融合、新的大的算子(kernel)怎样生成,整体设计主要通过HLO/LLO/LLVM层lowering实现,所有规则都是手工提前指定。
      TVM:分为Relay和TVM两层,Relay主要关注图层,TVM主要关注算子层,总体思路与XLA是类似的,也是拿到前端给一张子图进行优化,Relay关注算子间的融合、TVM关注新的算子和kernel的生成,区别在于TVM是一个开放的架构,Relay目标是可以接入各种前端,TVM也是一个可以独立使用的算子开发和编译的工具(基于Halide IR,最新演进到自己定义的TIR),TVM在算子实现方面采用了compute和schedule分离的方案,开发人员通过compute,设计计算的逻辑,通过schedule来指定调度优化的逻辑。
      TC(Tensor Comprehensions):开发者发现算子的计算逻辑的开发,比较容易的,但是schedule的开发非常困难,既要了解算法的逻辑,又要熟悉硬件的体系架构,更重要的是,图算边界打开后,小算子融合后,生成新的算子和kernel,这些新的算子compute是容易确定的(小算子compute的组合),但是schedule却很难生成,传统的方法就是事先定义一大堆schedule模板,万一组合的新算子不在模板之内,性能就可能比较差,甚至出错; TC则希望通过Polyhedra model,实现auto schedule,降低开发门槛,当然这个项目基本已经停更了,类似的工作在MLIR、MindSpore上,还在不停发展。
      • 图层和算子层的IR表达
      在神经网络编译器发展过程中,有多种IR的出现,各有特点:
      图层IR:朴素的DataflowIR、函数式IR、函数式图IR、SSA风格IR
      算子层IR:HalideIR、LLVM等
      图算融合表达:MLIR
      以前分析过图层IR,供参考:
      2.回到问题
      1、神经网络编译器与传统编译器的相同点
      神经网络编译器和传统编译器一样,也是有前端表达、硬件无关优化和硬件相关优化、最后的codegen等,整体结构是类似的。
      2、神经网络编译器与传统编译器的区别
      主要体现在神经网络编译器,像数据库的SQL引擎/向量化引擎一样,一个特定领域的编译器,这些领域特征包括:以Python为主的动态解释器语言的前端、多层IR设计(图层/算子层/codegen)、面向神经网络的特定优化(自动微分、量化/混合精度、大规模并行、张量运算/循环优化等)。
      • 编译前端解析
      与传统编译器不同,神经网络编译器通常不需要lexer/parser,而是基于前端语言(如Python)的AST,将模型解析,构造为计算图IR,侧重于保留shape、layout等Tensor计算特征信息,当然部分编译器还能保留控制流的信息。
      这里的难点在于,Python是一种灵活度极高的解释执行的语言,像弱类型、灵活的数据结构等,而神经网络编译器本质上是偏静态,两者之间的完全转化是不大可能的。
      • 多层IR设计
      为什么需要多层IR设计,主要是为了同时满足易用性与高性能这两类需求。为了让开发者使用方便,框架前端(图层)会尽量对Tensor计算进行抽象封装,开发者只要关注模型和粗粒度OP;而在后端算子性能优化时,又可以打破算子的边界,从更细粒度的循环调度等维度,结合不同的硬件特点完成优化。因此,多层IR设计无疑是较好的选择。
      High-level IR(图层IR),如XLA的HLO,TVM的Relay IR,MindSpore的MindIR等,重点关注非循环相关的优化。除了传统编译器中常见的常量折叠、代数化简、公共子表达式等优化外,还会完成Layout转换,算子融合等优化,通过分析和优化现有网络计算图逻辑,对原有计算逻辑进行拆分、重组、融合等操作,减少算子执行间隙的开销,提升设备计算资源利用率,实现网络整体执行时间的优化。
      Low-level IR,如TVM的TIR,HalideIR,以及isl schedule tree[7]等。针对Low-level IR主要有循环变换、循环切分等调度相关的优化,与硬件intrinsic映射、内存分配等后端pass优化。自动调度优化,主要包含了基于搜索的自动调度优化(如ansor)和基于polyhedral编译技术的自动调度优化(如TC和MindAKG)。
      有人可能会问,图层和算子层的表达和编译能否放在一起?也许可以,但是明显看到这样做面临几个挑战:
      1、整图展开到原子算子,看上去编译的规模/复杂度,指数级上升
      2、显然图编译优化的问题和算子编译优化的问题,有明显的区别,一个关注变换和融合,另外一个关注循环优化,放在一起对编译器实现的复杂度是个比较大的挑战
      3、要看到硬件供应商和框架供应商目前是分开的,两者总是需要一个边界。
      • 面向神经网络的特定优化
      自动微分:BP是深度学习/神经网络最有代表的部分,目前相对已经比较成熟,基于计算图的自动微分、基于Tape和运算符重载的自动微分方案、基于source2source的自动微分,都是现在主流的方案。
      并行优化:随着深度学习的模型规模越来越大,模型的并行优化,也成为编译优化的一部分,包括:数据并行、算子级模型并行、Pipeline模型并行、优化器模型并行和重计算等
      张量计算/循环优化:循环优化其实是一个古老的编译器的难题,在高性能计算领域,循环优化已经研究了几十年,一直没有很好的解决,但是看上去,深度学习/神经网络领域的问题,要简单一点,原因是这个领域大量的以Dense的矩阵运算为主,不像高性能计算领域那么复杂(大量稀疏/非规则的矩阵和向量运算),这为循环优化带来了很大的空间,不过即便是这样,自动scheduling、自动tilling、自动向量化这些理想的方案和技术也还远远没有成熟。
      量化/…:推理侧常用的一些变换。
      3)神经网络编译器未来的方向探讨
      编译器形态:也许需要两类编译器同时存在,一类是面向极致高性能的AOT编译器,同时这类编译器对NPU更加友好;另外一类是JIT编译器,适合与动态图配合;
      IR形态:需不需要MLIR这种统一的形态?
      自动并行:配合Cost model,提供自动并行优化的能力;
      自动Scheduling/Tilling/Tensorizing:可能很难全部做到,能支持大部分也可以。

    参考链接:
    https://www.zhihu.com/question/396105855
    参考文献:
    [1] Tensorflow. https://github.com/tensorflow/tensorflow
    [2] MindSpore. https://gitee.com/mindspore/mindspore
    [3] Tvm. https://tvm.apache.org/
    [4] XLA. https://www.tensorflow.org/xla
    [5]TensorComprehensions.https://github.com/facebookresearch/TensorComprehensions
    [6] Li, Mingzhen and Liu, Yi, etc. The deep learning compiler: A comprehensive survey. IEEE Transactions on Parallel and Distributed Systems. 2020
    [7] Polyhedral Compilation. https://polyhedral.info. Accessed February 4, 2020.
    [8] Zheng, Lianmin, etc. Ansor: Generating high-performance tensor programs for deep learning. Symposium on Operating Systems Design and Implementation. 2020
    [9] MindAKG. https://gitee.com/mindspore/akg
    [10] ^TASO: Optimizing Deep Learning Computation with Automatic Generation of Graph Substitutions https://cs.stanford.edu/~zhihao/papers/sosp19.pdf
    [11] ^abEquality Saturation for Tensor Graph Superoptimization https://arxiv.org/pdf/2101.01332.pdf

    展开全文
  • 2020 年前端技术发展盘点

    万次阅读 多人点赞 2021-03-30 08:36:09
    但是在 2020 年里面前端技术的发展依然没有停止脚步。 而我们作为前端开发者,必定需要对技术的更新换代有所了解。虽然我们不需要去学习所有新出来的技术。但是时刻保持 “了解” 和 “理解” 这些技术是有必要的。...
  • 前不久华为开发者大会上,华为给出了鸿蒙OS及方舟编译器的开源时间表,这着实让开发者们兴奋了一把。现在华为兑现承诺,8月31日,华为方舟编译器开源官网正式上线了。 方舟开源,自主托管 根据公布的信息,本次...
  • 关注+星标公众号,不错过精彩内容作者 |strongerHuang微信公众号 |strongerHuangKeil MDK 是否支持编译器?有没有办法选择其他编译器?可能你使用其他G...
  • 2020 年热门编程语言的发展方向

    千次阅读 2020-02-19 09:30:00
    时间行至 2020 年,对于编程语言的未来发展,很多人会更多的期待。因此,我们向多位编程专家征询了他们对热门编程语言的看法。Python今年 Python 最大的新闻是,其创造者和“终身...
  • 今天,复杂而泛在的软件架构支撑着全球经济,编译器和高级语言正是这些软件的基石。...我们还将提出四项建议,均来自美国科学基金资助的“编译器研究和教育的未来发展研讨会”上的主要内容。 ...
  • 在这个新版本中,我们对 Intel 系列的 C++ 和 Fortran 编译器做了全平台支持,并且改进了上个版本新加的 Wasm 工具链支持,同时对 Qt SDK for Wasm 也进行了支持。 另外,我们还将 luajit 升级到最新的 v2.1 版
  • 从2019看2020前端发展趋势

    千次阅读 2020-01-01 00:11:07
    从2019看2020前端发展趋势 2020前端趋势之愚见 前言 作为工程师不仅仅应当有理性的分解问题和研究技术本身带来的快感,更应当有对技术的敏锐观察或者说对技术趋势的判断以及其对应于场景的运用和实践,从过往的2019...
  • 包含: 解释器、即时编译器、垃圾回收器 作用: 执行引擎(Execution Engine)的任务就是将字节码指令解释/编译为对应平台上的本地机器指令才可以。简单来说,JVM中的执行引擎充当了将高级语言翻译为机器语言的译者。 ...
  • 9月7日,笔者到华为北研所,参加华为方舟编译器(以下简称“方舟”)的开源主题沙龙。 正赶上饭点,点了个安徽板面。 各个档口的师傅,热情招呼着。 “瓜哥凉面”的档口,还排起了队,要知道这可是周六! 看来...
  • 这个算是连接顶层和体系结构的部分,之所以有深度学习编译器的需求,是因为我们的模型从各式各样的顶层框架训练出来(Pytorch, Tensorflow, MXNet, Caffe等 ),但很多时候并不是还在训练时用的平台部署来进行推理,...
  • Grace Hopper为Remington Rand工作,是在第一个著 名的编译器——A-o.上开始设计工作。当Rand在1957年发布这个语言时,它被称为MATH-MATIC。 1952 AUTOCODE Alick E. Glennie ,他利用自己在曼彻斯特大学的课余时间...
  • 2020 年 8 月 4 日,美国计算机科学家、编译器领域先驱 Frances Allen 因病去世,而这一天,也是她 88 岁的生日。 作为计算机科学背后的研究者,她的名字或许不为众人熟知,但是她的贡献足以让我们每一个人向其致敬...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 4,299
精华内容 1,719
关键字:

编译器的发展2020