转载

我从.Net Native中学到了什么

　　英文原文：What I've learned about .NET Native

　　“本文最初发布于 Mark Rendle 的博客，经原作者授权由 InfoQ 中文站翻译并分享。”

　　笔者在 Linux 上安装了 .Net Core runtime，并对新的 CLI、CoreRT、ASP.Net Core 进行了简单的测试与分析。

　　在之前文章中，我终于将整个 .Net Core runtime 和工具都安装到我工作用的 Linux 笔记本了，包括了：

含 CoreCLR runtime 的 ASP.NET Core 1.0-rc1
新的 .NET CLI

　　(根据命名声明，从现在起我将会把 ASP.NET 5 写成 ASP.NET Core)

　　昨晚，我开始尝试在 CoreCLR/CoreFx 上运行各种当前能在 Mono runtime 上运行的 ASP.NET Core 项目。到目前为止它们都能工作，虽然我确实将那些我认为有问题的项目留到了最后，尤其是那些使用了 Azure Storage SDK 中较边缘部分的项目。:)

　　我在台式机上尝试通过那些能同时在 CoreCLR 和 Mono 的 Docker 容器中运行的各种服务来执行一些负载测试，我将会在这里公开那些实验结果。

　　我过去的两天里挖遍了 GitHub 上 dotnet 组织的各个仓库之后，我所见到的让我感到很兴奋。当然，我说的不仅仅是在 Linux 上运行。

　　新的 CLI

　　新的 dotnet CLI 与我大约在去年使用过的 dnx, dnu 和 dnvm 命令有很大差别。那些都是 shell 脚本（或 Bash 函数）；如果你执行一下 cat `which dnx` 就能看见脚本，它用 Mono 运行一个 .Net DLL。

　　但如果你执行 cat `which dotnet` 你将会得到满屏的乱码，因为dotnet是一个本机执行文件。

　　我不知道现在那边具体发展成怎样了。在dotnet-nightly 文件夹里翻一下，有很多大小相近的本机执行文件，这挺怪异的，或许它们只是 .Net 程序集的装载器，但也挺酷的。

　　CoreRT

　　由于好奇让这一切成为可能的基础，我进入了 CoreRT 仓库，里面对 CoreRT 的描述是这样的：

一个为 AOT（ahead of time compilation）场景优化的 .NET Core runtime，附带 .NET Native 编译器工具链。

　　然而什么是工具链呢？

　　我找到了隐藏在文档目录中的 intro-to-corert.md 文件，其中解析了具体的情况。

　　这个项目的开发者（我想应该包含所有在微软内外的贡献者）正在构建一套工具，可以将 MSIL byte-code（由 Roslyn 编译 C# 代码产生）预先编译成本机 x86/64 机器编码。

　　最初默认的实现使用新的 64-bit CLR JIT 编译器（去年夏天发布）RyuJIT 来产生机器编码，但工具链还可以使用其他编译器，包括它们自己引用的 IL-to-C++ compiler (难以置信的小巧) andLLILC，这个是建基于 LLVM 的 CoreCLR 中正在使用的 JIT 编译器，而且将来打算支持 AOT 编译。

　　关于 JIT 与 AOT 的简易备注

　　.NET CLR 包含一个 Just-In-Time (JIT)编译器负责把 MSIL bytecode 转换成本机机器编码。它在你应用程序运行的时候进行转换，而且它是在各方法第一次被调用的时候才进行转换的；因此，“just in time”。这就是为什么同一个程序集能够在不同的 CPU 和操作系统上使用。

　　JIT 编译器，一般来说，是优化成尽可能快地完成编译，而不是产生尽可能好的机器编码。

　　一个 Ahead-Of-Time (AOT) 编译器，能为特定的目标 CPU 和操作系统把所有 MSIL bytecode 预先转换成本机机器编码，所以你无需单独的 runtime 就能够分发应用或程序库。

　　因为 AOT 编译器不像 JIT 编译器那样有微观时间的限制，在大部分情况下能够产生更高效、优化度高的机器编码。

　　CoreRT 自身以 CoreCLR 和程序库的修改版本呈现，用不同的方式进行组织，对依赖项也进行过清理。我猜测至少有些部分开启了更高效的无用代码删除（dead code elimination），使其二进制文件尽可能的小。

　　所有这些意味着 C# 即将进入 Go 的领地 - 一个跨平台、本地编译、带垃圾回收的编程语言。除此之外，C#当然拥有现代语言的特点，比如泛型、async/await 等等。

　　本机 ASP.NET Core

　　在同一个页面， Roadmap 的下面，有这样的描述：

开始，我们的目标是本机可执行（又称“控制台程序”）。之后，我们将会把它扩展到包括 ASP.NET 5 程序...

　　而且除了当前 ASP.NET Core 网站应用的“XCOPY 部署”模型 - 简单地转存一个目录树到服务器外，我们还可以期待“COPY 部署”模型 - 仅转存一个单独的可执行文件。就如同一页面所述，这会导致 Dockerfile 看上去像下面这样：

FROM debian:jessie  EXPOSE 5000  ADD mycompiledapp.exe /   # The .exe is just there to make a point :)  ENTRYPOINT /mycompiledapp

　　还不清楚这工具链是否能静态链接非 .NET 程序库（例如 libuv 或者 libcurl）到本机二进制文件，还是需要以动态链接.dll 或 .so 文件的形式一并安装。两种形式，都将制成十分小巧的 Docker 映像，而且容器的启动也会非常快，不过，这一连串的想法很快引起了对 unikernels 的期待，.NET Native 将来会否支持呢？

　　初步的答案，至少看上去是 “会。会支持的。”

　　这些项目明显都在初级阶段，所以没必要太早地兴奋过头，免得将来在 roadmap 上有些东西会被残忍地杀掉，但总而言之，是时候成为一个 C# 开发者了。

　　致谢：我是受 Tugberk Ugurlu 最近关于这方面的部落文章激发才跳入这个兔子窝的。

正文到此结束