高人竟在我身边(校对)第142部分在线阅读

　　“首先得冷静……”
　　“然后，得搞清楚这款引擎运行的逻辑。”
　　让图形数据输出的速度更快，质量更高是一款好引擎的重要评判标准。想必在让这款引擎上线之前，冰川引擎的开发人员就已经绞尽脑汁地优化过它的代码了。
　　想在前人的努力上更进一步不是完全没有可能，但指望凭一个人的力量在短短三天时间内做到，恐怕自己的系统外挂还得加强。
　　如此说来……
　　想对引擎本身的代码进行优化是几乎不可能实现的。
　　自己唯一的希望，恐怕只有在引擎本身代码之外的地方。
　　比如，那些被频繁调用的底层函数？
　　不管是3D引擎还是2D的引擎，不管是国内流行的“冰川”还是国外比较流行的“荒原”，一切游戏引擎归根结底都需要对底层函数频繁的调用，越底层的函数被调用的也就越频繁。
　　尤其是3D图形渲染这一块！
　　有时候玩家碰到大场景出现卡顿，甚至角色悬空、穿墙，其实很大程度的原因就是图形算法的速度跟不上。
　　如果能优化底层函数……
　　搞不好自己还真有希望搞定这道题？
　　一瞬间，郝云被自己疯狂的念头给吓了一跳。
　　卧槽？
　　他仔细在心中合计了一下，这特么好像比优化冰川引擎还难啊！
　　毕竟冰川引擎好歹还算是新历元年之后的产物，但冰川引擎调用的那些底层函数，可是在人联时代之前就已经被开发出来了。
　　但……
　　万一能行呢？
　　咽了口唾沫，郝云抱着试一试的想法，找到了冰川引擎目录下code文件夹中的math.c文件，翻开了里面存储着的大量被调用函数。
　　将这些代码从头到尾全看一遍显然是不现实的，不过郝云也没打算干这么蠢的事儿。
　　他只需要找到这款引擎在运行时被调用次数最多，每一次加载游戏场景时几乎都会被调用、并且足以影响到引擎运行效率的函数，然后再去里面寻找改进的机会便可。
　　很快，郝云锁定了一条被命名为Q_Sqrt的函数。
　　这个函数表面上看着平平无奇，只不过是一个运用了牛顿迭代法的求平方根倒数的算法。
　　然而有意思的是，在这款引擎的运行过程中，需要求平方根倒数的情形多到了令人发指的程度。
　　因此换个角度来想，该函数的运算速度，已经足以影响到引擎本身的效率。
　　这就好像航天火箭上的一颗螺丝钉，表面上看火箭的速度并不取决于这颗螺丝钉本身，而是取决于火箭引擎的设计和关键的燃料等等，但当火箭引擎的设计和燃料技术都发展到了瓶颈，想要进一步提升火箭的效率，就只有从根本的材料上着手研究了。
　　郝云此时此刻正在做的，便是类似的事情。
　　然而……
　　虽然思路已经找到，但想要走通这条路却并不容易。
　　到这为止都没有任何值得深挖的地方，毕竟牛顿迭代法，本身已经是一种非常优秀的求平方根倒数的数学方法了。
　　再想创新？
　　数学方法上改进几乎不可能！
　　如果想比这更快，恐怕就只有对输入值和输出值建立一个庞大的数据库才能实现了。
　　然而为区区一个函数建库，似乎又显得本末倒置……
　　时间一分一秒过去，郝云的电脑上，还是一行代码都没有敲下。
　　在后台看着的詹永枢院士轻轻叹了口气，眼中浮起了一丝失望的表情。
　　很明显，这位101号选手，已经陷入了钻牛角尖的境地。如果不能立刻改变策略，换一道题目的话，他的进度将会被其他选手远远甩开！
　　至少他们见到的，已经有三名种子选手，分别将其他三道题的进度推进到四分之一了。
　　“虽然勇气可嘉，但这样下去是不会有结果的，”张存浩教授笑了笑说，“我刚刚看了一圈，好像就他还在研究第四道题。”
　　“这种题目出现在比赛中就很有问题，”詹永枢院士摇了摇头，“下次比赛可不能这么胡来了。”
　　张存浩教授尴尬笑了笑，轻咳了声：“下次一定。”
　　然而就在两人都认为，101号选手已经没有任何希望了的时候，坐在电脑桌前的郝云忽然动了。
　　只不过，他的操作好像有些诡异？
　　只见他没有着急去写什么代码，而是将math.c文件中关于Q_Sqrt函数的那一段代码直接删掉了。
　　“他想干什么？”
　　看着郝云屏幕上的操作，张存浩被这位选手谜一样的动作给惊讶到了。
　　他大概能猜到这位选手打算干什么，无非是想重新定义“反平方倒数”的算法，然而这个世界上有可能存在比牛顿迭代还要简便的算法吗？
　　话说这已经不是程序的范畴，而是数学的领域了吧？
　　詹永枢院长也被惊讶到了，一时间没有看明白郝云打算干什么。直到他看见一行【i=0x5f375a86-（i》1）】出现在屏幕上时，才微微收缩了瞳孔。
　　“我可能知道他想干什么了。”
　　“……？”
　　张存浩有一脸的懵逼，看向了自己的老师，试图寻求答案。
　　然而，詹永枢院士却丝毫没有解答他困惑的打算，只顾自己在那儿摸着下巴的胡渣，看着屏幕上的那段代码赞许点头。
　　“妙啊……”
　　“实在是妙！”
第一百章
101号选手提前交卷？
　　相比起詹永枢院士的惊讶，郝云在考虑这个问题的时候倒是没有想的特别复杂，纯粹是挠头的时候灵机一动想出来的这个方法。
　　程序首先猜测了一个接近1/sqrt（number）的值，然后运用牛顿迭代公式进行了迭代运算。
　　单从算法逻辑上来讲，其实他改写之后的代码，和之前那个Q_Sqrt函数的代码并没有太大的区别。冰川引擎在math.c文件中定义的Q_Sqrt函数，事实上也是采用的这个思路。
　　而要说唯一哪里不同，大概就是在那个神秘的数字——0x5f375a86上了。
　　根据牛顿迭代算法的原理，猜测值距离最终结果越接近，迭代的次数越少。而神秘的数字0x5f375a86，便是用来计算猜测值的。
　　而郝云在尝试了几次之后意外地发现，如果使用“0x5f375a86”这个数，得到的y将非常接近1/sqrt（n），以至于最终执行牛顿迭代算法时，只需要2次代法就可以达到他所需要的精度!
　　至于这个数是怎么得出来的？
　　郝云也没办法解释。
　　毕竟他只是遵循着自己的数学直觉，觉得原来那个程序中选取的数字不够好用，然后试着换了个更好用的数字试试。
　　一开始他也试了好几次，发现更改的数字都没有原先那个数好用，直到后来灵机一动试到了这个0x5f375a86，发现居然只需要两次迭代就能完成整个计算过程。
　　老实说，他自己也惊讶的不行。
　　可能……
　　这也和他的数学属性达到了精通有点关系？
　　总而言之，采用了0x5f375a86这个特殊的数字之后，单从运算步数来看，整个函数的运算效率将比原本math.c文件中定义的Q_Sqrt函数快上足足两倍！
　　至于这个结果会产生怎样的效果……
　　老实说郝云也没有一个准确的概念。
　　毕竟他对这款冰川引擎的了解，远远没有达到业内人士的高度。
　　之前他虽然做过游戏，但其实也就只做过2048这一款游戏而已。神殿逃亡算是运用到了和冰川引擎同源的一款开发软件，但那款游戏基本上都是李宗正一个人完成的，郝云压根儿就没参与到开发环节中，就算参与进去了八成也不会研究引擎的源代码。
　　这个世界的游戏开发工具已经进化到足够傻瓜的程度，除开那些大制作之外，绝大多数的中小型游戏都是能够单纯的依靠开发工具，以及二级程度的编程水平来实现的。
　　“……话说到底咋测试引擎效率提升了多少？这电脑上就没有一个打分软件，或者测试用的游戏吗？”