| yibo's profile一个人的圣经BlogLists |  Tools  Help |
|
November 28 龙梦预订了一台龙梦的盒子，虽说还是在测试阶段，但是还是下了订单。 产品规格 
处理器 龙芯2E CPU，主频600MHz-900MHz，支持DDR333内存总线，功耗2-4瓦 整机功耗15-20瓦 November 20 鸟得流感，猪被车撞，我的论文今天下午考试，巨简单，越做越high，心情儿倍儿好，于是去调戏老板。 老板说咱们抽空谈点工作上的事情吧，顿时把耳朵铺开，戏肉来了~~~ 老板首先画了几个圈，说这是鸟，然后问波波说你的兴趣是？赶紧恭谨的问答，网络。老板点点头，给几个鸟拿线连了，说这是鸟网络，我大惊失色。 老板接着又画了几个圈，注上pig，也连上线，我赶紧接话，这是猪网络。嗯，不错，知道他们有什么联系么？母鸡阿~~~~心中仰天悲呼。没关系，但是现在他们和你的论文就有关系了，拿泥！！~~~莫非我要成为一个动物学家？养鸡养猪双博士？前途似锦阿，哈来路亚~~~ 总算没有让我脑子缺氧太久，老板开始解释起来，说Avian Flu是鸟的一种疾病，但是不会直接传染给人，因为DNA不足够相近，鸟的网络代表着鸟的活动规律，或者说一个知识库；但是这种流感容易传染给猪，而猪呢，作为食物在美国各地运输，人与之接触便有可能感染，所以猪的网络便代表了与之相关的专家知识。比如说想知道猪上街被撞的几率么？这是一个O(1)的问题。最后结合病毒生长的模型，可以建立出灾难模型，比如说计算从西海岸传播到东海岸所需的时间。 以前当灾难发生的时候，一些相关领域的专家便集中起来，汇集他们自己的knowledge base，建立数学模型，借助计算机来进行运算。而更进一步的研究是让计算机具有智能，可以根据已有的知识，配合一些模型，计算出一些结果，但是仍然是非常专用化的。我们的目标是制作一个framework和一个engine，每一个专家的输入可以是一个独立的插件，对于给定的问题给予自动建模和回答，听起来很cool吧，但是这篓子捅大了！这玩意儿结合了machine learning/data mining/knowledge retrieving/mathmatical modeling/....别说3年，给我10年都不一定搞得定。我至少得花个2年钻研数学，sigh。 类似三国的"天下大势，分久必合，合久必婚"，鸟得流感，猪被车撞，这将会是我论文的扉页 November 17 Ask God今天去朋友组织的pre-thanks giving dinner，进门时候让填一张表格，末了问一个问题： If you can ask god one question, what will it be? 想了半天，填了个what can I do for you... btw： 去学校图书馆借了66年明报连载版的射雕英雄传，装在一个盒子里，外面写着易碎品，翻起来那叫一个有feeling阿 tips for high performance socket我很少在blog里面写技术的东西，主要是因为一直以来做的都是体力活，上不得大雅之堂。好比春节去丈母娘家吃饭，别人做的是狮子头，虾仁鲍鱼，你一上手就说来个烤地瓜吧，还不立刻被棒打鸳鸯？ 从上周五开始到现在，做Ditributed System的一个编程作业：实现一个RMI，将近一周，还算是比较的用心。在Admire众多人形帮助文件的指点下，终于完工。性能从原先的每秒20个方法调用提高了6.5k倍，达到每秒13k个方法调用，在优化的过程中稍有心得，记录下来，以供参考。这些方法在网上其实都被总结过，但是通过本文，可以给大家一个直观的印象，每一种优化方法的加速比如何。 程序的构架很简单，客户端通过stub调用方法，服务器端接受请求，解析对象id和方法名，找到对应的skel，并且执行。C/S的连接模式为服务器端起一个dispatch线程，对每一个用户process起一个工作线程。灰常简单吧，但是问题出来了，一秒钟只有20个方法调用。 Tune执行过程后发现服务器端真正执行程序的时间只占总时间的0.01%，主要的问题出现在传输和dispatch上。 首先看传输，跟踪发现，一个session中第一次recv时间为1.5E-5量级，之后的recv为0.5s量级！为什么第一次这么的刻骨铭心，现在了解了吧，是第二次的1w倍阿？回想了整个系统中，大部分报文都是不超过200bytes的小报文，控制报文更小，于是禁用了Nagle's algorithm。 setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char*)&yes, sizeof(int)); 立刻性能飚到了4k methods/sec，加速比2k。 然后根据提高linux上socket性能文中所述思路，减少系统调用次数，因为跨越内核/用户边界非常耗时。到底有多耗时呢，把控制报文取消，将其与数据报文合二为一看看吧。这样减少了一次send和recv，原先是总共3次send，3次recv，理论上应该能够有1.5倍的加速比至6kmethods/sec，结果是10kmethods/sec，加速比2.5。这期间有对数据的小优化。 再次Tune发现当调用次数增多时，lock又成了瓶颈，于是优化数据，减少功能，去除引用计数，去掉其他一些临界资源，虽然损失了动态添加/移除方法的功能，同时也潜在影响了实现服务器端GC的功能，但是成功将性能提高到13k/sec. 至于端口重用，目前因为测试所限，没有体现出来，但可以预计在不远的将来当连接数增多时，必有疗效。 setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (const char *) &on, sizeof on); 至于调节TCP窗口，没有任何影响。究其原因，当是应用情景所限，如果通信往来更频繁的话或有帮助。 至于设置MTU以支持巨帧，则南辕北辙。换了文件发送等情景或有所增益。 最后是对程序的一些优化：比如优化服务器端对象的dispatch（给定对象的方法名，找到方法并调用之）函数，考虑到函数命名方式为"Method"+index并且是顺序的，可以使用switch将其优化为O(1)而非O(n)(连续的if)，发现没有帮助，或许是因为一个对象最多的函数成员也就100个，执行时间近似为一个常值吧。倘若方法的index的顺序随机，则编译器会自动转成if序列，无丝毫优化，此时用map为最优(O(lgN))。 倘若用UDP代替TCP呢？假设是在同一台机器的情景下？Apache说这样TCPvsUDP性能不会太多变化，待我有空了试试看。 btw: Marshalling/DeMarshalling的时候需要注意字节对齐 <int i1><string s><int i2> char buf[256]; //Careful char* p=buf; *(int* )p=i1; p+=4; memcpy(p, s.c_str(), s.length()); p+=s.length(); // Align to 4 for int. p = 4*((((uintp_t) p) + 3)/4) *(int *) p = i2; //直接用memcpy搞定得了 memcpy(buf+index, &i1, sizeof(int)); //index+=sizeof(int); memcpy(buf+index, s.c_str(), s.length());//index+=s.length(); memcpy(buf+index, &i2, sizeof(int)); 但是不管上面是如何做的，取的时候同样要注意字节对齐： char * p = buf; i1 = *(int*)p..................................OK p+=sizeof(int); memcpy(temp, p, len)..........OK p+=len i2 = *(int*)p...................ok but wrong value(VC上OK) November 11 夜之第七章上次提到通宵coding的后遗症 1. 打完public以后主动跟一个：外加回车 2. 在Foobar中搜melody时打出method 继续coding... 现在风格逐渐向大师看齐，一抬头便是满墙的*((int*)(dpkt->data->res+index))之类变换，自己都深深为自己的专业精神所打动，优美阿~~~~ 后来....他妈的，debug扒了我一层皮@_@ November 03 有谁能理解这个笑话么？像我这样的宗师竟然都看不懂...here we go 下午，妈妈在睡觉，萝卜在菜地，Leo在织毛衣。 一会儿，妈妈睡醒了。Leo想带妈妈去菜地玩，他说，“萝卜在菜地里，它想拔爸爸，可是它拔不动。我们去帮萝卜拔爸爸还不好？” 妈妈点头说好。于是Leo带着妈妈去了菜地，可是他们发现萝卜和爸爸都不在了。原来萝卜已经把爸爸拔走了。 |
|
|
