优化思维【2】有符号和无符号的本质区别

做题

以下代码打印什么?

1
2
3
4
5
6
7
auto count = sizeof (int);
if (count > -1) {
std::cout << "> -1";
}
else {
std::cout << "<= -1";
}

答案是:<= -1,因为 sizeof (int) 是无符号的,把 auto 改为 int 则结果是 > -1

本质论

当我们声明 unsigned/signed int count 时,unsigned/signed 是变量 count 的使用属性,int 是其容量属性。

所谓使用属性,就是当它存在寄存器或内存时,不管是 unsigned 还是 signed 本质是一样的,但对它进行访问时,就区别对待。

比如对 count 进行加法,unsigned 时用的是 ADD 指令,signed 时用的是 ADC 指令,其余减乘除也都类似地使用不同指令。

再来一个问题:把一个变量保存到文件里,再读出来,怎么知道它是有符号还是无符号?

答案是:如果你不在序列化时考虑符号,则反序列化时,无法知道原来的符号,把它赋值给什么类型的变量它就变成什么类型。

这也是 JSON 文本转对象后,要自己选择数据类型的原因,因为 JSON 文本没表示符号的语法。

结论

优化思路:理解本质,就能了解限制和优化方向。

云游戏开发指南【1】

实用参考

  1. 云游戏的架构设计和技术实现

    https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/79226317

  2. GamingAnywhere

    http://www.gaminganywhere.org

  3. OBS Studio

    https://github.com/obsproject/obs-studio

服务器架构

  • NVIDIA Grid 显卡

  • Windows 8 - 10,最好别用 7。

  • Sandbox 方案

一份授权 Windows 系统大约可以运行 40~50 个游戏实例。

音频

  • 服务器上设置 48000Hz 采样率;

  • 编码器采用 Opus,48000Hz,128kpbs

    1. 音频编码的延迟:需要一个 frame 才能编码,而等待一个 frame 需要时间。比如,48000Hz 的 samplerate 编码到 1024 samples/frame 的 AAC,一个 frame 需要的采集时间是 1000 * 1024 / 48000 = 21.3ms,这个只是采集的理论时间,应用程序的采集间隔还可能增大这个采集延迟,然后还有编码、传输、解码、播放延迟。

      Opus 的 frame size 默认是 960,相比 1024 的 AAC 理论上可以减少一点点延迟,1000 * 960 / 48000 = 20ms。

      Opus 的 frame size 还可以更小,比如 120,但不建议使用,因为 Windows 一次采集 480 samples,frame_size = 120 时,一次采集包含 4 frames,所以延迟和 frame_size = 480 其实是一样的。另外,live555 最小发送单位是 packet,而不是 frame,并且实现上 packet 要等待 960 samples 时长。

      128kpbs 的 Opus 音质几乎已经顶天了,人耳很难分辨,比 mp3 好太多了,网络上流行的高音质 mp3 都是 320kpbs 的。

    2. Opus 是开源并免费的,AAC 好的编解码器都是收费的。

流传输协议

  • RTSP

  • live555

    http://www.live555.com/

    UMU 之前用 live555 2017.07.18 版本时,发现它对 Opus 支持不好,需要改进,当前版本未测。

优化思维【1】字符串去空格

In place 版本

传入的字符串将被改变。

为方便复用,一般会实现 ltrim 和 rtrim 两个函数,然后 trim 函数调用这两者实现。

  • ltrim:从 str 头部开始找到非空格字符,偏移量记为 offset,将 str 左移(move)offset 个字符。

  • rtrim:从 str 尾部向头部找到非空格字符,偏移量记为 offset,将 str 截断为 offset。

一个想当然的实现:

1
2
3
4
trim(str) {
ltrim(str)
rtrim(str)
}

假设 str 是 x 个空格 + y 个分空格 + z 个空格,则以上代码需要把 y + z 个字符向左移动 x 个位置。

更好的实现是:

1
2
3
4
trim(string& str) {
rtrim(str)
ltrim(str)
}

由于先截断,剩 x + y,再去左移,只需要把 y 个字符左移 x 个位置。

优化思路:尽量减少复制,调整顺序也是优化手段。

Copy 版本

传入的字符串不会被改变,返回一个新的字符串。

一个复用前面代码的实现:

