Performance 基数排序的最佳基

关于这个话题，我读了好几篇文章。然而，我很难弄清楚这些公式的确切含义。当b=n时，基数排序似乎是线性的。这是否意味着我应该将基设置为数组的长度

如果我有一个1亿个整数的数组，范围从0到10亿，我应该选择基数1亿

如果这是不正确的，请试着为我沉默一下。我能找到的大多数基数排序的示例都只有基数10或基数2，所以对于大于10或2的数组，它们要么速度慢，要么就是我不懂

---

感谢您的帮助。

对于您的情况，最好的基数排序基数是2^16（65536）或2^8（256）。

---

在第一种情况下，您将为每个元素对数组进行两次移动排序，在第二种情况下为4次移动排序。

当您将基数设置为数组中的条目数时，基数排序实际上不是线性时间。基数排序的运行时间是O（n logb U），其中n是数组中元素的总数，b是选择的基数，U是数组中的最大数目。如果设置b=n，则运行时为O（n logn U）=O（n logu/logn）。逐渐地，这真的很棒

然而，在实践中，在评估基数排序时，其他因素往往更为重要。一个方面是将数字拆分为单个数字的成本。使用2的幂的基，这只是一个简单的位移位。对于其他基地，您可能需要使用（相对）更昂贵的分区，这可能会造成一些伤害。不过，更重要的是，还有引用的位置。如果使用base b，那么将有b个不同的数组，元素将被丢弃到其中。如果您选择b太高，那么在将元素附加到bucket数组的末端时，可能会获得较差的缓存性能，这实际上可能会导致性能下降

也许最好的办法是根据不同的基本选择对程序进行实际分析，看看什么是最好的。根据经验，当我尝试使用base-n基数排序时，我发现在大输入上，它比标准的base-2基数排序慢，主要是由于局部性问题。我猜2不是基数排序的理想基数，但是像216这样的大型对象可能会开始出现缓存未命中。尝试尝试一下，让我们知道你发现了什么

---

希望这有帮助

你能解释一下为什么这个值是最好的吗？因为它是sizeof（int）的1/2或1/4。使用256，您将使用更少的额外内存，但总共移动4次。使用256*256，您只需2次移动即可获得结果（对于eqch int），但计数器需要大量额外内存：sizeof（int）*2*256*256 bytes=512Mb。您好，您说过“使用base-n基数排序，我发现在大输入上比标准的base-2基数排序慢”。然后你会说，“我猜2不是基数排序的理想基数。”。当base-2比base-n快时，你为什么要说后一种说法？@chandresh这句话的主要意思是“我没有任何先验的理由相信两个是所有可能的碱基中最好的。”很可能它是最好的，但如果没有做更多的测试，我就不能肯定了。好的。我希望在这里收到您对我的问题的评论：