Algorithm 计算密集型算法

我计划写一系列关于计算密集型算法的程序。这些程序将作为不同编译器/硬件性能的指示器

我想学习一些在不同领域使用的常用算法，如生物信息学、游戏、图像处理等。我想这样做的原因是学习算法，并拥有一套小型、实用、易于维护的个人迷你基准套装

---

任何关于算法选择的建议都会非常有用

典型的是快速傅里叶变换，也许你也可以做一些类似卢卡斯-莱默素性测试的事情。

基准测试不值得你注意！ 最好的处理器性能指南是：

然后有人会把它扔进一个装有3GB内存的盒子里，打破了双通道的希望，而你漂亮的基准测试将再次给出完全不同的结果

如果您有一段性能关键的代码，并且您确信已经选择了获胜的算法，那么您就不能使用通用基准来确定最佳编译器。您必须用每个编译器编译特定的代码段，并用它对它们进行基准测试。你获得的结果虽然对你有用，但不会外推给其他人

举个例子：制作压缩软件的人——比如zip和7zip，以及PPMs和上下文混合等高端产品——对性能和程序基准测试都非常谨慎。他们常出去玩

情况是这样的：对于开发相同基本算法的工程师来说——比如LZ或熵编码，比如算术编码和哈夫曼编码——工程师们都发现非常不同的编译器更好

也就是说，两名工程师使用相同的高级算法解决相同的问题，他们将各自对其实现进行基准测试，并获得推荐不同编译器的结果

（我看到同样的事情在竞赛节目中反复出现，例如，这是一个同样关注表演的社区。）

（较新的GCC4.x系列在各方面都非常好，但这只是我的数据点，其他人仍然支持ICC）

---

（IO相关任务的平台基准测试完全是另一回事；人们不理解Linux、Windows和FreeBSD（以及其他）有多么不同。）在压力下执行。在相同的工作负载、相同的机器、不同的机器或不同的核心计数上执行基准测试将提供非常广泛的信息。遗憾的是，没有足够的这样的基准测试。）

我记得有个人测试过机器的计算性能，编译器版本通过反转希尔伯特矩阵实现

---

对于图像处理，中值滤波（用于去除噪声、坏像素）总是太慢。考虑到足够大的图像，比如1000x1000，这可能是一个很好的测试。

几年前，伯克利做了一些这方面的工作。确定了并行编程的13种常见应用模式，即“13矮人”。其中包括线性代数、n体模型、FFT等

见第10页及以后

这里有一些.NET实现示例：

---

您可以使用标准测试来衡量自己的表现。也许值得研究一下它们，以避免重新发明轮子。我相信肯定有很多，但我想利用这个机会学习繁重的算法。我厌倦了介绍矩阵乘法结果或其他一些我部分理解的基准：）是的，我想到了FFT。我会调查卢卡斯·莱默的，谢谢。