图文：是真的吗？_楚天都市报_多媒体报
&第7版 今日求证
第1版 : 要闻第10版 : 武汉民生第11版 : 武汉直击第12版 : 武汉教卫第13版 : 武汉法治第14版 : 武汉街坊第15版 : 武汉跑腿第16版 : 编读往来第17版 : 文娱新闻第18版 : 环球竞技第19版 : 情感讲述第2版 : 聚焦湖北两会第20版 : 悦读时代第21版 : 环球时局第22版 : 中国纵览第23版 : 中国聚焦第24版 : 中国万象第3版 : 聚焦湖北两会第4版 : 聚焦湖北两会第5版 : 今日关注第6版 : 今日话题第7版 : 今日求证第8版 : 楚天写真第9版 : 武汉新闻
?图文：是真的吗？
图文：是真的吗？
&&&&楚天都市报讯&阅读提示&&&&许多司机朋友在冬日早晨开车都小心翼翼。因为路面的薄冰让车辆难以操控。有网友表示，汽车在冰雪路面刹车距离是正常路面的4倍，司机朋友们可以根据刹车距离来调整车辆之间的间距。汽车在冰雪路面的刹车距离真有这么远吗？&&&&冷风劲吹，在外等朋友的时候要是能待在开着空调的车里，该有多惬意。不过，有网友提醒，停车关窗开空调可要当心了，因为很可能会一氧化碳中毒？&&&&冬日必备神器吹风机如果被堵住出风口会引发火灾？用餐巾纸贴在猪肉上能鉴别注水猪肉吗？这些都是真的吗？&&&&本报联合央视财经《是真的吗》栏目进行实验，对以上传言验明真伪，给您带来最贴心的冬日提醒。&&&&冰雪路面刹车距离能达到正常路面4倍以上？&&&&冬日的武汉气温持续在低位徘徊。前一晚道路有洒水车作业后，部分昼夜温差较大地区在早晨出现路面结冰，因此引发不少交通事故。&&&&据楚天都市报报道，在刚刚过去的2013年年底就有多起交通事故因路面结冰而引起。众所周知冰雪路面难刹车，但它的刹车距离到底有多远呢？有网友表示，在冰雪路面刹车距离会高于正常路面4倍以上，这是真的吗？&&&&实验：冰面刹车距离是正常路面6倍还多&&&&实验员通过人工造冰的方式模拟冰雪路面。实验选择了一辆比较常见的运动版四驱轿车作为测试对象。第一次试验将车速定为30千米/小时。经过测量得出，该汽车在正常路面行驶时的刹车距离是3米。然后该汽车通过冰面并进行刹车，此时测量得出的刹车距离是18.8米。也就是说，此时在冰面的刹车距离是正常路面的6倍还多。&&&&那么随着车速的提高，刹车距离又会有什么样的变化呢？&&&&实验将车速提高到40千米/小时时，汽车在正常路面刹车距离为4.2米，在冰雪路面刹车距离为33米，后者是前者的7倍多。当车速提高到50千米/小时时，在正常路面刹车距离为7米，在冰雪路面刹车距离为51米，后者也是前者的7倍多。&&&&经过多次重复试验，测量所得数据相差并不大。&&&&提醒：普通车辆制动距离更长&&&&从试验结果看，冰雪路面的刹车距离确实能达到正常路面的4倍以上。同济大学建筑设计研究院赛车场设计与安全研究室博士姚启明表示，试验是运动版车辆，制动性能较好，如果是普通民用车辆,制动距离会更长一些。&&&&专家提醒，车辆在冰雪路面上行驶易发生溜车、侧滑等情况，引发追尾、侧向相撞等事故。在冰雪路面开车起步要缓，转弯要缓，制动也要缓。行驶保持平稳，控制好车速，保证安全车间距。&&&&餐巾纸能鉴别注水猪肉？&&&&网上流传着一条“用餐巾纸鉴别注水猪肉”的传闻，声称将干净的餐巾纸贴在猪肉上，稍压半分钟左右，如果餐巾纸能基本完整地揭下来，且可以点燃，那就是正常猪肉；反之说明肉中水分较多，可能是注水猪肉。这是真的吗？&&&&实验：纸巾燃烧验不出注水与否&&&&实验员将5块猪肉分别做1号到5号的样品标签。1号和2号样品的纸巾，当燃烧到被浸湿的部分时，几乎立即停止了燃烧。3号样品的纸巾燃烧得不充分。4号样品的燃烧效果较好但同样未完全燃烧。5号样品纸巾几乎燃尽。根据网传理论，初步可判断1号、2号、3号样品是注水猪肉，4号、5号样品不是注水猪肉。&&&&农业部农产品质量监督检验测试中心检验员周子莹对5份样品做专业检测。结果显示，1号至5号样品水分含量分别为80.2%、73.1%、78%、75.6%和74%。&&&&周子莹表示，根据我国标准规定，畜禽和猪肉水分含量不能大于77%，如果大于这个值就是注水产品。由此可知，1号和3号是注水猪肉，2号、4号和5号为合格产品。也就是说，燃烧试验和专业检测的结果无法对应，用餐巾纸并不能辨别出注水猪肉。&&&&提醒：实际操作不可行判断注水肉有三招&&&&专业人士表示，这种方法理论上有一定依据，但实际不太可行，只能作为参考，但并不准确。&&&&生活中可以通过以下方法简单鉴别注水猪肉：一为“看”，正常鲜肉表面干燥，而注水猪肉则颜色暗淡，下方还会有血水；二为“按”，正常的鲜肉弹性好，而注水肉按压缺少弹性，无法迅速恢复；三为“割”，割开猪肉后，正常鲜肉基本无变化，而注水猪肉马上会有汁液和血水流出。&&&&被堵住出风口的吹风机会着火？&&&&冬天洗头后，总要用吹风机把头发吹干防止着凉感冒。不少人也发现了吹风机的新“用途”：用来烘干潮湿的鞋子、难晾干的袜子等，方便又高效。&&&&不过，有的人为了提高烘干速度，干脆把袜子等需要烘干的物品套在吹风机的风筒上。对此，有网友表示，这样做其实很危险，因为吹风机的出风口被覆盖使用时会着火。这是真的吗？&&&&实验：堵住出风口的吹风机被烧焦&&&&实验员准备了一只有些潮湿的袜子和电吹风，并做好了安全设施。&&&&实验员将袜子套在吹风机的风筒上，并将其固定好放入透明的防爆屋内，下面铺上了防火毯。&&&&当接通电源后，吹风机便开始工作。15秒过去时，袜子看起来有些干燥，其他一切正常。30秒过去时，吹风机开始冒烟了，随后出现了火星，很快吹风机便蹿起了火苗，而且火势越来越大。实验员赶快关闭电源并灭火。只见吹风机已经被烧得黑乎乎的，袜子虽然已经烘干了，但也有一部分被烧焦。&&&&提醒：勿遮盖吹风机出风口&&&&原来，吹风机主要是由前部的电热丝和后部的小风扇组成。外壳一般也都采用的是塑料材质。&&&&当出风口被遮盖时，就会严重影响到吹风机散热。过高的温度很容易导致塑料外壳和覆盖物的燃烧。&&&&因此，市民在使用吹风机时一定要提高警惕，不能将其出风口遮盖住影响其散热，以免产生安全隐患甚至引发火灾。&&&&停车闭窗开空调会中毒？&&&&在冬季，开车的人们在等人或休息时，大多会打开车内空调取暖。但有网友表示，这种行为其实非常危险。因为有可能造成一氧化碳中毒。严重者甚至会昏迷乃至死亡。在报纸报道中，也经常能看到司机在车内休息时遭遇不幸的新闻。&&&&关窗开车内空调真的会使一氧化碳浓度超出限值而中毒吗？&&&&实验：一小时车内一氧化碳浓度超标&&&&实验人员选择了一辆普通家用小轿车作测试，将一氧化碳测试仪放置在车内，用微型摄像机记录仪器数值的变化。&&&&随后，实验员打开车内空调，关闭车窗、车门。测试仪器的数值很快发生了变化。一个小时过去后，车内的一氧化碳浓度已经升高到了7ppm，比测试之初升高了30多倍，但并未超过健康限值。&&&&那么，在相对封闭的环境内，车内情况又如何呢？&&&&实验人员把车开进了一个面积约为普通私家车库4倍大小的房间里进行第二次试验。摄像机显示，到第28分钟时，车内的一氧化碳浓度已达到了7ppm，而户外需要一个小时才达到该数值。当测试时间达到一个小时时，车内的一氧化碳浓度已经达到了10.1ppm，并以约每10秒0.1ppm的速度继续增长。这已经超过了一氧化碳浓度的健康限值。&&&&据专业医师介绍，燃料不充分燃烧易产生一氧化碳，它极易与血红蛋白结合，使血红蛋白丧失携氧功能，造成组织窒息，尤其对大脑皮质的影响最为严重。一氧化碳浓度对成年人的健康限值是小于10ppm，如果超过10ppm，就可能会对人体产生一定影响。&&&&提醒：停车开空调注意保持通风&&&&北京吉利大学汽车学院汽车试验实训技术中心副教授徐春保表示，汽车怠速的时候，进入发动机的油比较多，气比较少，汽油不完全燃烧就会产生一氧化碳，比其他转速的时候产生的一氧化碳都要高得多。打开车内空调，这些气体就会被吸进去一部分。&&&&徐春保还表示，密闭环境中车排放出的废气会充斥在整个车周围，随后被吸金车内。&&&&因此，司机在车内休息又开着空调时，一定要注意开窗通风。《怎样识别水货程序员》说的是真的吗？
见下面链接：&br&&a class=& wrap external& href=&/note//& target=&_blank& rel=&nofollow noreferrer&&怎样识别水货程序员&i class=&icon-external&&&/i&&/a&&br&&blockquote&
怎样识别水货程序员
&br&&a href=&/people/jgs/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Sinclair&i class=&icon-external&&&/i&&/a&
&br&今天来灌个水。&br&水货程序员泛滥的时代，装大神也容易的多。扒几张皮给你看看。&br&首先，有些公认的水货，比如熊节，根本就是一个文艺编辑，就不用废话了。&br&其次，有争议的，比如陈皓。这货的博客多年保持livelock状态。什么意思呢，就是看起来系统还是在跑，但没有任何有用功。常年都是给入门马农做科普的内容。&br&这种属于大自然的搬运工，把搜索引擎里的资料编译一下就拿来做自己的内容。&br&然后是比较隐藏的水货。比如陈硕。言必让读者看自己的书第几页。但他那本书纯属&br&基础知识和常识列举。看几个man page和rfc就够了。另外，他的书里错误很多，&br&言之凿凿的地方其实都是挂一漏万，把特例当公理。&br&云风当属最隐蔽的水货。都是实打实的产品，代码，难题，分析。内容都是网络，&br&高性能，并发，分布。但不幸的是，老子才是这方面的行家。就拿他最新那个所谓的乐观悲观锁来说吧，里面每个结论每个分析我都指出其不靠谱之处。&br&还有其他一些水货，就不一一列举了。&br&&br&他们有如下显著特征:&br&话题以程序科普为主。&br&内容都是在其他它地方能轻易获得的，缺少自己的思想。&br&问题分析流于猜测，不能达到问题本质。&br&轻易下结论，下过多总结陈词。&br&缺乏量化分析，以主观感受和特例作为依据。&br&&br&如果有不服的，欢迎讨论。我可以具体问题具体分析给你看，他们的思想有多毛糙，基本功有多不扎实。&/blockquote&此人第二篇：&a href=&/note//& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&怎样识别正品程序员&i class=&icon-external&&&/i&&/a&&br&&blockquote&好，最后一篇灌水。以后绝不灌水了。&br&&br&扯谁比谁厉害都没意义，第一是因为山外有山，第二是因为术业有专攻。水货和正品的区别不是水平而是态度。我认可的态度第一是打破沙锅问到底，第二是有自己的想法，第三是有常识。&br&&br&云风那个乐观悲观锁是个好的反面栗子，可以看看他的态度有多毛糙。&br&&br&碰到性能问题，第一步是简化场景，第二步是量化分析。简化场景可以帮你更容易发现热点，也更容易搭起测试环境，而不是靠线上程序的反应来查找热点。量化分析是性能问题的唯一解决方法，除此之外其它方法都是瞎蒙。&br&&br&云风两件事都没干。他猜了下问题是lock的方式引起的，然后没有任何测试数据依据就把cas改成了spinlock，最后根据线上程序的反应，说问题得到了解决。我不知道他怎么能说服自己安心睡觉。&br&&br&这个问题正确的解决方法如下。首先是把程序执行逻辑拆开成可以单独profile的单元，根据profiling的结果找到热点。然后把有问题的部分单独提出到测试环境，用模拟的压力测试重现问题。这是一个递归的过程，直到热点的范围能精确到源代码某一两行，甚至到某一两条指令上。------这就叫常识。要在只有很少symptom的情况下，知道该做什么以及怎么做。&br&&br&然后开始考虑这一两条指令为什么会引起性能问题。通常profiler的数据都会给出明确提示，这个性能问题其实是branch miss或者d$ miss或者i$ miss。但也有时候看不出明显的原因，那你就得多想一点，是不是deadlock/livelock，是不是甚至可能不是performance而是correctness的一个表现方式，如果是的话，有什么测试可以证明这个想法。通常这时候你不需要跟任何人讨论，因为跟其他人思想同步的过程纯属浪费时间。-----这就叫有自己的想法。任何能用搜索引擎找到正确答案的问题都不是问题，但有些问题是在哪也找不到答案的，只有靠自己想。&br&&br&有了自己的想法，接下来就是要获得验证。这里必须搬出量化分析。换个姿势再来一次，看看各种miss是否有稳定的减少，时间是否有稳定的降低，具体降低了百分之几。更优的解法必须通过这个过程来获得。但有些问题注定是无解的，因为性能问题最终都要回归到trade-off上，而且需要trade out的部分甚至可能是correctness。&br&&br&你回过头再看看云风是怎么“解决”问题的。不知道根据什么，匆匆得出个结论说“多核心无助于提高队列的性能”，然后依据此结论推出spinlock比cas更高效。这种既没有上下文，又没有数据支持，又笼统的结论，连说服自己都难。&br&&br&还有个没提到的态度，是打破沙锅问到底。你们可以翻翻我之前几篇日记，其中之一提到了一个想法，就是有没有可能在软件里借鉴bus的设计来做分布式系统。到目前为止没有结果。归其原因是我对bus了解的还太少了。bus protocol只是暴露出来的冰山一角，bus的atomicy也是一个虚拟的概念。实际当中，cache controller的state-machine有几个transient的状态，每条transaction的原子性也不是仅仅靠arbiter来解决的。不搞清楚这些内在的设计就不知道实现bus的黑魔法到底是怎么回事。很有可能最后还是个dead end，但我必须把bus的设计搞清楚，另外directory-based的系统也同样要搞清楚。&br&&br&干码农这行就是得有这样的动力，要分析性能吗？那必须知道从register到LLC到memory bus的全部细节，要知道pipeline上所有hazard的全部细节，要知道store/load buffer是怎么干扰program order的，要知道out-of-order哪些情况下是不可避免的、哪些情况下是邪恶的。&br&要知道TCP状态是怎么跳转的吗？那么不仅要读几乎所有的TCP rfc，还要把Linux/BSD的stack翻一遍--因为implementation和rfc是相互参照相互倾轧的。这不是你网上搜一个TCP FSM图就能明白的。&br&&br&口口声声talk is cheap, show me the code的人，Linus的话搬过来也压不死人。代码只是记录思想的工具，而且绝大部分代码都是废话。看书比写代码重要的多的多。&br&&br&最后说一下我认同的正品程序员。银神我很佩服，冰河我很钦佩，知乎/微博上的温兆伦也不错。&/blockquote&
见下面链接：
怎样识别水货程序员
今天来灌个水。水货程序员泛滥的时代，装大神也容易的多。扒几张皮给你看看。首先，有些公认的水货，比如熊节，根本就是一个文艺编辑，就不用废话了。其次，有争议的，比如陈皓。这货的博客多年保持livelock状态。什么意思呢，就是看起来系统还是在跑，但没有任何有用功。常年都是给入门马农做科普的内容。这种属于大自然的搬运工，把搜索引擎里的资料编译一下就拿来做自己的内容。然后是比较隐藏的水货。比如陈硕。言必让读者看自己的书第几页。但他那本书纯属基础知识和常识列举。看几个man page和rfc就够了。另外，他的书里错误很多，言之凿凿的地方其实都是挂一漏万，把特例当公理。云风当属最隐蔽的水货。都是实打实的产品，代码，难题，分析。内容都是网络，高性能，并发，分布。但不幸的是，老子才是这方面的行家。就拿他最新那个所谓的乐观悲观锁来说吧，里面每个结论每个分析我都指出其不靠谱之处。还有其他一些水货，就不一一列举了。他们有如下显著特征:话题以程序科普为主。…
按投票排序
101 个回答
就对云风改bug 这件事来看，我觉得作者好比是在用实习医生的路子要求多年经验的临床专家。
本来对这个问题没兴趣，不过既然群里的同学多次提起，刚才我又不小心把原帖作者的代码看了....还是过来回复下吧。原帖作者
终于上代码了，那么先评价下他的代码，看看他是否不是“水货程序员”，而是所谓的“并发专家”。 的代码版本1：（参见
的贴图） cas循环里没有重新读取状态进行test，只要cas失败一次，将死循环，致命逻辑错误。坦白说，经验丰富的服务器程序员不可能写出这种代码，犯这种错的我一般当是新手。当然，作者通过构建巧妙的测试，成功避免了这个问题：1个push线程+1个pop线程，总计两个线程的并发profile用例... cas成功过后，立刻"q-&msg[tail & QMSG] = m"、"ret = q-&msg[tail & QMSG]"，这里无锁的读、写，都是非法操作。cas成功，的确局部变量tail暂时保存了合法的写入地址，但一旦此时线程被挂起，其他push线程或pop线程被调度，再连续读/写queue size条消息，导致head/tail wrap，稍后线程1再次被调度时，局部变量tail指向的位置所属权已变更，这行赋值非法。这个bug比较隐晦，但这正是无锁编程必须面对的困难；正因为类似的代码很难写正确，错误又极不明显，所以它才属于专家任务，一般程序员应该极力避免的。连我这个外行都能察觉的问题，作者却轻易犯错，至少他在这里的表现配不上他自诩的“并发专家”的称号。（处理类似的并发细节，陈硕尤其擅长，我本人十分佩服）update1：
问题1修复 问题2依旧update2：（用作者的话说，“教科书级别”的代码）编译错误单线程连续push 10次，容量始终为1...多线程push。线程1执行完"q-&msg[tail & QMSG] = m"过后被挂起，其他线程成功push后，线程1再被调度，此时局部变量head永远小于q-&p.tail，死循环。好吧，这个版本各种逻辑错误，不知道想要干嘛。“教科书”，你教？谁学？update3：我不关心你还有多少个版本，我不关心你在那个双线程profile中比云风的代码快多少，如果不能做到明显没有错误，快又有什么用！而且从你上面每个版本各种竞态，各种逻辑错误来看，你并不具备“并发专家”的素养，事实上，第1个版本的代码已经证明你编程经验不足（甚至说，外行）。顺便谈一下编码风格（针对update3，所谓教科书）：queue.p、queue.c重复声明struct。编译期/运行时不分，QSZ、QMASK既作为编译期常量，又作为queue的字段存储。当然，queue size真的成变量的话，就不能简单的使用mask了。作为库的message queue，为什么接口声明是static inline，就这么在乎这个性能？再谈一下工程师素养在
贴代码之前，我是觉得他的话还是比较有道理的，虽然部分观点偏激。现在我对他的看法是，理论水平暂且不提，至少编码能力还欠佳，学艺不精。至于原帖中，秒天妙地谁都不放眼里，只能是笑话。所谓“第一步是简化场景，第二步是量化分析”，如 Sinclair 这般简化的profile用例，却得到性能高2倍、高3倍的结论，实在荒谬，全没有工程师的严谨。过早优化是万恶之源。错误的实现，快又有什么用？我个人及其痛恨晦涩难懂的“专家代码”，更别说“伪专家”。一而再、再而三的拿出半吊子的代码，甚至编译不通过，却仍然在这里争强斗狠，而不是反省自己狂妄的态度。作为一个工程师，交付的每一行代码，都要为产品的稳定性负责，你的代码质量是本人能力的证明，必须对得起团队对你的信任，岂可一而再的撤回、重提，儿戏。做事的态度。云风的代码解决了线上问题，而对比你的代码呢？如果把你的第1个版本发布出去会怎样？第2个版本发布出去又能怎样？什么，出现死循环，停机维护？什么，又死锁了，停机，排查，项目组的逻辑程序员找不出问题？这是要损失几十万呢，还是损失几百万？谁来负这个责任？谁更不靠谱？结论写出《怎样识别水货程序员》的 ，本人，至少目前还不算靠谱程序员，无论经验还是态度，都还有待提高。再谈一下我对文中提到的各位大牛的看法： 云风：云风在自己博客中记录日常，记录想法，既然只是想法，难免有所疏漏，毕竟云风也不是万能。如果你认为他的观点不对，正好过去和他交流，可能这也正是他公开写文章的目的之一。另一方面，云风有把这些临时想法发到媒体上？发到大型技术站点上？有印成黑纸白字卖钱？有收你培训费来用错误的观点荼毒你？作为国内技术圈子的前辈，他有一天到晚冷嘲热讽你们年轻、你们不行？至于你这么追身喷人“水货”？换位思考一下，云风根本就是躺枪，自己平时处理些线上问题，把自己想法放自己博客上做下记录，然后惹来一身骚。陈硕：很厉害，并发方面确实是专家，对相关问题很敏锐，佩服。不过我个人不太喜欢他那本书，虽然一度期待很高（书中部分内容取自早期博文，一些观点我不太同意）...陈皓：“就是看起来系统还是在跑，但没有任何有用功。常年都是给入门马农做科普的内容”。怎么说呢，正是因为这点，我觉得才更可贵。我的博客很少更新，因为我写东西太慢了，而且我脑子不太好，写东西颠三倒四，需要反复修改，往往我半个小时的想法，2个小时的编码，如果再追加一篇文章来讲的话，得再追加4个小时，要是之后再在评论里跟人讨论上几个回合，再多2、3个小时不止，所以干脆不写，太浪费时间了。陈皓的时间比我贵太多了，收入是我10倍呢，我要是他我写个蛋的博客啊，下班就哄老婆孩子花钱任性去了。虽然酷壳多少会帮陈皓攒一些影响力，但相比维护的时间，这性价比绝对是不高的，尤其是，陈皓的博客，大部分时间是在向人传授知识，单方面让他人受益。所以，无论是在博客中深入探讨领域知识的和，还是向普通程序员科普常识的陈皓，我都很尊敬他们，只要他们还在写；有机会通过这些文章，和这些牛人交流思想，我觉得这是很幸运的一件事，感谢他们分享。虽然我今天比几年前厉害多了，从陈皓的文章中学到的东西要少一些，但是，我知道还有很多一般水平的程序员，能从陈皓浅显易懂的文字中受益，毫无疑问他在做的是对某些人有益的事。我不看轻酷壳，正如我不去看轻我的小学、初中老师。：品德学识都无可挑剔，工程师楷模。以他的能力和身价，花3、4年时间、用大量的个人时间去翻译一本书（），去把一件事做到极致...记得在微博上看到说几年间，经常翻译到深夜，还有沙鹰在推荐序中说“对游戏有着如同对家对国般强烈责任感”...真的很感动，他身上值得我学习的太多了，不止是技术。年轻一辈里面，文刀秋二、Yong He、RednaxelaFX、，都是业界良心了，他们的文章、回答，质量都是杠杠的。至于vczh，重点关注他的博客和github。有意思的是，他们都不会说那些秒天秒地的话。
计算机科学与技术，一部分人是当成科学来研究的，一部分是当成技术来用的；程序员基本属于后者；但这里面有一部分以为看了几遍前者的论文，就非常了不起了，高高的站在鄙视链顶端乱喷。=======本来就是不擅长写这么多字的程序员，下面的话又是开了嘲讽技以后写的，所以会稍微激烈点，望见谅。＝＝＝＝＝作者第二篇博客指导云风怎么定位问题，对象错了，应该来指导我。但是一个没写过几行程序，就把微博弄个认证为程序员的哥们来指导我，以我这种不追求上进的性格，肯定是呵呵呵^_^。仔细看了下，作者好像没什么被喷的价值。豆瓣上那十来篇博客（），没看到提出个什么了不起的想法，更没看到代码是怎么写的。当然了，作者认为：“代码只是记录思想的工具，而且绝大部分代码都是废话。看书比写代码重要的多的多。”不敢喷看书多的，万一在某本书的某个旮旯里面有个什么真理，读书少的我没看到，被抓住尾巴了，就不用混了^_^。＝＝＝＝＝说下自己的经历。入行初期，在华为待了四年多，基本不能上网查资料，更不用说上网灌水了。也不关注开源，更别提写博客了。但是在那个环境里，就有真正的工程师，他们在各种体系结构下一行一行汇编的分析性能，一个一个机器码的扣bug。把各种完全没有头绪，没有调试信息的现象弄得一清二楚。这样的人，我觉得牛逼极了，佩服得五体投地。受到感染，学了点皮毛，我居然以此本钱转行安全领域，写了一年内核程序。后来又混了一段时间，认识了云风。我发现云风的行为，跟我以前的认知不太一样。虽然写很牛B的代码，但是定位问题大部分居然靠看代码这么原始的行为。然后，好几次，我重现来重现去，gdb寄存器一个个查，找不到原因。。。居然被他看出来了＝。＝！我的感觉就是，偶像啊。。。。另外，我不认识自以为读书特别多，掌握计算机科学真理的牛B程序员。这类牛评价不了。=======================作者来贴代码了，那我就不客气打脸啦。首先，q.h那个简化代码，把别人需求弄漏了，懒得说了。然后，大牛作者自己贴了一个大约相当于小学生水平的实现，居然还做了profile；我先截个图，防止被删。下面看图：简单说，这段实现有4个错误，两个低级错误，一个作者自称为专家领域的并发错误，还有一个设计错误。简单说，这段实现有4个错误，两个低级错误，一个作者自称为专家领域的并发错误，还有一个设计错误。1. 低级错误1： push应该在while循环里面每次重置tail的值，否则这个程序基本可以算是死循环。当然实际不会，频繁插入的话，在循环sizeof(q-&msgs)次有几率会回来。测试的时候有没有看到自己CPU一直很高呢?2. 低级错误2：pop函数里面把错误1重复了一遍。3. 并发错误：假设把上面两个错误改了，代码可以基本正确的运行。那么在push ok之后，q-&msgs[tail & QMSK] =这行代码打个断点，然后把这个线程frozen住；pop继续，等到pop到那个tail值的时候，取出来的是什么？来解释一下，这个算什么水平的问题？4. 设计错误：如果数组满了再push消息怎么办，这个实现的意思是返回错误，那你让调用者把消息放哪里？丢掉？重试？如果一直处于满状态，又是无锁队列，重试不就相当于很多线程轮流死循环一会。你看看原实现怎么处理的。所以，好心建议先做个单元测试再做profile吧。===============原作者update1：作者居然又更新代码了，那就再截个图，嗯，两个低级bug改掉了，还剩下两个呢。加油改！======原作者update2：好吧，作者第二次更新实现了，号称：“这次不给个教科书级别的不行了” 。。。。这是要把知乎当成github用吗？我对代码的评价是，你看的教科书是幼儿园教科书吗？把逻辑复杂度提升了一个数量级，然后犯了更多的错误，你觉得q-&p.tail = next这句执行之后的结果是什么？忘记说了，你博客里面的那几篇spin lock的分析里面，伪代码错误一堆，看完之后只能哈哈一笑。再截最后一次图，马上睡觉了，你连夜优化吧。==============隔了一夜，来看原作者update3:代码在 ，还是一如既往的没实现对。另外，你的测试代码测试过程，我都没看。我相信能把错误代码测出卓越结果的测试过程，也能把正确实现测出错误结果。我对测试结果的回应：skynet框架已经在生产环境中支撑了同服10多W玩家同时在线游戏，如果核心调度层效率如测试结果般不堪，skynet早被我们自己唾弃无数遍了。======嗯，原作者已经抓狂了，目的已达到，呵呵！我对着代码一行行解读，都能把原作者惹抓狂。试想下，如果一个人连别人实现的东西都没看懂，照着别人短短数十行的代码反复重写了一夜，都写不对，还敢跳出来喷人水货。这需要多大勇气？原博中提到的“打破沙锅问到底”的态度，就是这么支撑着你一次一次来提交错误代码，浪费别人时间看的？你提交的代码仔细测试了吗？错第一次时都告诉你错在哪和重现步骤了，有去验证吗？这种态度，别说做学问了，就是写个简单的业务逻辑都能坑死队友。最后回应一下，后面的新代码更新，恕不跟近打脸了！太没技术含量，无法兴奋了-_-!=======既然一直在讨论这段代码，那我再补充一下。这段代码，在历史上出于不同考虑，有个好几个版本。两年前的版本是无锁的，代码如下：在外部保证队列不会满的情况下，两年前的实现是对的，我们也使用了两年(云风在skynet主干分支上改实现，我们项目已稳定运行，不想跟进，就fork出来自己维护分支，所以中间的其他几版实现被我无视了)。大家可以看看原始版本的实现，比作者贴的无锁实现不知道简洁到哪里去了。关键还是对的。但是一直有个特殊场景下的瑕疵困扰着我们（可以去看云风原博），那个现象一直得不到合理的解释。追求每个计算机现象都有合理解释的工程师应该能够明白，这事一直成了我们的心病。然后，偶然，我定位一个不相干bug的时候，找到了解释，于是就有了现在的有锁版实现。至于这个有锁版实现是怎么解释那个诡异现象的，云风原博没说，我这里也懒得说了（说道skynet实现细节就没意思了）。skynet资深玩家，看看调度上下文应该能够明白。最新代码地址：这份实现就是云风说的悲观锁实现：struct global_queue {
struct message_queue *head;
struct message_queue *tail;
#define LOCK(q) while (__sync_lock_test_and_set(&(q)-&lock,1)) {}
#define UNLOCK(q) __sync_lock_release(&(q)-&lock);
skynet_globalmq_push(struct message_queue * queue) {
struct global_queue *q= Q;
assert(queue-&next == NULL);
if(q-&tail) {
q-&tail-&next = queue;
q-&tail = queue;
q-&head = q-&tail = queue;
struct message_queue *
skynet_globalmq_pop() {
struct global_queue *q = Q;
struct message_queue *mq = q-&head;
q-&head = mq-&next;
if(q-&head == NULL) {
assert(mq == q-&tail);
q-&tail = NULL;
mq-&next = NULL;
return mq;
大牛作者可以重新分析了，加油！＝＝＝＝＝利益相关：我是云风说的那个spin lock PR的作者。=========尼玛，我就有理有据打个脸，有必要那么认真的点反对吗？我说错啥了，除了态度恶劣点外^_^。
既然有提到云风，那我也来妄议一下云风。简单来说就是，云风处理实际问题的能力强不强？强。但是小朋友你们能不能学？不能。云风的优点就是能就事论事，但是经常路子太野。他能蒙对的事情，你们不一定蒙对，还会留下坏习惯。关键是云风大爷还会用他的江湖地位，有意或者无意的来误导你们，你们还要信以为真，这才是最糟糕的。不信你们可以自己看看这里的许多答案。不要说白猫黑猫抓住老鼠就是好猫，人家云风是老虎，你能比？那么，谁的教导是系统正确的路子，小朋友们可以尽情模仿的呢？我就提几个人，你们赶快关注： 关于编译器的一切话题 关于图形学的一切话题。或者说他给出的但凡含有参考文献的回答基本都是靠谱的。 关于C++和Compiler的一切话题
关于CPU和Cache微结构的一切话题。不过补充一下，我是做GPU的，所以他的一些观点我很难通过自己的Background去验证，因为应用场景不一样，偶尔我直觉上觉得他的某些观念有些偏，但是总体来说还是很靠谱的。 网络方面硕爷的实战看起来很屌的样子，我周围做过网络的朋友也都觉得他的博客不错。我拜读了硕爷的书，当然必须是跪着读的，他对工程的理解和C++的理解很得我的共鸣，当然有可能是我们俩都错一条道上了有一个人你们不能随便模仿，因为他的话真假掺半，好坏掺半，除了极少数编译器相关的话题，还可以信任一下，那就是微软的前精神股东，现肉体股东：至于温兆伦中的 ，他的博客很屌，但是知乎上似乎精力都放在妹子身上了。。。===============================还有一些大牛求点评的我诚惶诚恐。 巨巨我接触不多，真正看他发言都是今年在知乎上了，似乎是关注管理的问题更多一些。对于这种大牛我只有跪的份。（当然对于我文中引用到的其他大牛我也只有跪的份）===============================同意不点赞的都是耍流氓啊！特别是我at的几个你们人情票总要给的吧！===============================还有人要我点评自己，我编译器后端不如 RFX，前端不如VCZH，C++标准不如蓝色，图形学不如Milo，体系结构不如 Tero，工程能力不如硕爷，我有啥好说的。。。
跳进来看了一下，意识到自己现在其实连水货的门还没碰到，更高的境界就更是高山仰止了，好吧，洗洗睡了。安，各位牛们。--------------------------------------------------------------------------------------------------------------------------------今天有空唠叨两句。我以前说过一句话优秀的人才，学习别人的长处，清晰认识自己的短处（改不改再说）。平庸的人，天天指摘别人的缺点，炫耀自己的长处。每个人都有自己擅长的领域，也有不是那么擅长或计较的领域，但是如果你抱着挑错的态度去说，你会发现好像谁都不如自己，除非你换个视角去看。我以前面试php程序员，很多人都说，看过dz的代码，一说问题 ，说出七七八八一堆，好像都比dz的开发者牛，可是我回头问几个典型dz做的比较不错的点，基本没人回答处理，比如ip地址反查dz怎么做的。 实话说，我面试过的php程序员，没有一个能有戴志康那样理解数据结构和查询效率的，但是每个人都告诉我，dz代码有多烂。我的水平远不如上面列的那些水货们，我也不想给自己正名，反正现在也不混技术饭吃，但是我想说一句，天天只会挑着别人毛病来证明自己牛逼的，没有一个是出色的人，记住我说的，没有一个。
很多答案已经阐述了这哥们的问题，他在理论层次喷应用层次。如果站得足够高，他所谓佩服的那几个程序员也一样有很多喷点。最关键的是，任何项目都是在规定时间内利用有限资源最大可能的解决问题。例如那个瓶颈定位，他说的是一个很基本的方法，理论上很对，但是在项目里，不一定对。资源不足，时间不足，做事情的方式也会不一样。实验室的态度是尽可能的精确，目的是验证猜想；工程的态度是能够解决问题，目的是投入产出比。所以这哥们压根就站错地方了，喷得自然没有说服力。
确实很多巨牛的程序员在网上并不活跃，而社区中那些知名程序员也未必都是最牛的，甚至误导人的情况也是有的。但正如前面的人所说，程序员社区里是需要布道者（或者热心参与者）的，哪怕有人只是因为翻译一下国外的技术文章火了，或者是写点新手入门火了，作为旁观者，也没必要跳起来说谁谁谁其实是水货。就事论事的讨论问题，积极分享的人，会比态度高冷，恃才傲物的人得到更多的尊重和知名度，这在哪个圈子都一样
按照知乎儿的玩法不是废话少说，让我们来决战Github之巅吗？
大家都是批评的，我来说说代码里的精妙之处吧。我想作者其实是想给大家秀一下这些提高性能的技巧，程序是不是能立马上线倒不是他想表达的关键问题。作者有几个反问，我想这也是他得意的地方，我来说说这些地方有哪些好处：1.为什么定义两个一样的internal struct？为什么mask是一样的值，却要定义在两个地方？大家看struct queue的定义是缓存行对齐的，并且mask放在两个字结构体。这是为了让push和pop在访问数据结构的时候，使用不同的缓存行。大家都知道缓存一致性是基于缓存行的，如果两个核使用一个缓存行的数据，那么每次更新数据之后，缓存会自动去做同步，这需要十几个周期的时间。而把数据分开到两行后就没有这个问题。2.为什么一定要用static inline？代码本身不长，减少跳转，提高命中率。3.是不是还要问为什么要asm volatile和padding？padding就是把数据结构设成缓存行对齐，这个解释过了。asm volatile是内存壁垒，意思是之前的访存，必须全都执行完了，才可以往下走。用于把不能乱序的访问隔开，比如代码中的q-&msgs[head & mask] =和while (unlikely((q-&p.tail != head)))。4.在他的测试代码里面，有一个结构socket_top，定义了一堆和核有关的数字。作者说如果测试跑在非32线程处理器上，那么需要修改这个结构。其用意应该是这样的，他把pop和和push分别绑定在一个物理核的两个物理线程上，这样可以共享L1cache。实在不行，那也得绑定在一个组的物理核上，可以共享L2cache。最差的是随便绑，那就得穿过前端总线，到L3cache。这样效率最低。说的不对大家请指正。
一部分人态度非常差，各种鄙视链横行。看了几篇paper就以为自己懂得什么终极奥义似的。国外大牛虽然术业有专攻，但是他谦虚啊。苏格拉底是最有智慧的人，不是因为他懂什么，而是因为他知道自己不懂什么。大牛的方法要学，大牛的态度还是省省吧。我从来不搞鄙视链，你的领域low但是拿的钱比我多我会佩服你。
刚刚拭去眼角嫉妒泪水的我们，其实只想安静地混在楼主们中间，不敢打扰你们，你丫的为毛要识别我们？识别你妹啊...给点生存空间行不行？我被你挤得只有QQ空间了。
动了真格的水平，我觉得随便去多读几篇ppopp的论文，然后再把《计算机体系结构量化研究方法》翻上几遍就可以了。不要认为会这些东西有多牛逼，一个本科生训练半年年也能写出这样的程序。 我在工作中也遇到过一些人，对于各种细节非常熟悉，比如一行c代码差不多要花费多少个cycle，gcc的各种优化选项，cache状态转移，各种各样最快的fifo，sse指令优化等等。因为他们做相关的工作做了几年，做过编译器优化，做过多核的分析优化，所以对这个熟悉，也可以说是这个细细分领域的专家。但是，让他们去设计一个真正的商业产品，他们的水平确实太菜了。考虑任何事情都是把性能排在第一位，完全实验室发文章的思路，模块化，易维护方面从来不考虑。其实说了这么多，我想表达的是他们并不是这些优化思路的发明者，他们都是从《量化研究方法》这本书上学来的，都是从国际顶级会议别人的文章中学来的，所以不要去拿着学来的小众东西喷别人，你这么牛逼去拿个图灵奖看看？完全田忌赛马的路子。------------------------------------------------------------------------------------------------------------而且我觉得，少几个这些所谓i的专家计算机科学和技术照常发展，但是如果少了一些 的不辞辛苦不问回报指引新手入门的人，那么可能会让更多的人远离这个行业。“专家”都喜欢拿数据说话，从来不信别人“蒙”的结果，把别人“蒙”的结果都归结为运气，不可信。我不觉得python的创始人会去喷《父与子的编程之路：与小卡特一起学编程》的作者，相反，我觉得《父与子的编程之路》的作者对于大部分第一次接触编程的人来说更加重要，如果不信，可以去翻翻，看看别人是怎么教小孩子入门的，是怎么让更多的新人有兴趣在编程这个上面持续探索下去的。
以我的姿势水平，远远没达到评论该事件当事人的程度，不过....
作者的分析方法很正确，我面试别人时就经常使用这种方法，虽然识别成水货后不能百分百确定这是一个水货程序员，但可以保证能通过这样的程序员基本靠谱，即使他们能力不足，也很容易培养起来。用个简单的例子，问一下线程同步有什么用，资深水货程序员通常可以回答出很标准的答案，标准到比资深程序员好得多的程度，这时你只要重复问一遍，为什么要使用同步，然后听到的答案就是同步通过synchronized 进行同步，然后什么会死锁之类的回答就出来了，从面试经验来看，水货程序员几乎百分百是这样回答的，不相信你可以这样考查你没写过线程同步的同事，如果你被打死的话千万别找我。另一方面，很多高深的大牛同样有很多知识上的盲区，比如很多写OS或低层代码的大牛连String类最常用的使用方法都不会，很多做DSP的搞过十多年C语言，printf这个函数都不一定能拼全，这都是很正常的事，因为他们的工作中很多时候在发明轮子，并不需要使用这些系统上现在的东西。所以如果用该作者的方法去恶意判断某人是水货的话，很多真实的大牛同样可以归于水货列传当中，就像不管你有多牛，被方舟子钉上一样会死得很惨一样，虽然方舟子很多时候是对的。当然，该作者目前还没有表现出方舟子的迹象出来。虽然真的大牛，出书的很少，但还是有部分大牛会出书，作为大牛的出版物，有很多初级错误，这个也是很正常的，一方面是他们没时间，更重要的是他们很多东西也真的不懂，但出个编程书要求把东西写全，不能只写自己擅长的那部分，他们可能也是去其它书上抄的。
独立思考, 定量分析, 靠数据说话. 好像都没有错. 那看书的, 从网上找来的, 科普的知识就一定是水货么? 谬甚~ 牛顿也不是从结绳记事开始研究出微积分的. 学习和思考是天平上的两端, 不管偏向哪一端, 都是有问题的. 另, 这小孩有点中二, 慢慢就会好的.
凡是因为一个人的某些缺点，而把这人一棒子打死的人，肯定有问题。
呵呵，首先为防止偏题太远，先表一下态。细节不敢苟同，但我认为原文章大致正确。网上水货太多，随便从本科课本上抄点代码也能成大牛，随便扯点概念，就能糊弄住一群人。好了，问题的回答就到这。我发这个答案，主要是感觉当事人 太稚嫩了，这个不是对技术上的评论，而是指处理问题的方式。第一个要说的事情是她（女性？）在知乎上的表现。你首先要搞清楚，你是要解决什么样的问题。我们看到，云风说了一句话：“并发队列这种数据结构，无论是采用 spin-lock 还是 cas 无锁结构，为了保证时序，进队列或出队列的部分都必须是依次进行的，也就是说，多核心无助于提高队列的性能。”我们也注意到，当事人也是就这段话进行反驳的，那么你要做的事情非常简单，你根本不用管云风的什么需求，什么代码环境，你只要给出最简单的lock-free队列和spin-lock队列，然后做一下benchmark就可以了。只要benchmark能证明云风这句话是错误的，你的论据将是坚不可摧的，那么别人怎么驳斥你，都会显得苍白无力。当事人几乎是这样做的，但是有一些问题。首先，她做的事情太多了。依上段所言“你只要给出最简单的lock-free队列和spin-lock队列”，我们看到，她试图找出云风的更多错误，但效果适得其反。你要知道，你在这个环境里是稍微弱势的，你本来就属于获支持较少的一方，而且大部分人只是看热闹，并不见得就真懂什么并发队列，什么cas。因此，只要有稍微获得大众信任的人指出你代码里的一点点瑕疵，那么你就翻不了身了。而她其实犯了不少错误。究其原因，是她修改了云风的源代码，而不是直接给出自己所需的代码，这让自己的论据变得更为复杂，浪费了自己的精力，增加了出错了可能，此外还让对方有了更多的解释权（需求）。其次，是被对方找出的bug分散了精力，你代码是出了问题，但你要强调的是，出的问题会不会影响你的结论，能多大程度影响你的结论。但你在出了问题后，一味的和对方打嘴仗，代码改了又改，说的难听点，像个小丑一样。别人说你没懂需求，说你的代码不能放在生产线上，说你的代码不符合规范，这些和你要驳斥的内容有关系吗？即使你已经犯了上面一个错误，在这一步，你只要咬住你要处理的最根本的问题，就能把这些质疑都挡下来。第二个是关于她在豆瓣上的行为。 我觉得，不管你再有道理，随随便便的点草具体的人总是不太好。这些人里面，可能确实有一些比较水的人，什么翻译一下wikipedia，贴到blog上之类的。但这些行为总归对社会没什么害处，相反，很可能可以帮助很多小白。你看不惯，说说这现象也就行了，没必要直接说谁谁谁不好。你想像一下，你什么都没做，一天早晨起来，上网发现有人指名道姓的说你是大水货，你心里是什么滋味。即使单单描述别人的行为就能刺痛很多人，何况指名道姓的说别人？再者，你说的那些人，不少在网上有很多fans，这些人也不一定就能看懂你们讨论争执的问题，即使你论据充分，别人看你不爽，一句“呵呵”，你就输了，更何况你还出了那么多小毛病。那些墙头草看看形势，自然也就反对你了。这事从一开始，你就吃亏，归根结底，不要随便直接针对某个人。以上。
大大at过来了，就来凑个热闹。 我没有资格在一众好手面前摆弄一个程序应该怎么写，只说跟我的专业（处理器核心微结构，Cache微结构）相关的部分。在
自己举的这个例子里面，data cache的padding做的不错，值得鼓励。Branch hints就有点儿玩脱了。编译器（以及某些特别的ISA上）开放branch hints不是为了循环的，而是为了非循环的分支。循环判断的分支语句早在上世纪80年代就可以达到99%以上的准确率，真不稀罕这点儿提示，专门挑循环分支加上这些branch hints的目的看上去不像是优化性能，倒像是作死，你看你改完程序以后branch miss率反倒退步了好几个百分点。 如果是为了帮助缩短execution path而加上了这些hints，也没什么必要，只要个把次预测失准以后，整条trace就会被inline到front-end的uop-cache里面去，整个分支路径上没有被执行的代码会在inline过程里面自动跳过，塌缩成最短路径，在这些个地方插入branch hints有些舍本逐末的味道。（如果你想知道这是怎么做到的可以去读一下Intel的micro-ops cache论文，或者以前的trace cache论文，二者同宗同源）
显著特征:“问题分析流于猜测，不能达到问题本质。 轻易下结论，下过多总结陈词。 缺乏量化分析，以主观感受和特例作为依据。”这说的是这篇文章的作者么？
唉，温兆伦得罪人了。。。还是安心当码农舒服