微软的wasm 和 rust的wasm 方案对比

微软家的:blazor

看图即可见原理。mono.wasm用来构造了一个dotnet解释器。

在blazor被微软收购之前是用的dotnetanywhere,现在换成了mono

然后,直接加载那些dll,执行正经的IL代码。

这个方案,稳健,除了加载容量吓死人

这个helloworld,肉眼可见的压缩后容量超过100K的文件就4个。

开发工具 visual studio 2019

开发语言 IL家族

火狐家的rustwasm

非常干净,代码直接被编译为wasm执行,没有依赖环境

这个helloworld,wasm 压缩后47k,胶水代码4k

开发工具,命令行工具链rust家族,IDE漂泊不定,vscode可以用

开发语言 rust

来互相伤害一下

先拉个表格

方案对比
微软

Blazor


火狐

RustWasm

blabla
原理 把Mono解释器编译为wasm,然后解释执行dotnet dll 直接将rust编译为wasm 思路完全不同
容量
业务代码14K

解释器 压缩后600k

dotnet基础库 压缩后约800k

业务代码与依赖代码均编译在一起,47K 火狐碾压胜
开发语言
dotnet 家族

理论上C# F# VB.net 等,实际上c#为主

rust 定位完全不同
开发工具
visual studio 2019

编译、编辑、代码管理一体化


编译工具 rust 工具链和 wasm-pack 工具链

IDE 官方没有,vscode可以用。


微软碾压胜

我对比了四个维度

工作原理

blazor是直接把mono解释器变成了wasm,用户不需要再接触wasm。这个方案有很高的一致性,兼容性极好。用户不需要了解太多wasm,dotnet开发者即可上手。相当于用wasm写了一个脚本语言,然后用户写脚本。

而rust是直接把用户代码编译为wasm。

这是两个截然不同的方案,微软方案存在二次解析和GC,性能会有一定折扣。

容量

blazor的容量惊人,仅解释器和dotnet基础库压缩后就达到了1.5M,不压缩4M多。

仅此一条,将极大的限制blazor的使用场景。

rust在这个项目上碾压胜出

开发语言

c# 作为一门已经有很广泛用户基础的语言,其资料丰富程度是无法抵挡的,外加庞大的c#开发者。

而rust 则是一门致力于为难程序员的语言。

rust是c++的挑战者,他更加底层,尤其是在内存相关的设计上极为复杂。

c#有gc,代码编写比较容易。

对程序员友好度来说,自然是c#更优,但项目?何时轮到程序员的感受了。

rust没有gc,代码就小,也没有gc代价,转换成项目语言就是,rust代码比c#代码快,尤其在wasm环境,微软选了解释器,那就会更快(按照lua的效率预测,lua解释器性能大约是c语言同等逻辑的1/22,这个仅作参考)

开发工具

微软visual studio 2019,目前坊间称为宇宙最强IDE,绝非浪得虚名。

而rust 和 wasm-pack 只有命令行工具

rust IDE,目前体验比较好的,依然是微软家的visual studio code

n

100分 对 60分的差距

调试

微软碾压胜,可以在c#直接下断点,调试wasm环境的代码。

火狐的rust这边,还要靠打log,下断点的方法暂时还没有,希望rust生态的蓬勃发能尽快弥补这个短板。

wasm是支持sourcemap的,目前 wasm-pack工具包居然没有直接生成sourcemap,所以没办法在浏览器环境直接看到rust代码,短板啊。

小结

微软太异端,巨大的依赖容量无法实用化。

rust 还是目前wasm开发的首要选择

原文地址:https://www.cnblogs.com/crazylights/p/12151514.html

时间: 2024-10-08 23:11:15

微软的wasm 和 rust的wasm 方案对比的相关文章

上一条下一条方案对比

今天CPU狂飙了一把,分析SQL后揪出真凶: 上一条下一条方案对比,布布扣,bubuko.com

[硬件项目] 2、汽车倒车雷达设计——基于专用倒车雷达芯片GM3101的设计方案与采用CX20106A红外线检测芯片方案对比