1
2
3
4
5
6
string trim_copy(string str) {
// str is a copy
rtrim(str)
ltrim(str)
return str
}

这个版本需要复制 x + y + z 个字符,ltrim 和 rtrim 里面都有找偏移量的代码可以复用,直接找到 y 个非空格字符是起点和终点,复制这 y 个字符就好了。

1
2
3
4
5
6
string trim_copy(const string& str) {
// str is a copy
l = lfind(str)
r = rfind(str)
return str[l, r]
}

优化思路:尽量减少复制。

move

strlen、strcpy、memmove 这类函数,都有一个优化思路:机器字长对齐,一次处理一个机器字。对于长字符串,效果显著。

优化思路:针对硬件特征调整策略。

修复 Clang 编译错误:error: expected unqualified-id

问题

今天编译 EOSIO/eos 出现一些 error: expected unqualified-id

环境

  • 操作系统:macOS Mojave
  • 编译器:AppleClang 10.0.1.10010046
  • SDK:MacOSX10.14.sdk
  • Boost:1.69.0(1.67.0 也有问题,干脆用这个版本)

验证问题

1
2
3
4
5
6
7
8
9
#include <signal.h>

int main() {
::sigset_t sigset;

::sigemptyset(&sigset);
::sigaddset(&sigset, SIGCHLD);
return 0;
}

编译输出:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Scanning dependencies of target signal
[ 50%] Building CXX object CMakeFiles/signal.dir/signal.cpp.o
/Users/umu/umutech/macos-cpp/source/study/posix/signal/signal.cpp:6:5: error: expected unqualified-id
::sigemptyset(&sigset);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/signal.h:125:26: note: expanded from macro 'sigemptyset'
#define sigemptyset(set) (*(set) = 0, 0)
^
/Users/umu/umutech/macos-cpp/source/study/posix/signal/signal.cpp:7:5: error: expected unqualified-id
::sigaddset(&sigset, SIGCHLD);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/signal.h:122:31: note: expanded from macro 'sigaddset'
#define sigaddset(set, signo) (*(set) |= __sigbits(signo), 0)
^
2 errors generated.
make[2]: *** [CMakeFiles/signal.dir/signal.cpp.o] Error 1
make[1]: *** [CMakeFiles/signal.dir/all] Error 2
make: *** [all] Error 2

解决

去掉 sigemptysetsigaddset 前面的 :: 即可。因为他们是宏,宏都是全局的,用 :: 修饰反而错了,严格!

Boost 开发分支上已经修复:

https://github.com/boostorg/process/blob/develop/include/boost/process/detail/posix/wait_for_exit.hpp#L60

https://github.com/boostorg/process/blob/develop/include/boost/process/detail/posix/wait_group.hpp#L65

EOSIO 数据同步

作者: UMU @ MEET.ONE 实验

最近三个月尝试各种方案把 EOSIO 链上交易数据同步到数据库中,踩了不少坑,现总结一下经验。

1. 使用 MongoDB 插件同步 transaction_traces 和 action_traces

原始需求是要链上交易数据,所以先是把 transaction_traces 和 action_traces 都同步。

踩坑:无奈地发现速度跟不上,服务器的时间成本比较高,只能舍弃。

2. 使用 MongoDB 插件同步 transaction_traces

研究插件代码,发现 action_traces 是从 transaction_traces 拆出来的,是重复的,所以把 action_traces 去掉,这次成功追上主网区块高度。

踩坑:transaction_traces 在查询 actions 时不太方便,因为 actions 是放到 transaction_traces 内部的一个数组,要查询具体一个 action 就得分两步走,先在 MongoDB 查询出某个 trx,然后再 actions 数组里遍历。数据库使用端的工程师觉得这样太麻烦,无奈继续放弃这到手的肥肉。

3. 使用 MongoDB 插件同步 action_traces

明确 action_traces 才是客户端想要的后,就只同步 action_traces。

踩坑:action_traces 条数比 transaction_traces 多了三倍以上,又出现追不上区块的问题……

4. 使用 MongoDB 插件同步 action_traces,但只要 transfer 数据

客户端最关心的是 transfer 数据,既然跟不上,就舍弃其它数据。

踩坑:舍弃的数据后期不好补。

5. 考虑 kafka_plugin

有人说 kafka_plugin 同步数据很快,可以追上主网区块。

