以下内容来自于腾讯后台研发工程师johnyao
最近对C++20协程的进行了预研, 作为对比,同时研究了下市面上已经存在的其他协程实现方案。
虽然工作重点是C++20协程的预研,但作为一篇完整的文章, 不可避免的要从协程的基础开始讲起。
本文第一部分介绍现有一些协程的实现方案。如果你已经对协程非常熟悉,尤其是知道栈(stack),帧(frame)在协程知识体系中意义,可以跳过第一部分。
本文第二部分介绍C++20协程的实现。如果你已经对C++20协程有所了解,知道C++20协程的基础实现,可以跳过第二部分。
本书第三部分是实验数据,以及C++20协程在项目内落地的设想,欢迎各位同学参与讨论。
关于协程的定义和实现,并没有像进程和线程那样有统一的标准。而且由于都有一个“程”字,初学者很容易去和线程和进程做类比,往往走进理解的误区。
所以我们一开始只是引用维基的定义,简单说明下协程是什么:“协程是允许执行被挂起与被恢复子例程(也称为子程序 subroutine)”。
这一章节,我从函数切换的寄存器操作入手,继而通过协程的实现,和不同协程分类标准的介绍,帮助读者理解协程的本质。
背景知识
我们都知道进程内存空间被划分为下面的各内存段(引自维基百科Code segment):
- text 代码段
- data 已经初始化的全局数据
- bss 未初始化的全局数据
- heap 堆区
- stack 栈区
对于函数切换以及后面介绍的协程切换,我们最关心的是栈区的内存的管理。
当函数调用发生后,会扩展栈区内存,用于存放函数体内声明的局部变量。当被调函数返回时,则释放这部分内存。每次函数调用扩展的这部分内存我们称之为栈帧。函数调用栈(call stack)就是由栈帧组成的,函数调用和返回就是栈帧(stack frame)入栈出栈的过程。
我们以如下代码为例,看下这个过程中详细步骤。
#include <cstdint>
int64_t f(int p1, int p2, int p3, int p4, int p5, int p6, int p7, int p8)
{
int x = 0;
int y = 0;
int64_t z = 0;
int64_t l = 0;
x++;
p1++;
p7++;
p8++;
return 0;
}
int main()
{
int64_t i = 0;
i++;
i = f(1, 2, 3, 4, 5, 6, 7, 8);
return 0;
}
这里需要一些汇编的基础知识,但由于这部分不是此篇文章的重点,感兴趣的同学可以自行学习。 对于本文要解释的函数切换过程,我们只需要了解如下内容:维持栈帧需要两个寄存器的支持,对于x86_64架构,即%rbp,%rsp。在本文中, 我们把他们称为
- rbp 栈帧基地址寄存: 当前栈帧的起始内存地址。
- rsp 栈顶地址寄存器:整个调用栈的栈顶地址。
此外还需要了解:函数需要执行的下一条指令存放在%rip中,我们称之为指令地址寄存器。
有了如上的背景知识,我们看下在main函数中调用函数f,具体发生了什么。以此来加深栈帧的概念。
根据上一节的内容,在函数f调用发生之前,%rbp指向main函数对应栈帧的基地址。%rsp指向整个栈区的顶地址。
函数调用的第一步是参数传递。上面例子参数传递部分,在gcc编译器下,产生的汇编如下:
pushq $8
pushq $7
movl $6, %r9d
movl $5, %r8d
movl $4, %ecx
movl $3, %edx
movl $2, %esi
movl $1, %edi
参数个数小于等于6时,采用寄存器传递,对于gcc使用的是%rdi, %rsi, %rdx, %rcx, %r8, %r9这6个寄存器。当大于6个参数时,需要使用栈区内存进行传递。本例中的参数7和8,都被执行了压栈操作pushq。 pushq,可以认为是两步操作
- 扩展栈区地址空间,也就是将%rsp寄存器内容增加8。
- 将目的操作数,拷贝到这个新扩展的内存空间。
可以看到参数传递是在调用方完成的。
函数调用产生的汇编代码如下:
call f(int, int, int, int, int, int, int, int)
call指令也相当于三步操作
- 扩展栈区地址空间,也就是将%rsp寄存器内容增加8(x86_64架构)。
- 将%rip的内容(一下条指令,函数返回后需要执行的指令),拷贝到这个地址空间。
- jmp到f函数标号。
pushq %rbp
movq %rsp, %rbp
subq $56, %rsp
被调用函数生成的汇编,需要执行三步初始化操作:
- 保存调用者(main函数)的栈帧基地址寄存器的地址。
- 将当前的栈顶指针,作为新的栈帧的基地址。
- 根据当前栈帧(f函数)内申请的局部变量的总大小,直接扩展栈的大小。这里之所以用sub, 是因为栈的地址空间是从高地址向低地址部分扩展的。
以上部分,可以总结为下图。
需要说明下,虽然为了画图方便,%rsp指向了一个未使用的地址,但实际上栈顶指针指向实际使用的地址: 比如参数传递部分,指向的是参数7的地址; 函数调用部分指向的是返回地址对应的地址。
在被调函数完成相关初始化处理后, **我们称绿色部分为函数f对应的栈帧。也可以把 (%rbp %rip] 部分当做函数f的栈帧。**对栈帧的理解,可能会有些许差别,但在此处并不关键。
理解了上述函数调用的过程后,函数返回的过程可以简单的理解为以上操作的反向操作。
movl $0, %eax
leave
ret
也是三步:
- 函数返回值保存在%rax中。
- leave指令会把当前%rbp的值恢复到%rsp(恢复栈顶);会将保存在f函数栈帧中的main函数的栈帧基地址弹出, 恢复到%rbp寄存器中
- ret指令会将保存在f函数栈帧中的返回地址(main函数函数调用后的下一条指令地址)弹出, 恢复到%rip寄存器中
如果我们理解了上述函数调用的实现细节, 如果我们允许函数f 在执行某些等待异步操作的时机, 将它的执行上下文, 主要是各寄存器(通用寄存器, %rbp, %rsp, %rip等)的值, 保存在某个协程上下文对象(内存)中。
在异步操作完成,需要切换回来时, 我们再将这些保存的值恢复到各寄存器, 那么函数f 就成为了一个协程。当然这个过程还涉及到栈帧这块内存本身的处理, 这点在后面的小节马上介绍。
int64_t f(int p1, int p2, int p3, int p4, int p5, int p6, int p7, int p8)
{
int x = 0;
int y = 0;
int64_t z = 0;
int64_t l = 0;
<等待异步操作-yield>
x++;
p1++;
p7++;
p8++;
return 0;
}
posix ucontex, boost fcontext和tencent libco都是这种类型的协程。 对于有栈协程, 时刻要记住一点: 栈帧中使用的指针型变量, 如果不是指向该栈帧中的局部变量, 在协程恢复后其意义可能已经发生改变。
有栈协程是指协程本身有自己独立的调用栈。基于栈帧切换的协程, 除了寄存器上下文,一般需要我们给协程指定其使用的栈空间。在协程切换后, 你会发现调用方的函数调用栈替换为了, 被调方协程的调用栈。 以libco为例, 协程的寄存器上下文保存在regs[ 14 ], 而协程使用的栈由ss_sp指定。
struct coctx_t
{
\#if defined(__i386__)
void *regs[ 8 ];
\#else
void *regs[ 14 ];
\#endif
size_t ss_size;
char *ss_sp;
};
我们以libco为例看下有栈协程的切换。 libco的协程入口函数遵循如下原型:
typedef void* (coctx_pfn_t)( void s, void* s2 );
在函数切换前,我们要完成对上下文的初始化,主要是完成如下三点:
- 将RSP(此时还不是寄存器,而是保存该寄存器的内存)设置为之前指定的ss_sp对应的地址空间的最大值-8(可以想下为什么设置为栈空间的最大值,前面已经提过)。
- 将返回地址设置为协程函数pfn的起始地址,这样协程上下文切换后,就可以从指定的函数执行。
- 将函数的参数保存在RDI, RSI(此时还不是寄存器,而是保存该寄存器的内存)
int coctx_make(coctx_t* ctx, coctx_pfn_t pfn, const void* s, const void* s1) {
char* sp = ctx->ss_sp + ctx->ss_size - sizeof(void*);
sp = (char*)((unsigned long)sp & -16LL);
memset(ctx->regs, 0, sizeof(ctx->regs));
void** ret_addr = (void**)(sp);
*ret_addr = (void*)pfn;
ctx->regs[kRSP] = sp;
ctx->regs[kRETAddr] = (char*)pfn;
ctx->regs[kRDI] = (char*)s;
ctx->regs[kRSI] = (char*)s1;
return 0;
}
协程的切换过程相较于函数切换的call指令,使用的是coctx_swap函数。这是汇编实现的一个函数,函数原型如下:
extern void coctx_swap(coctx_t*, coctx_t*) asm("coctx_swap");
想下上面的“参数传递”小节,coctx_swap作为一个函数, 在进入该函数前。函数第一个参数coctx_t*会设置到%rdi,这个结构体用于保存切换前的协程上下文。第二个参数会设置到%rsi,这个结构体就是切换后的协程上下文。如果第二个参数对应的上下文结构刚通过上面coctx_make初始化完成。那么通过下述恢复操作,
movq 48(%rsi), %rbp
movq 104(%rsi), %rsp
movq 56(%rsi), %rdi
leaq 8(%rsp), %rsp
pushq 72(%rsi)
movq 64(%rsi), %rsi
ret
关键的寄存器会被设置:
- 设置新协程的栈帧基地址寄存器,此处是0。
- 设置新协程的栈顶地址寄存器(前面已经介绍过,coctx_t结构中指定的ss_sp对应的地址空间的最大值-8)。
- 通过"movq 56(%rsi), %rdi" 把coctx_make的第三个参数 void s放置在参数传递寄存器%rdi。
- 通过"leaq 8(%rsp), %rsp" 将栈顶降低8(用于保存下一步的返回地址)
- 通过"pushq 72(%rsi)" 把coctx_swap返回后执行的指令设置为协程如果为函数pfn(coctx_make的第二个参数) 进行压栈。
- 通过"movq 64(%rsi), %rsi" 把coctx_make的第四个参数 void s1放置在参数传递寄存器%rsi。
- 通过ret指令将第5步的压栈的地址弹出到%rip,开始了新协程函数的执行。
在执行完被调函数初始化后,会开始新的栈的执行,后续该协程栈上的函数调用和普通函数调用没有区别。 完整的流程如下图:
再次说明下,虽然为了画图方便,%rsp指向了一个未使用的地址,但实际上栈顶指针指向实际使用的地址: 比如第二步中,指向返回地址对应的栈空间。
其他的有栈协程切换方式和libco类似,不一一赘述。
libco在协程切换之上,还提供了私有栈和共享栈的封装。 私有栈是针对每个新开的协程都指定独立的栈空间,栈空间不能太大,有越界风险。 共享栈则是定义一个默认线程栈空间大小的栈,多个协程共享同一空间,使用者不用担心越界风险。但在协程切换时,涉及到栈空间的保存。
这种方法, 本人还没有仔细研究。简单说下和其他同事讨论的相关结论: 这种方式并不会执行寄存器级的上下文保存和恢复, 只是将函数执行到的行号记录在协程对象的成员变量中, 协程函数通过switch case和跳转宏, 在恢复执行时跳转到指定的行号继续执行。 这种实现方式就可以认为是一种无栈协程。无栈并不是没有stack。而是在现有的stack上创建协程栈帧。不会为协程指定独立的stack空间。 C++20的原生协程就是此种实现。这里可以提前透露下,相较于其他无栈协程,C++20的原生协程创建的栈帧存在于堆上,我们可称之为堆帧,并不会随函数的挂起而销毁。
关于协程还有一种分类方法,对称,非对称。对称协程只提供了一种协程间的控制转移的语义即pass control, 而非对称提供了两种, invoke和suspend。 利用libco可以实现对称协程,也可以实现非对称协程。但我们一般倾向于实现非对称协程,实现如下程序架构。
c++20的原生协程也是非对称式的。在协程挂起时会返回到它的调用方。但我们还是可以实现它的对称转移,其中原因下篇文章会讲到。 对称协程的控制转移示意图如下:
这一章节我们会给出,C++20协程的定义,并列举协程需要的所有接口。这一章节会一下涌现很多术语和概念,可能你会感到有些困扰,但不用担心,后续章节会逐一解释各个接口的具体使用。
我们先看下C++20协程的定义。C++20协程标准引入了3个新的关键字, co_await, co_yield, co_return。如果一个函数包含了如上3个关键字之一,则该函数就是一个协程。
除了这3个关键字,实现一个C++20协程还需要实现两个鸭子类型,分别是promise type和awaiter type。
举个例子:对于如下函数some_coroutine,由于在函数体内使用了co_await, 所以在C++20标准下,它就成为一个协程。
T some_coroutine(P param)
{
<declare x>
co_await x;
}
按照编译器的约定,该函数的返回值类型T,必须包含名为promise_type的子类型,且该子类型必须拥有约定的接口。
class T
{
public:
class promise_type
{
public:
<method of convention>
};
};
对于co_await操作数x,可能是如下类型:
- 鸭子类型awaiter type。
- 可以通过 T::promise_type::await_transform 接口转换为awaiter type的类型。
- 第三种鸭子类型,awaitable type(和awaiter关系紧密,但有所区别)。
关于上文中提到的三种鸭子类型,我们将相关接口约定列举如下,后续章节会介绍基础接口的使用。
- awaiter type需要实现如下名字的函数:
- await_ready
- await_suspend
- await_resume
- awaitable type需要实现如下的操作符重载:
- operator co_await()
- promise type需要实现如下名字的函数:
- get_return_object
- initial_suspend
- final_suspend
- unhandled_exception
- return_void
- promise type可选实现如下名字的函数:
- return_value
- operater new
- operater delete
- get_return_object_on_allocation_failure
- yield_value
- await_transform
我们先从co_await的语义实现说起。
co_await x;
假设x是我们之前说的awaiter type的变量。我们知道awaiter type有三个必须实现的接口,await_ready, await_suspend, await_resume。
那么co_await的执行过程相当于如下伪代码:(引自参考文献1)
{
if (!awaiter.await_ready())
{
using handle_t = std::experimental::coroutine_handle<P>;
using await_suspend_result_t =
decltype(awaiter.await_suspend(handle_t::from_promise(p)));
<suspend-coroutine>
if constexpr (std::is_void_v<await_suspend_result_t>)
{
awaiter.await_suspend(handle_t::from_promise(p));
<return-to-caller-or-resumer>
}
else
{
static_assert(
std::is_same_v<await_suspend_result_t, bool>,
"await_suspend() must return 'void' or 'bool'.");
if (awaiter.await_suspend(handle_t::from_promise(p)))
{
<return-to-caller-or-resumer>
}
}
<resume-point>
}
return awaiter.await_resume();
}
简单的讲,就是如下步骤
- 首先调用await_ready判断是否需要执行挂起(异步操作是否已经完成)
- 然后调用await_suspend
- 如果返回值是void版本的实现,则直接挂起。
- 如果返回值是bool版本的实现,则根据返回值决定是否挂起。
- 如果返回值是coroutine_handle<>版本的实现,挂起并返回到该返回值对应的协程。
- 当协程唤醒后,会执行await_resume()。其返回值作为(co_await x)表达式的值。
coroutine_handle<>是新出现的一个类型。从名字我们就可以知道,它是协程的句柄。后续在介绍promise type类型时会继续介绍它。
总览部分也提到了co_await操作数x,除了awaiter type,还可能是如下其他类型:
所以对于非awaiter type的x变量,可能经历如下转换步骤(引自参考文献1)。
template<typename P, typename T>
decltype(auto) get_awaitable(P& promise, T&& expr)
{
if constexpr (has_any_await_transform_member_v<P>)
return promise.await_transform(static_cast<T&&>(expr));
else
return static_cast<T&&>(expr);
}
template<typename Awaitable>
decltype(auto) get_awaiter(Awaitable&& awaitable)
{
if constexpr (has_member_operator_co_await_v<Awaitable>)
return static_cast<Awaitable&&>(awaitable).operator co_await();
else if constexpr (has_non_member_operator_co_await_v<Awaitable&&>)
return operator co_await(static_cast<Awaitable&&>(awaitable));
else
return static_cast<Awaitable&&>(awaitable);
}
简单的讲就是:
- 调用T::promise_type::await_transform,将x作为参数传入,返回新的对象y(如果没有定义该函数,y就是x本身)。
- 如果上一步得到的y对象的类重载了co_await()运算符,或者有全局的co_await()运算符,则调用该运算符,返回一个awaiter。
上一小节,我们已经介绍了promise type的其中一个接口await_transform。下面我们继续看下promise type其他接口,借此了解协程函数本身的实现细节。
针对上面的协程some_coroutine,以及它的返回值类型T,调用协程的语句可以理解为如下过程 (引自参考文献1)
// Pretend there's a compiler-generated structure called 'coroutine_frame'
// that holds all of the state needed for the coroutine. It's constructor
// takes a copy of parameters and default-constructs a promise object.
struct coroutine_frame { ... };
T some_coroutine(P param)
{
auto* f = new coroutine_frame(std::forward<P>(param));
auto returnObject = f->promise.get_return_object();
// Start execution of the coroutine body by resuming it.
// This call will return when the coroutine gets to the first
// suspend-point or when the coroutine runs to completion.
coroutine_handle<decltype(f->promise)>::from_promise(f->promise).resume();
// Then the return object is returned to the caller.
return returnObject;
}
如果你对之前文章中提到的函数切换,协程切换还有印象的话,作为一个被调用的函数,他需要保存其局部变量的栈帧空间。 对于C++20的原生协程,可以看到,编译器首先会为协程在堆上分配这块空间,我称之为堆帧。堆栈的大小可以认为是,T::promise_type的大小,协程局部变量以及参数的大小累计相加得到的。
在协程的堆帧上,会同时创建协程对应的T::promise_type的变量。 然后调用其get_return_object()接口。这个接口负责返回一个T类型的变量。 这里有一点我个人的理解:这里的伪代码只是演示方便,执行过程并不会封装为一个函数,并不会启动新的栈帧,而是在原有栈帧上执行此逻辑。所以协程函数返回的T类型的变量,只是一个临时变量。
这里我们再次看到coroutine_handle。在介绍了堆帧后,我们现在可以说,这个句柄维持了指向协程堆帧的指针。我们可以调用该句柄的resume函数恢复挂起状态协程的执行。
协程本身的执行遵循如下伪代码的流程(引自参考文献1)
{
co_await promise.initial_suspend();
try
{
<body-statements>
}
catch (...)
{
promise.unhandled_exception();
}
FinalSuspend:
co_await promise.final_suspend();
}
- 首先会调用协程对应的promise变量的initial_suspend函数,该函数返回值应可以作为co_await的操作数(参见上一小节的内容)。这里主要是允许C++20协程的使用者,可以在协程执行前就挂起。
- 然后开始执行我们编写的协程代码。 执行代码过程中,如果遇到了挂起,则会返回到调用者。
- 最后,无论是否中间经历了挂起,在协程完全结束后,还会调用协程对应的promise变量的final_suspend函数,该函数返回值应可以作为co_await的操作数。这里主要是允许C++20协程的使用者,可以在退出前做适当的处理。
- 这里还需要实现unhandled_exception(),用于处理协程本身未处理的异常。
除此外,promise type还有一个必须实现的接口,return_void() 或者 return value() 二选一。 在使用co_return时, 会调用你实现的函数,并跳转到FinalSuspend。
至此,我们还剩一个关键字没有解释。在协程内调用co_yield
co_yield
相当于调用
co_await promise.yield_value().
也就是说,对于要支持co_yield的协程,promise_type需要实现yield_value函数,同样的,该函数返回值应可以作为co_await的操作数。
有了以上的理解,那么我们及可以实现一个简单的demo了。
std::coroutine_handle<> g_handle;
struct BaseSwapTestCoro
{
struct awaiter
{
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<> h) { g_handle = h; }
void await_resume() {}
};
struct promise_type
{
BaseSwapTestCoro get_return_object() { return {}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {}
void return_void() {}
};
};
需要说明的是std::suspend_never是预定义的变量,表明是nerver suspend的awaiter。
测试代码如下
BaseSwapTestCoro SomeFunc()
{
LOG(0, "in coroutine: before await");
co_await BaseSwapTestCoro::awaiter();
LOG(0, "in coroutine: after await");
}
TEST(base, swap)
{
SomeFunc();
LOG(0, "in main: before resume");
g_handle.resume();
LOG(0, "in main: after resume");
}
测试输出如下
[ RUN ] base.swap
base_test.cpp:29|in coroutine: before await
base_test.cpp:37|in main: before resume
base_test.cpp:31|in coroutine: after await
base_test.cpp:39|in main: after resume
[ OK ] base.swap (0 ms)
关于C++20协程实现的基本原理,先介绍到这么多。如果想进一步了解其他可选接口的使用,可以阅读参考资料1。这里需要说明一点,协程的语义并没有改变C++的基本语法规则,比如:
- co_await BaseSwapTestCoro::awaiter(); 这里会创建awaiter的一个临时变量,那么这个临时变量在该语句执行完成后就会释放。
- 协程退出后,栈帧就会销毁。g_handle就会指向一块已经释放的内存,再次resume就会的导致crash。 所以对于上面的例子,可以在await_resume, 将g_handle置空,以防野指针问题。
在了解了C++20的实现原理后,我做了协程的基础创建和切换的试验
std::coroutine_handle<> g_handle;
struct BaseSwapTestCoro
{
struct awaiter
{
bool await_ready() { return false; }
void await_suspend(std::coroutine_handle<> h) { g_handle = h; }
int await_resume() { return 1; }
};
struct promise_type
{
BaseSwapTestCoro get_return_object() { return {}; }
awaiter initial_suspend() { return awaiter{}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() {}
void return_void() {}
auto await_transform() = delete; // no use co_wait
auto yield_value(int) { return awaiter{}; } // how to use void
};
};
TEST(base, swap)
{
base_swap::SomeFunc();
// test
int MAX_LOOP_COUNT = 1000000;
auto begin = CALC_CLOCK_NOW();
for (int i = 0; i < MAX_LOOP_COUNT; i++)
{
base_swap::g_handle.resume();
}
auto end = CALC_CLOCK_NOW(); // 340ns
LOG(0, "cost %lld ps", CALC_PS_AVG_CLOCK(end - begin, MAX_LOOP_COUNT) / 2);
// EXPECT_EQ(g_counter, MAX_LOOP_COUNT);
}
对比libco的方案,有如下数据
方案 | 耗时(单位:皮秒=0.001纳秒) |
---|---|
libco原生实现 | 17,000 ps |
libco opt by walkerdu2 | 4,243 ps |
c20上下文切换 | 1,660 ps |
此外, 还得到了c20协程创建开销 1,400 ps。
看到这个数据还是很令人振奋的。
考虑项目内的使用情况,我们往往会将某些协程函数进行封装,这样就会出现某个协程函数等待另一个协程函数的请求。
举个例子,某个RPC请求的响应函数,由于需要请求其他的服务,所以被实现为一个协程A。某些常用的其他服务请求被封装为协程B。A使用B完成部分功能。
假设协程调用过程如下
T B()
{
<co_await service b>
}
T A()
{
B();
<其他同步操作>
<co_await service c>
};
之前有提过,C++20协程是非对称的。如果这样实现的话, 在B函数挂起时, 会返回到A协程的下一条语句继续执行。 且B协程后续唤醒后,执行完成相关逻辑,并不会回到A。而是回到他的唤醒者。如下图所示
而我们想得到的效果是某种对称转移的语义(如果对协程的对称性不了解,可以参见前面的章节)。
上面对称转移到语义就要求我们在协程A中可以 co_await B协程, 等待其执行完成。
T A()
{
co_await B();
<其他同步操作>
<co_await service c>
};
参考Lewiss Baker的第四篇文章3,我试着实现了这种对称转移的语义。思路如下 ,针对 co_await B(); 这个语句执行如下步骤:
- B协程启动后通过initial_suspend立即挂起,并返回对应的T类型对象,此T类型对象保存了B协程句柄。
- 通过await_transform将T类型对象转换为一个awaiter type,并在其await_suspend函数,通过保存的B协程句柄,在其对应的promise对象中记录他的调用者A。
- 在B协程被唤醒,执行完后,利用final_suspend,恢复A的执行。
代码地址 https://git.woa.com/johnyao/c20_coroutine/blob/master/include/coro.h
在完成初版的封装后,我们对比了三个方案:项目内已经落地的基于libco的协程池方案,Asio Library内的协程方案,以及本人实验封装的版本。
创建协程测试用例(其中项目内的测试数据由组内的seanxchen提供):
方案 | 耗时(单位:纳秒) |
---|---|
项目内libco协程池 首次创建 | 6436 ns |
项目内libco协程池 预创建 | 140 ns |
C++20实验封装 | 42~368 ns |
C++20 asio co_spawn | 450 ns |
可以看到,有栈协程由于初始化的时候需要额外申请栈区空间等操作,首次使用的时候效率是最低的。达到了微秒级,6.5微秒左右。但由于协程池的使用,在初始化后再次使用,效率是最高的,140ns。Asio Library中使用的co_spawn,则要450 ns。 这里需要说明的是,本人实验封装的版本不包含协程管理的开销,由于没有提供统一的spawn接口,所以协程运行时间和协程的嵌套层级有关系。
C++20的无栈协程,会随着协程调用层级的增加,增加执行耗时。而有栈协程不会有这部分的开销,一旦协程创建成功,则协程内的函数执行就是普通函数调用。所以我只对比了自己的实验封装和Asio Library针对不同嵌套层级的开销。
嵌套层级 | C++20实验封装 | C++20 asio封装 |
---|---|---|
1层(同步) | 42 ns | 34 ns |
3层 | 221 ns | 124 ns |
5层 | 368 ns | 241 ns |
测试用例git地址: https://git.woa.com/johnyao/c20_coroutine/tree/master/tests
以上结果只是初步结论,后续还会持续校验和跟进。
虽然对比项目内现有协程实现,性能有所降低,但个人认为相较于有栈协程,C++20的协程还是有他的优势。
- 基础性能确实优越。
- 语言原生支持, 后续可能有高效的对称转移语义的标准库。
- 堆帧空间可认为不受限制,不用担心爆栈。
作为初步的预研,C++20协程可以总结为,在语言层面实现了一种非对称的无栈协程。作为语言原生支持的协程,基础的效率表现很亮眼。在项目中实际落地,还需要进一步的探索。后续有空闲时间,会继续关注如下三点
- 如何提高协程的对称转移的效率。
- 如何提高协程管理的效率。
- 针对特定框架定制更高效的协程封装。
最后也欢迎感兴趣的同学,一起讨论C++20协程实际落地过程中的最佳实践。
- https://lewissbaker.github.io/2018/09/05/understanding-the-promise-type
- https://github.com/walkerdu/libco
- https://lewissbaker.github.io/2020/05/11/understanding_symmetric_transfer
- https://km.woa.com/articles/show/355152?kmref=search&from_page=1&no=1
欢迎点赞分享,关注@鹅厂架构师,一起探索更多业界领先产品技术。
原文作者:鹅厂架构师