vc 鲜为人知的 __if_exists

阅读更多关于《vc 鲜为人知的 __if_exists》

msdn 中有这样一个示例:

 

但是不能检测某个变量是否有某个成员,象下面这样的代码是不能编译的:

 

 

或许是因为本质上,可以通过其它方法实现这个功能,也就是依据目前的这种机制,也可以达到目的,但是繁琐一些,需要加一个中间层,例如:

检查序列化声明的顺序和成员定义的顺序

阅读更多关于《检查序列化声明的顺序和成员定义的顺序》

DataIO_is_realdump用来推断一个对象是否可以直接通过dump内存来完成序列化,如果可以,在load/save时会有极大的性能提高。 继续阅读

febird.dataio vs boost.serialization 运行性能对比

阅读更多关于《febird.dataio vs boost.serialization 运行性能对比》

代码表示的是数据格式,DATA_IO_LOAD_SAVE 在 <febird/io/DataIO.h> 中定义

对于 boost.serializationDATA_IO_LOAD_SAVE 的定义相当于: 继续阅读

febird.DataIO 和 boost.serialization 编译性能对比

阅读更多关于《febird.DataIO 和 boost.serialization 编译性能对比》

C++ 程序的性能,重要的不光是运行性能,还有编译性能。运行性能就不多说了,编译性能往往被大家忽略,但是,想一下,如果编译一次要花一小时,那每天能编译几次?

和 boost.serialization 相比,febird.DataIO 的运行性能和编译性能都压倒性地胜出: 继续阅读

febird.dataio 优化技术

阅读更多关于《febird.dataio 优化技术》

优化技术主要有两点:

1.         优化的inline

a)         频繁调用的函数都使用inline,但是值得注意的是,在inline的时候,只inline最频繁的分支,很少走到的分支使用非inline函数,例如:

继续阅读

最便捷、最强大、速度最快的C++序列化框架【二】

阅读更多关于《最便捷、最强大、速度最快的C++序列化框架【二】》

目前该框架(DataIO)仅支持二进制。想起序列化支持只需要两个宏 DATA_IO_LOAD_SAVE / DATA_IO_LOAD_SAVE_V,对象成员基本上用“&”连接起来,这样,可以写一个简单的语法分析器,在序列化宏中将成员序列化表达转化成字符串, 继续阅读

Coroutine真的可以大幅提高效率吗?

阅读更多关于《Coroutine真的可以大幅提高效率吗?》

 这段时间一直想用Coroutine来实现我的rpc中异步调用的分派。看了很多Coroutine的资料,感觉它比起线程切换,就是少了个内核调用,少了自动激活,以及一些内和支持的线程状态(errno,tls等)。在处理器状态的存储/恢复,堆栈的切换等方面的开销都是一样的。在x86这样的体系结构下,处理器的状态(寄存器状态)很少,就那么几个寄存器,存储/恢复起来很快。但是,象MIPS,甚至Itanium这样的体系结构,他们的寄存器很多,Itanium甚至有128个64位的寄存器,这样,光寄存器状态就要1024byte!存储/恢复的开销很大。

有时也想,在没有Coroutine的普通函数调用中(不需要切换堆栈),编译器可以使用一些寄存器分配算法,来有效利用寄存器。如果在语言支持的Coroutine中,是否可以通过类似的方式减轻Coroutine切换开销?

使用C++模板实现不需要IDL的RPC【二】

阅读更多关于《使用C++模板实现不需要IDL的RPC【二】》

严格讲,是不需要专用的 IDL 语言,传统 RPC 的 IDL 语言 相应的部分 在这里全部是 C++ 语言本身,也可以把它称作 IDL,是由几个宏实现的: 继续阅读

process–>thread–>coroutine

阅读更多关于《process–>thread–>coroutine》

在现实世界中,基本是是按着这样的顺序演化:process–>thread–>coroutine/fiber

其实是一个context切换开销从大到小的演化,process切换开销最大,需要切换地址空间,所有的CPU状态,所有其他资源

thread切换只需要切换CPU状态,当然是大部分的CPU状态,而coroutine切换,只需要切换很少的CPU状态,而且全部都在用户地址空间运行,不需要到内核空间。

当然,切换coroutine的开销还是比一次函数调用大很多,其实函数调用也是一个cpu状态的切换,不过这个状态要少得多,在x86 windows 上,甚至不必保存所有的寄存器状态(EAX/ECX/EDX在函数调用之间就不用保证,EAX保存返回值),有些调用甚至通过寄存器传递参数……比起coroutine,太微不足道了。

coroutine其实也可以看成是一个保留了以前调用状态(另一个堆栈帧)的函数调用,在寄存器很多的系统上(如Itanium),切换寄存器状态的开销还是比较大的,如果哪一天大家又开始嫌coroutine也太慢,那怎么办?

about boost::shared_ptr

阅读更多关于《about boost::shared_ptr》

boost::shared_ptr 对象中,有两个成员一个是对象 ptr,一个是引用计数类的指针,由于某种原因,我希望把 shared_ptr 放入一个指针大小的地方,却无法实现,只能用 intrusive_ptr,但是牵涉到的类又太多,改起来不现实,仔细想一下,其实 shared_ptr 完全可以只有一个指针大小,只要把对象指针放到引用计数类中就可以了,为什么shared_ptr作者不这么干?是他没想到?我觉得不太可能。或者只是为了减少一次内存访问?我觉得也不太可能。这到底有什么更深层次的原因?