前言 尽管每辆汽车都有后视镜,但不可避免地都存在一个后视镜的盲区,倒车雷达则可一定程度帮助驾驶员扫除视野死角和视线模糊的缺陷,提高驾驶安全性.上一节已经分析清倒车雷达的语音模块(上一节),本节将深入分析测距模块的设计. 一.倒车雷达的发展 第0代倒车雷达:“倒车请注意”!只要司机挂上倒档,它就会响起.(然并卵) 第1代倒车雷达:在距车1.5~1.8m处有障碍物,蜂鸣器就会工作,距离越近蜂鸣器越急促.(没有显示,考验司机耳力) 第2代倒车雷达:数码管显示距离数字,3色波段绿.黄.红分别表示安全.警

(转)Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析 数据库表数据量极大(千万条),要求让服务器更加快速地响应用户的需求. 二.解决方案: 1.通过高速服务器Cache缓存数据库数据 2.内存数据库 (这里仅从数据缓存方面考虑,当然,后期可以采用Hadoop+HBase+Hive等分布式存储分析平台) 三.主流解Cache和数据库对比: 上述技术基本上代表了当今在数据存储方面所有的实现方案,其中主要涉及到了普通关系型数据库(MySQL/PostgreSQL),NoSQL数据

传统手工盘点与盘点机盘点方案对比,盘点机的用途,盘点机的价值,汉码科技实时盘点方案

传统的盘点方案: 1.盘点前的准备工作:信息部一般会规划处盘点哪些店铺或者哪些区域,制订好盘点计划,打印好盘点单,下发到相关工作人员. 2.盘点中的盘点工作:盘点工作员拿到盘点单,分组,分区域进行盘点,并将商品数量登记在盘点单上.盘点时一般是一个人点数,一个人查找盘点单并记录数量.由于商品品种上千上万,在这么多的商品中查找到一个商品记录是非常痛苦的一件事情,头晕眼花.有的使用按仓位进行盘点,这种方式查找稍微没那么困难,但是手工记录,手工抄写难免出现误差,并且商品品种多,工作量巨大.传统的手工盘点

私有云存储服务4节点部署各方案对比

近日因工作需要在某高校安装私有云存储系统.部署环境是一台4节点服务器,每个节点有16GB内存,3个硬盘,每个硬盘3TB ,每个节点可用空间约为8TB.部署的目标是充分利用所有的服务器资源,提供可靠的存储服务,同时尽量不要修改我们的系统源代码.由于本人在web服务部署经验尚浅,遂问计于师哥,对比了如下多种部署方案. 1. 原始方案 说明:1节点部署ffmpeg转码服务,1节点部署私有云存储系统(nginx+mysql+php代码).文件读写只在部署了私有云存储的节点进行,日后购买磁盘阵列后将存储挂

Memcache,Redis,MongoDB(数据缓存系统)方案对比与分析

mongodb和memcached不是一个范畴内的东西.mongodb是文档型的非关系型数据库,其优势在于查询功能比较强大,能存储海量数据.mongodb和memcached不存在谁替换谁的问题. 和memcached更为接近的是redis.它们都是内存型数据库,数据保存在内存中,通过tcp直接存取,优势是速度快,并发高,缺点是数据类型有限,查询功能不强,一般用作缓存.在我们团队的项目中,一开始用的是memcached,后来用redis替代. 相比memcached: 1.redis具有持久化机

ActiveMQ的集群方案对比及部署

转载:http://blog.csdn.net/lifetragedy/article/details/51869032 ActiveMQ的集群 内嵌代理所引发的问题: 消息过载 管理混乱 如何解决这些问题--集群的两种方式: Master slave Broker clusters ActiveMQ的集群有两种方式: MASTER/SLAVE模式 Cluster模式 Pure Master Slave Pure master slave的工作方式: 当master broker失效的时候.Sl

动态数据源四种实现方案对比

简单描述需求,当前我们的分析型数据都是不可变的,且每次的分析都是要将整体数据都加载到计算节点进行分析计算,所以基础的存储和缓存都是面向文件的,并不支持对某一行的修改,如果需要Update某些行或者插入新的记录,需要将增量修改与原数据源联合进行复杂的合并操作,对于经常需要修改的数据源尤其是更新某些行的属性值不那么方便,如果只是Append还好,并且还有对这个数据源的实时查询需求,用户希望能够在页面上进行交互式查询,要求响应速度亚秒级别. 看起来这个需求很像是一个数据库所擅长的,但是从另外的角度看,

负载均衡方案对比表

在选择使用何种负载均衡方案的时候,除了考虑工程师本身的熟练程度外,也要理解技术的原理,透过本质才能更好的看问题,下图参考<Linux运维最佳实践>: