#book
看来大家都陆续上车了
#qtum #
我上午看了这次分享,并且做了一份脑图。这次分享主要是介绍了椭圆曲线相关的内容,感兴趣的可以看看。
同时,量子链也在招聘Rust工程师,感兴趣的可以投简历 yangting at qtum.info
#reviewing #sled
Sled是一个用Rust编写的嵌入式数据库引擎。对于如何存储数据采用了一种非常不同的方法。
Read More
#android
该文作者有个很好的学习习惯,就是每年都给自己制定一个年度的个人项目,今年他的目标是为旧的HTC One X安卓智能手机编写一个可启动内核image。但他今年的计划看来是失败了。虽然失败了,但是他看来也学到了不少东西,在文章里介绍了:
微内核(Little Knrnel),将加载地址设置为KERNEL_LOADING_ADDRESS=0x8000
以使LK到达正确的位置。
交叉编译,在MacOS上为armv7平台交叉编译代码。
详细内容请看原文。
Read More
#mozilla #irc
Mozilla最近宣布将关闭其IRC网络,理由是日益增加的维护和审核负担。距离最终关闭还有几个月的时间,官方建议大家转移到Rust的官方Discord服务器去交流。Discord服务器包含#users
,#help
和#beginners
频道。
如果你想继续使用IRC,那么可以去非官方的freenode频道去交流。
(IRC交流太古老了,为了扩大Rust社区的交流面,使用现代化的通信工具是必须的。)
Read More
更多讨论
#cli
本文介绍了crossterm的使用。
Read More
crossterm
#linkerd #Job
Read More
软件工程师职位
系统工程师职位
#job
该岗位也支持Rust开发
【工作职责】 1、负责AI算法中计算在华为CPU/GPU/NPU等处理器上的计算性能优化,基础库设计;2、负责CNN/RNN/RL等模型的效果评估分析,持续优化到极致;3、负责持续跟踪业界最优实现,超越并创新 4、负责和上下游同事对接,协同交付最优成果;
【任职要求】 1、熟悉计算机体系结构,非常了解现代处理器的特性;2、熟练掌握C,清楚C的常见坑和编程技巧;3、至少熟悉ARM NEON指令集、OpenCL、CUDA中一种, 有性能优化经验;4、熟悉至少一个推理平台开源框架的实现,具有相关经验者优先;5、熟悉机器学习算法,熟悉Caffe,Tensorflow,Pytorch,Mxnet等至少一个主流AI开源框架,具有上述开源项目经验者优先;6、追求极致、理性的心态。
感兴趣的朋友可把简历直接发给@风辰(qq 304128534) ,或发送到 liuwenzhi4 at huawei.com
#keyboard
通过该库可以很容易地自己构建机械键盘。
keyberon
#Graphics
Luminance是Rust实现的一个无状态类型安全的图形库。本来是Haskell实现的,后来作者使用了Rust之后就决定把Rust作为图形库开发的默认语言。可能比gfx-hal更易于使用?
luminance-rs
Read More
#wasm #virtualDOM
dumle
#TravisCI #GitHub
本文教你如何使用TravisCI达到交叉编译的目的。
Read More
#error_handle
本文介绍了一种方法,让你在代码中编写更易于调试的编译错误:compile_error!宏,它也可以配合条件编译使用。
Read More
#search #elasticsearch
本文是对Sonic的创建者Valerian Saliou的采访,也可以帮助我们对Sonic有一个比较全面的了解。
Q: 什么是Sonic?
A: Sonic是一个开源搜索索引服务器,用Rust编写。它构建简单,高性能且轻量级。Sonic接受用户查询,并返回标识符。这些标识符指的是关系数据库中的实际文档(例如,在我们的案例中:消息,文章,CRM联系人等)。Sonic不存储文档,这使得整个系统在存储方面简单而有效,因为从Sonic获取搜索结果的应用程序必须从另一个数据库(例如,MongoDB,MySQL等)提取实际结果数据,因为搜索结果返回的是ID)。
Q: 为什么要创造一个除Solr、ElasticSearch之外的新选择?
A: 我(sonic作者)经营一家名为Crisp的公司,为100,000名用户提供客户支持软件。用户想要搜索他们的消息,我们的一些用户有很多消息。事实证明,使用传统的开源搜索索引软件(例如Elasticsearch等)对我们的免费增值商业模型来说太贵了,因为这些系统很重,因此需要巨大的服务器CPU和RAM。
作为开发人员和系统管理员,我非常喜欢Redis的简单性和速度。在计算机软件中,简单性通常提供速度,这在规模上是一件好事。我将Sonic打造成“可搜索的Redis”:简单的功能,简单的网络协议。
Q: 你为什么决定使用Rust?使用Rust创建Sonic是一种什么样的体验?
A: Rust使整个开发体验更加顺畅。语言的约束(例如,借用检查器,没有NULL值的事实)保证在生产中运行项目时不会遇到某些类型的错误(例如,NULL指针异常和分段错误,这些是在C,C ++或Go等编程语言中不可避免; 是人就会犯错误)。
我过去已经构建了其他Rust项目来大规模支持Crisp基础架构,例如Bloom,Vigil和Constellation(它们也已经在GitHub上开源)。Rust对我来说不是什么新鲜事;总的来说,我喜欢使用这种语言。我2年前的第一个Rust项目有点粗糙,因为你必须花很多时间借助借助检查器“无缘无故”阻挡你。一旦你了解它的工作机制,你就会变得更有效率,并且Rust借用检查器错误也会逐渐变得更加罕见。
总的来说,我可以说在Rust中编写Sonic的经历非常棒。我爱Rust。它也使我成为一个更好的程序员。(同感)
Q: 什么是Sonic Channel?这个功能的灵感是来自Redis吗?
A: Sonic Channel用于通过网络与Sonic通信的协议。由于当今大多数应用程序基础结构都通过网络分布在多台计算机上,因此需要一种基于TCP的协议来将新文本数据推送到索引并查询索引。出于性能原因,我不想像Elasticsearch那样编写基于HTTP的协议。
在发布Sonic之后,我从社区中获得了很多贡献,为最流行的编程语言构建Sonic Channel库(集成):Go,Python,Ruby,Java,PHP和JavaScript(仅在NodeJS上运行)。这使开发人员能够以他们喜欢的编程语言从他们的应用程序中推送数据并搜索Sonic中的项目。它使整个Sonic集成过程更容易调用REST API,更简洁。
Q: 您使用哪些数据结构来支持创建索引和自动完成?
A: 索引存储在LSM(Log-Structured Merge-tree)中,底层使用了RocksDB。为了自动完成,Sonic使用FST(有限状态传感器),BurntSushi在他的博客上的一篇文章中详细解释了这一点。
FST存储在磁盘上,用于每个Sonic(集合,存储桶)对,并且是内存映射的,这意味着实际的FST数据不会加载到RAM中,但访问速度仍然很快。我正在使用的Rust FST实现的缺点是任何构建的FST都是不可变的。如果Sonic存储桶中出现一个新的词,则需要将其推送到FST,因此需要重新构建新的FST。Sonic定期为变异的FST运行合并任务,并在磁盘上添加或删除它们的词。
FST结构不仅用于自动完成,还用于拼写错误校正(例如,它能够将“Englich”校正为“English”)。它使用Levenshtein自动机来实现这一点(给定最大Levenshtein距离相对于单词的长度;即,单词越长,允许的拼写错误越多)。
Q: 你为什么选择RocksDB作为存储?
A: RocksDB(来自Facebook)建立在LevelDB(来自Google)上。
它非常擅长在巨大的密钥空间保持性能稳定,并通过压缩旧数据来最小化磁盘使用(它具有分层数据存储架构,旧数据处于较低级别,可以通过较高但较慢的比率进行压缩或压缩)。
RocksDB改进了LevelDB,并且非常易于配置。这意味着Sonic用户可以通过Sonic配置调整RocksDB的内部结构,以便在服务器硬件的情况下充分利用其设置。
Q: Sonic现在有什么文档?
A: 我写了一篇博文,总结了Sonic的工作原理。后续还打算写大量的文档来解释Sonic的内部工作原理,这个可以在GitHub issues上跟踪。
总的来说,阅读Sonic代码应该有助于理解它的运作方式。我花了很多时间注释我的代码并使其尽可能清晰。
Q: 为什么要用jemalloc ?
A: jemalloc是一个最初为FreeBSD编写的内存分配器。它专为现代CPU架构而设计,在管理多核架构上的内存方面要好得多。但它在单核架构上没有任何好处,但在单CPU的情况下已被证明与旧的分配器一样好。所以在最坏的情况下,它与传统的分配器一样好,最多可以在多核CPU上提供更好的性能并减少内存碎片。
Rust先前使用jemalloc作为其默认分配器,并且最近由于性能以外的原因而移至系统分配器。
Q: 你之前写过数据库吗?如果别人想构建Sonic这样的工具,你有什么建议?
A: 我已经构建了大量的服务器软件,但我从未编写过数据库。数据库可能很难,因为它们涉及大量的锁定策略以防止竞争条件,因此数据库开发人员必须一丝不苟。锁是很难正确的;生产中的锁更难:编写死锁的代码很容易,同时找到发生死锁的原因是痛苦的。
自己创造新事物的最佳方式是了解其他人过去是如何做到的。所以我建议大家可以先看看Snoic的源码实现。
Q: Sonic现在状态如何?还有什么想改进的?
A: 是的,看起来Sonic到目前为止工作得很好。搜索很快,用户很高兴。
我们的Sonic实例索引了5亿个对象(消息,文章,联系人)。压缩索引为20GB,负载下的CPU使用率为1 Intel Xeon核心的10%。Sonic在最差的情况下使用~200MB的RAM用于如此大的索引,而在冷启动时使用20MB的RAM。搜索延迟低于1毫秒。
Read More
sonic
From 日报小组 @Chaos