并行扩展

我有一个应用程序与沉重的IO操作，如文件复制，压缩和移动文件周围的文件系统，复制到备份服务器。并行扩展

我构建这个程序为单线程。它在2分钟内运行。

我构建了另一个版本的这个程序与并行扩展和使用任务，它也运行了近2分钟。

换句话说，由于重IO导致使用Parallels，我没有看到性能提升。

如果我将应用程序部署到刀片服务器，会得到相同的结果吗？

刀片服务器是否比我的工作站更快/在多通道上处理IO？

使用Parallels和IO绑定应用程序没有好处吗？

来源

2011-03-18 DarthVader

你正在做很多I/O，所以看起来它是一个瓶颈。如果它是计算密集型的，你很可能会看到有所不同，因为它实际上使用了CPU AFAIK。 – 2011-03-18 03:42:50

在刀片服务器上如何？它会有所作为吗？ – DarthVader 2011-03-18 03:44:50

刀片服务器只会因CPU处理能力不同而带来不同的IO带宽。 – 2011-03-24 04:53:25

如果你只是在系统上复制或移动文件，那么TPL提供的并行性不会对你有很大帮助。举例来说，实际上并不使用任何CPU，它只是改变磁盘目录记录结构中的文件位置。

文件压缩是一个不同的故事。在这里，您正在加载数据并使用CPU在将数据保存到磁盘之前进行压缩。您可以使用pipeline或parallel loop以更高效的方式加载/压缩/保存数据。而不是让一个线程在压缩每个文件上工作，你可以有多个线程在不同的文件上工作。

以下代码按顺序压缩文件，然后并行压缩文件。我在i7 920上获得了以下时间，并使用intel X25 SSD压缩了总共800Mb数据的329张JPG图像。

顺序：39901ms

并行：12404ms

class Program 
{ 
    static void Main(string[] args) 
    { 
     string[] paths = Directory.GetFiles(@"C:\temp", "*.jpg"); 

     DirectoryInfo di = new DirectoryInfo(@"C:\temp"); 

     Stopwatch sw = new Stopwatch(); 
     sw.Start(); 
     foreach (FileInfo fi in di.GetFiles("*.jpg")) 
     { 
      Compress(fi); 
     } 
     sw.Stop(); 
     Console.WriteLine("Sequential: " + sw.ElapsedMilliseconds); 

     Console.WriteLine("Delete the results files and then rerun..."); 
     Console.ReadKey(); 

     sw.Reset(); 
     sw.Start(); 
     Parallel.ForEach(di.GetFiles("*.jpg"), (fi) => { Compress(fi); }); 
     sw.Stop(); 

     Console.WriteLine("Parallel: " + sw.ElapsedMilliseconds); 
     Console.ReadKey(); 
    } 

    public static void Compress(FileInfo fi) 
    { 
     using (FileStream inFile = fi.OpenRead()) 
     { 
      if ((File.GetAttributes(fi.FullName) 
       & FileAttributes.Hidden) 
       != FileAttributes.Hidden & fi.Extension != ".gz") 
      { 
       using (FileStream outFile = 
          File.Create(fi.FullName + ".gz")) 
       { 
        using (GZipStream Compress = 
         new GZipStream(outFile, 
         CompressionMode.Compress)) 
        { 
         inFile.CopyTo(Compress); 
        } 
       } 
      } 
     } 
    } 
}

对于压缩代码中看到How to: Compress Files

来源

2011-03-18 04:46:26

+1建议允许每个线程从头到尾采取一个文件......这是我首先会尝试查看性能如何变化的。 – BonanzaDriver 2011-03-18 05:11:58

我认为并行扩展的优势可能会对CPU的运行产生重大影响。 Donnu它应该如何影响IO寿。

来源

2011-03-18 03:47:17 Shimmy

这一切都取决于你是否是CPU密集型还是IO约束。我会建议做一些性能测试，看看你的瓶颈在哪里。

如果你发现你正在移动和压缩很多文件（到不同的磁盘，因为在同一个磁盘上的移动只是一个FAT表的改变），你可能想看看实现一个压缩的流式文件移动器移动。这可以节省移动文件后重新读取文件的额外IO。我用移动和校验和完成了这个，在我的情况下是一个巨大的性能凹凸。

希望这会有所帮助。

来源

2011-03-18 05:01:43

如果您要在一台物理设备上移动文件，则不会因将多个并行IO请求发送到同一台设备而看到很多性能优势。该设备的运行速度比CPU慢许多个数量级，因此并行进行的多个请求仍然会在设备上一一处理。您的并行代码正在被序列化，因为它们都访问同一个设备，但一次不能处理多个请求。

您可能会看到一个微小的改善PERF并行代码，如果你的磁盘控制器实施的“电梯寻求”，“分散 - 集中”，或乱序等操作，但PERF差异会比较小。

对于文件I/O，您应该在哪里找到更有价值的perf差异，是在多个不同的物理设备之间移动文件时。您应该能够将磁盘A上的文件移动或复制到磁盘A上的其他位置，同时还将磁盘B上的文件复制到磁盘C.使用许多物理设备时，并没有将所有并行请求堆叠在一起等待一个设备来填充所有请求。

您可能会看到与网络I/O类似的结果：如果一切都正在经历一个以太网卡/网段，那么您将不会实现与多个以太网卡和多个网段一样多的并行性，与...合作。

来源

2011-03-18 05:02:03 dthorpe

我有一个是在处理的WinForms实施〜7800个网址，在约5分钟（应用程序下载URL，解析内容，查找特定的数据，如果它发现它在寻找什么呢的一些额外的处理那个数据

这个特定的应用程序过去需要26到30分钟才能运行，但是通过将代码更改为TPL（.NET v4.0中的任务并行库），它仅在5时执行。计算机是采用双核四Xeon处理器（3 GHz）的戴尔T7500工作站，运行24 GB内存，Windows 7旗舰版64位版本

虽然这与您的情况并不完全相同是非常密集的IO。关于TPL的文档声明它最初是为处理器绑定的问题集而设计的，但这并不排除在IO情况下使用它（正如我的应用程序向我演示的那样）。如果你至少有4个内核，并且你没有看到你的处理时间显着下降，那么你可能有其他的实现问题妨碍了TPL的真正高效性（锁，硬盘驱动器等）。 “并行编程与Microsoft .NET”的书确实帮助我了解了代码需要如何修改才能充分利用所有这些优势。

值得一看在我看来。

来源

2011-03-18 05:08:44 BonanzaDriver

回答

相关问题