踩坑:从 kafka_plugin 代码就能看出它没有处理 action_traces,如果还要去后端再拿出来处理,再插入到 MongoDB 里,那开发成本和服务器成本一样又上去了。

6. 从 2019 年的区块开始同步

从 35058781 块开始,插入数据库。之前的区块(1 - 35058780)处理后,仅插入数据量相对很小的 account_controls、accounts、pub_keys,其它数据量大的表不插入。

做这个尝试很重要,因为发现重要的线索:

  • 大约在 2200 万块开始,nodeos 的处理速度下降很多,平均每块要 2-3ms,所以同步慢的原因在于跑 nodeos 的服务器的性能。

  • 在 1 开始的早期区块阶段,同时插入 transaction_traces 和 action_traces,并不能看出比只插入 action_traces 慢,说明 MongoDB 端压力很小。

7. 结论

  • 要追上主网区块高度,nodeos 机器性能要好,2.5GHz CPU 不够用。之前听闻 BOS 要求 BP 使用 4.0GHz 的 CPU,现在看起来也是有道理的……以性能成本换取时间。

  • MongoDB 集群,按之前的文章《为 EOSIO MongoDB 插件搭建高可用集群》的配置,插入阶段毫无压力。

  • 插件代码有些问题,需要优化,最明显的就是 queue_size 的设计不合理,打印处理时间太长的提示也不合理。

    • queue 函数是个模板,所有的 queue 都调用它,但 max_queue_size 和 queue_sleep_time 缺只有一份,这可能导致一个 queue 导致的 queue_sleep_time 加大,影响到其它 queue,即整体的休眠时间会无用地加大。

    • 打印处理时间没有按照 max_queue_size 变化,当 max_queue_size 设置大时,打印就很频繁,带来延迟。

  • 建议:一定要注意成本问题!如果查询量不是很巨大,找点友商的数据源用用就好了,自己搭建的成本好高……但如果查询量太大,或者友商卖太贵,以上经验就是很好的参考了。

Nodejs 实现监控告警

作者: UMU @ MEET.ONE 实验室

钉钉

  1. 选择要接受通知的群,群设置 - 群机器人 - 添加机器人;

  2. 复制 webhook URL,记为 webhook_url;

  3. 发送通知的代码:

1
const fetch = require('node-fetch')

fetch(webhook_url, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    "msgtype": "text",
    "text": {"content": text}
  })
}).then(function(res) {
  if (res.ok) {
    console.log('Dingtalk message sent!')
  } else {
   console.log('status = ' + res.status)
  }
})

Telegram

  1. 添加 @BotFather,发送 /newbot 命令,随提示逐步建立一个机器人,得到这个机器人的 token,记为 bot_token。

  2. 选择要接受通知的 Group 或 Channel,按以下任一方式取得 chat_id:

(1) 转发 Group 或 Channel 内的消息到 @getidsbot

(2) 通过 Web 版查看 Group 或 Channel 的 URL 中,p 参数 的值。

  • 如果是 Group,chat_id 为把 g 前缀替换为负号的负整数。比如 p=g268787210,则 chat_id = '-268787210'

  • 如果是 Channel,chatid 为 前部分,并把 c 前缀替换为 -100 的负整数。比如 p=c1383705039_968667419389618100,则 chat_id = '-1001383705039'

  1. 发送通知的代码:
1
2
3
4
const TelegramBot = require('node-telegram-bot-api')
const bot = new TelegramBot(bot_token, {polling: false})

bot.sendMessage(chat_id, text)

程序员鼓励师系列:EOSIO 智能合约开发从入门到入定

作者: UMU @ MEET.ONE 实验室

常规入门流程

经典三步:

  1. 了解区块链基本概念,了解 EOS 基本情况;

  2. 官方开发者文档

  3. 开始愉快地写代码。

但是,有个很大的问题:开发语言居然是 C++!所以,鼓励师出场了……

这不是 C++,这不是 C++,这真是不是 C++

不信?我们就来试一试:

1
2
3
error: cannot use 'try' with exceptions disabled
try {
^

智能合约的编译目标是 WASM 文件,最终要在 WASM 的 VM 里运行,比如 wabt,这和常规情况下使用原生 C++ 开发可执行程序、静态库、动态库等,有很大不同。

受限部分包括:

  • 语言特性。比如上面举例的 try。

  • 可调用外部函数。比如 CRT 的 rand 函数,再比如您想用 socket 自由通信……没门。

  • 内存访问。这个比较难解释,后面再说。

如果您学过 Golang、Python、nodejs、Java 或其它相近语言,转到智能合约开发,可以说是轻而易举。理由如下:

  1. 智能合约关注业务逻辑,和大部分脚本语言类似。

  2. 智能合约有很强的约束范围,API 很有限,不会要求记忆大量知识。举个例子,它可以使用 boost,但也只是子集,无法使用完全的 boost。

  3. 智能合约有很强的套路,代码是满满的既定格式。熟悉 Hello world,会用基本的命令行工具进行测试,最多只需要 2 天,就会发出“原来这么简单”的感叹。

【高级话题】关于 WASM

多语言支持

如果您学过 Golang、Rust 可能会注意到,它们可以编译成 WASM 文件。比如 Golang 的编译命令为:

1
GOOS=js GOARCH=wasm go build -o hello.wasm

但是找个 Hello world 编译一下,您可能会哭,产生的 WASM 文件有 2.3MB,就获得一个打印信息……(EOS 基本概念:RAM 挺贵的。)

虽然现状是 C++ 一枝独秀,但未来可能会有人开发专门的编译器支持 Golang、Rust 等语言开发 EOS 智能合约。

WASM 逆向

VSCode 安装插件后可以直接打开 WASM 文件,显示 WAST 代码,比如我们随便打开一个 hello.wasm,滚动到末尾,可能会看到以下两行:

1
(data (i32.const 8192) "read\00")
(data (i32.const 8197) "get\00malloc_from_freed was designed to only be called after _heap was completely allocated\00"))

下面我们写个 C++ 代码:

1
2
const char* p = reinterpret_cast<const char*>(8192);
eosio::print(p);

以上代码,打印出 read。如果把 8192 改为 8197,则打印 get;改为 8201,打印 malloc_from_freed was designed to only be called after _heap was completely allocated

这个例子可能吓倒大家,特别交代下,一般开发中,较难遇到逆向……只是想说明 WASM 的内存管理和常规 C++ 开发的可执行程序是不同的,后者把指针指向 8192,是 Process Working Set 的地址,通常来说去读这么低的地址,后果极可能是读异常,挂掉。

划重点:虽然你用 C++ 写代码,但编译后是 WASM 二进制编码,运行时使用 VM,受控性很强,降低了开发难度,也杜绝很多安全问题。

性能问题

为了讨好 Python 程序员,下面用 Python 来写个开平方运算,有这样的:

1
2
3
import math

print(math.sqrt(2.0))

也有这样的:

1
2
3
import numpy

print(numpy.sqrt(2.0))

他们有个共同点——很快……相对 C++ 写的!!有点难以理解?

Python 的 sqrt 函数,其实都是用 C 语言实现的,最终都是调用解释器里的本地代码,速度很快。

原生 C++ 写的本地程序,几乎肯定是比 Python 快的,但我们前面说过:智能合约的 C++ 不是常规的 C++,当它被编译成 WASM 后,我们去看 WAST 代码,会发现 sqrt 的实现整个被塞进 WASM 里,它最终要用 VM 来执行,当然没有 Python 解释器快了!

设计原则

