与其想当然的 overdesign，不如自己动手做个试验

Conmajia

Jan. 29th, 2019

早在2012年，我曾经针对 C# System.Random 不同的初始化方案专门做过一次试验，得出了单次默认初始化即可获得质量很好的随机数的结论。可是这么多年过去，C# 从2.0升到了4.7，还能在网上看到很多新手（甚至是老鸟）被一些想当然的奇怪思想误导，费时费力地脱裤子放屁。

有些人总觉得用点额外的、生僻的玩意儿会显得很炫技，很厉害。正如修真小说里，稀有的古代神器多半比量产的现代装备牛逼，在编程的时候，用上那么几个不常用，或者当前问题环境下一般没人用的patterns or callbacks什么的，仿佛就拥有了高贵的血统，让人不明觉厉。然而再华丽的古罗马战车，也比不上穿梭在街头巷尾的五菱宏光；再炫酷的开发技巧，也敌不过没头没脑的overdesign。

以前有种说法，觉得用随机性相当大的GUID做种子来初始化Random就能得到比new Random()更随机的输出结果。这种不知从何而来的莫名自信一直延续到了今天。

且不说这堆一脉相承的智障操作对性能的影响，很显然，他们对真随机数、伪随机数这些概念有点误会，对计算机生成随机数的原理也不甚了然^[1]。他们只是看到那一长串变幻无穷的GUID后，心中的虔诚感油然而生。然而回过神，迎面扑来的却是现实的一盆刺骨冷水：对于 Random，任何多余的初始化都不过是拖后腿的累赘而已。

一顿操作猛如虎，一看战绩0-5

.canvas{width:100%;height:200px;margin:0px auto;padding:0;}

已经足够好的 `Random`

一个随机数发生器好坏的评判标准，首先看它在值域的分布概率是不是符合均匀分布（uniform distribution），也就是说它取得任何一个值的概率都是相同的。其次看它的性能。不管你的Random用到了多么炫酷亮瞎狗眼的神技，只要它的性能不够，狂吃资源，那它一定是个辣鸡。如果产生一个随机数需要5分钟，那么任何音乐软件的“随机播放”都将变得索然无味。而对于那些热衷于使用花里胡哨的玩意儿来做随机数种子的方案，性能永远不可能超过默认构造函数。毕竟你每次生成随机数的时候都必须把这帮家伙初始化一遍，否则就和默认初始化完全一样，这些花里胡哨将变得毫无意义。数学理论不说了，先让秀儿们看看默认的Random到底够不够随机。

Case #1 的数据，是用默认构造函数初始化生成的数据统计概率直方图。$x$ 轴是输出的随机数数值，范围从0-99，共100个数。$y$ 轴是对应数值出现的概率。每次试验生成 10,000,000（一千万）个随机数，每个case进行10次试验，共生成100,000,000（一亿）个随机数，得到单次试验平均用时0.76秒。令 $\tau=0.76$，后面的case都按类似的方法进行，并以 $\tau$ 作为性能基准，排除计算平台的干扰。

Case #1 new Random()，用时：$\tau=0.76$

平均值0.010,000,000,000,000,002（移动滑块缩放显示窗口）



// 函数定义

static Random r = new Random();

int GetRandomNumber() {

    return r.Next(0, 100);

}

// 主程序（单次试验，1000 万随机数）


...


for (int i = 0; i < 10000000; i++) {


output[i] = GetRandomNumber();


}


...

看，典型的均匀分布。在一千万大数据量的支撑下，100个可能值每个的输出概率都达到了完美的1%，带内波动小于 ±0.000,05，还有什么可挑剔的呢？

那么，现在开始试验备受推崇的GUID初始化随机数发生器了。当然，这句话也可以拗口地说成随机生成随机数发生器（generate random generator randomly），反正都是秀嘛。

找个比较简单的GUID例子：

依然生成 10,000,000个随机数，主程序内容不变，只需要修改 GetRandomNumber()：

Case #2 new Random(GUID)，用时：$52\tau$

平均值0.009,999,999,999,999,998



int GetRandomNumber() {

    Random r = new Random(

        BitConverter.ToInt32(Guid.NewGuid().ToByteArray(), 0)

    );

    return r.Next(0, 100);

}

没错，这确实能得到输出效果不错的随机数。但是，它的带内波动达到了 ±0.000,2，差不多是 Case #1 的4倍，完全谈不上更好。那么性能呢？在效果近似，波动更大的情况下，Case #2 用时达到了 #1 的52倍（39.5秒），这么辣鸡的性能还好意思吹您的呢？

再来看看更秀的，本文最开始那张图里的例子，用的是GUID×Time×计数器这种秀破天际的初始化方案：

Case #3 new Random(GUID * Time * count)，用时：$56\tau$

平均值0.009,999,999,999,999,998



static randomCount = 0;

static int GetRandomNumber() {

    randomCount++;

    Guid guid = Guid.NewGuid();

    int key1 = guid.GetHashCode();

    int key2 = unchecked((int)DateTime.Now.Ticks);

    int seed = unchecked(key1 * key2 * randomCount);

    Random r = new Random(seed);

    return r.Next(0, 100);

}

您可省省吧！

这段代码的作者甚至还想到了用unchecked略微优化一下代码的健壮性。上手就来秀优化，全然不顾丫的压根儿从算法上就有毛病。习惯成自然，可以猜测他平时在业务工作中没少这么干。然后是hashcode、time tick各种key一顿花里胡哨得到一个seed来初始化Random。可是这又有什么卵用呢？朋友？为了这个和 Case #1 几乎一样效果的输出结果花掉了 56倍（43秒）的计算时间，您觉得合适吗？？

代码的质量不是看它用了多少技巧，秀了多少知识，只要花点功夫，这并不难做到。恰恰相反，用最简单的办法实现适当功能和良好的性能，才是最困难的。一段代码是不是实用，你也不可能靠它的字数来判断，任何结论，要么理论推导，要么试验验证。那些被人奉为经典的半吊子大神的话，可能往往只是他们放的狗屁而已。

The End. $\Box$

所有的真随机数发生器都需要专用硬件支持，它们中绝大部分受到发明专利保护。System.Random 基于 Donald E. Knuth 的减随机数生成器算法实现，从实用角度而言，随机程度已经足够。 ↩︎