TWTCAD并行计算程序说明

TWTCAD并行计算程序说明

 

程序中的并行计算部分主要采用.NET中的Remoting技术，整体的计算代码被拆分为可并行计算的部分代码，这些部分代码被封装在不同的对象中，而这些对象可以通过Remoting技术远程的分布在网络中，即这些对象可以被创建在网络中的其它计算机中，在本地计算机中生成一个代理。有几台客户端，在服务器端就会生成几个远程对象代理，而每个代理都有单独的线程来维护，代理在服务器端是并发执行的，而实际的远程对象则在网络中并行执行（注意并发与并行的区别）。

程序的静态结构和动态结构在VISIO中都已经用UML语言描述过，这里将会对程序中的一些特殊部分和技巧进行解说。

一、远程对象的管理问题

每一个远程对象都在服务器端对应一个代理，对于远程对象的管理就是对于代理的管理，在服务器端针对没一个代理创建了一个线程单独进行管理，没个线程内部对于远程对象代理上方法的调用采用同步方式，即调用后被阻塞，但是这并不会影响到其它代理管理线程的运行，因此程序整体上表现出的还是并发执行。由于程序中大量的使用了多线程处理技术，其管理问题十分复杂。这里，对任务求解器定义了抽象接口，然后针对多线程处理定义了一个ClientAgent，封装了一个线程和任务求解器接口来对所有的任务求解过程实现多线程处理。

二、网格数据的传输与存储策略

  首先，远程对象可以保存状态，这就解决了数据网格的分布式存储问题。

网格数据在客户端上分别被计算完成后最终都是先传输到服务器端，保存在服务器上的，当所有的网格都计算完成后，服务器就会将这些网格数据根据静态任务和动态任务的分配策略再重新分配并传输到每台客户端上。理论上才服务器上采用多线程传输可以提高网络的利用率，虽然会加重服务器上的负载。但是对网格数据的传输过程进行分析后发现，网格数据占用的存储空间非常大，多线程传输模式下每个线程对网格数据的访问是分散的分布在整个网格中，即各线程访问的数据并不是同时聚集在一起的，这就违反了数据的局部性原理，对于大内存的服务器来说不存在这个问题，但对于小内存的服务器来说这必然会引起磁盘的调度，使数据在物理内存和页面文件之间频繁交换，从而降低服务器的速度。但是如果采用单线程传输，虽然磁盘的调度问题解决了（磁盘调度次数最少），但是传输速度太慢，因此在程序中采用了折中方案，静态任务采用单线程传输，动态任务采用多线程传输（每台客户端受到的数据都是一样的）。

  然而，在实际的测试中发现，当客户端比较少时，这种方案工作的很好，网格传送速度很快，但当客户端的数量增加时（>＝5），公共网格部分的传输速度明显变慢，服务器端的网络平均利用率很低。经过分析发现，当客户端过多时，一方面服务器端并发线程明显增多，线程之间的频繁调度可能造成系统的效率降低，另一方面，客户端过多造成并发线程传输公共网格的步调不一致，从而使大范围分布的网格被并发传输，这又早成了磁盘的频繁调度。因此，在最后的方案中所有的网格传输都采用单线程串行传输，这样虽然在传输公共网格的时候要重复磁盘调度numOfClient次，但效率是固定的，波动性不大。

三、动态任务的重组问题：

按照我们的任务分配算法，动态任务的目的是调整客户端的负载均衡问题，使得客户端的想互等待时间尽量少，但实际测试，随着计算的进行，这种调整作用逐渐减弱，甚至反而造成了客户端负载失调的问题。动态任务零星的分散在各个网格中，对于IJK个数为0的任务可以将其删除，避免无谓的调用，但有些网格中的IJK个数只有1个，却要进行网络调用，网络传输时间远大于实际的计算时间，虽然客户端表面上看处于负载均衡状态，但实际上计算效率非常低，因为大部分的时间用于网络传输，这种状况随着计算的进行不断恶化！

为了解决这种问题，必须从两个方面入手，一是调整好静态任务的比重，在本程序中将静态任务比重设置为0.9。另一方面必须对动态任务中的十字链表进行调整，将IJK个数少的整个到一个链表中，在程序中采用如下策略：首先对动态IJK十字链表降序排序，然后从最后一个元素入手，如果这个元素IJK个数少于500，那么就把它合并到前一个元素中，这样可以将动态任务重组为IJK个数比较大的大任务，同时降低任务的个数，减少网络调用的开销。但是，任务不能被过渡合并，即如果所有的任务IJK个数和还是小于500的话，任务最终不能被合并为一个，而是对任务的个数设置了一个底线：numOfClient/2，当任务个数等于这个底线时即使IJK个数很小，也不会被合并。