打开任意 WASM 文件,可以看到里面很多 (import 开头的行,这些都是原生 C++ 实现的 API,它们的执行速度就是本地代码的速度,对应官网 API 文档里的 API。

有前面的性能问题,我们不禁要问 EOS 为什么不多做点 API 来提高性能?这是因为维护少量 API 代价比较可控,数量一多就有版本问题,各节点可能因为版本不同步而无法达成共识。

另外,目前的 wabt 功能强大,性能也过得去,对于 sqrt 此类可能并不常用的数学函数,即使用原生 C++ 实现了,性能提升带来的好处,也无法平衡多版本可能带来的风险。

原则上,BP 之间快速达成共识,提升 TPS 才是更值得做的。

EOSIO MongoDB 插件系列:管理技巧

作者: UMU @ MEET.ONE 实验室

总结同步主网数据到 MongoDB 时的常用操作,大部分以 transaction_traces 表为例。

1. nodeos 配置优化

1
2
3
4
5
read-mode = read-only
validation-mode = light

mongodb-queue-size = 2048
abi-serializer-max-time-ms = 15000

2. 首次启动 nodeos

https://eosnode.tools/blocks 下载最新 blocks data,以减少网络同步时间。

首次启动,应使用 --replay-blockchain 参数。

3. 守护 nodeos 进程

目前 nodeos 1.5+ 版本如果优雅退出,下次启动可以无需痛苦的 replay 过程,所以可以监控 nodeos 进程,如果退出就调用。

启动脚本 /home/ubuntu/shell/continue.sh:

1
nohup /usr/local/eosio/bin/nodeos --config-dir /home/ubuntu/nodeos/config-dir --data-dir /home/ubuntu/nodeos/data-dir > /home/ubuntu/shell/`date +%Y-%m-%d_%H-%M`.log 2>&1 &

守护脚本 /home/ubuntu/shell/autorun.sh:

1
ps -C nodeos || /home/ubuntu/shell/continue.sh

添加到计划任务,运行 sudo crontab -e,输入下行并保存、退出:

1
* * * * * /home/ubuntu/shell/autorun.sh

4. 读写用户分离

nodeos 需要写入,使用有写入权限的 EOS 用户,其余情况使用只读权限的 EOSReader 用户,数据库安装之后就尽量不使用管理员用户。

1
2
3
use EOS
db.createUser({"user" : "EOS", "pwd" : "Password", "roles" : [{role : "readWrite", "db" : "EOS"},"dbOwner"]});
db.createUser({"user" : "EOSReader", "pwd" : "password", "roles" : [{role : "read", "db" : "EOS"}]});

5. 查询同步进度

1
2
use EOS
db.transaction_traces.find({}, {"block_num" : 1, "block_time" : 1}, -1).sort({$natural:-1}).pretty()

6. 修复丢失数据

参考《EOSIO MongoDB 插件系列:从 log 中找回丢

EOSIO MongoDB 插件系列:从 log 中找回丢失的插入记录

作者: UMU @ MEET.ONE 实验室

问题

当 MongoDB 因不可抗力故障,nodeos 重启后会丢失上次故障时正在插入的记录。

解决

nodeos 会将插入语句连同错误原因等信息一起写入 log,这给了我们手动修复丢失的机会。下面以 transaction_traces 为例,介绍修复流程。

1. 找出所有失败记录

1
grep 'mongo exception, trans_traces insert:' *.log > lost.txt

2. 从 log 生成 mongo script

1
2
3
4
5
6
echo 'print("++++");
var eos = db.getSiblingDB("EOS");' > lost.js


cat lost.txt | sed -n 's/.*, trans_traces insert: \(.*\), line 920, code.*/eos.transaction_traces.insert(\1)/p' >> lost.js

echo 'print("----");' >> lost.js

3. 导入 MongoDB

1
nohup mongo mongodb://$user:$password@127.0.0.1:$port/admin lost.js > lost.log

纯数字 EOS 账号

作者: UMU @ MEET.ONE 实验室

问题

2018 年最后一个工作日,智能合约开发小哥哥遇到一个奇怪的现象:某个账号给我们合约转账,在 EOS 浏览器上都可以找到记录,但用 cleos get table 在合约的 RAM 里找却找不到!

解决

观测

了解具体情况后,注意到两个事实:

  1. 只有某个特定账号有问题,其它账号很正常。

  2. 那个有问题的账号是纯数字的。

这是 EOS 账号解析的问题,UMU 曾经给 EOS 提过一个相关的 issue:get_table_by_scope parameter lower_bound is NOT properly converted, cause enumeration dead loop #5824,里面有问题产生原因和解决方案。

原因

eosio::name 本质是一个 uint64_t 数字的 base32 编码,编码形式是为了方便人类记忆。举个例子:

shengxiaokai 本质上是 14075216089888066784 (0xc3553675c6a40ce0)

cleos get table 在解析账号时,兼容了这两种表达形式,所以 14075216089888066784shengxiaokai 是等价的。

但本身是纯数字的账号可就有歧义了,比如 313131313131 是当成一个 uint64_t 解释,还是当成 base32?很不巧,解析代码是优先当成 uint64_t 解释的。

解决方案

给纯数字 EOS 账号加上个空格后缀,比如 111122223333 可以改为 "111122223333 "