[推荐] 基于.net的Grid实现：Alchemi
Alchemi试用手记
Alchemi的实现机制初探
昨天对其效率做了一个简单的测试，测试结果如下：
对不同大小的空间数据集进行坡度求解的运算的计算结果见下表。其数据集大小分别为400×400，2000×2000和10000×10000的数据集；网格节点，即Alchemi的Executor节点分别为1到5。测试结果表明，对于小数据集，在网格计算环境下，效率呈现下降趋势，例如对于400×400，2000×2000的数据集，效率分别是单机环境的0.09倍和0.29倍，但对于10000×10000的大数据集，2个节点的网格计算环境效率即超过单机环境，而对于5个节点，效率提升为1.92倍。
对于分布式调用，其运行效率受以下因素影响：
（1）远程调用本身的开销，一般来说，远程调用要比本地调用慢1个数量级以上；
（2）网络传输速度的限制，所有运行的代码和调用指令等都需要远程传送，因此效率也必然要比本地调用慢得多。
这2个原因也是为什么对于较小的数据集，网格环境下效率反而不如本地代码（上表，图 a，b），但对于大数据集的较大的计算量，这些开销的负面影响被分布式计算所抵消，带来了更好的执行效率（上表，图 c）。而且，随着数据集大小的增加，计算量随之增加，增加网格节点会持续带来效率的提升，例如图a和图b随之网格节点增加，节点数超过2个以后，效率提升并不明显，但图c随着节点数增加，效率会持续提升。
由测试结果我们可以看到，通过计算网格技术的分布式计算，可以提高需要高密度计算的空间分析的运算效率，但对于运算时间小于远程调用及网络传输开销的运算，使用网格会得不偿失，所谓“分布式对象第一定律：不要使用分布式对象”，诚不我欺。
因此，网格可能只是适用于类似科学计算之类大计算量问题求解，对于一般的计算，例如企业系统，并不适合。