代码之家  ›  专栏  ›  技术社区  ›  ennuikiller

当我使用线程时,为什么我的Perl脚本解压文件的速度较慢?

  •  3
  • ennuikiller  · 技术社区  · 15 年前

    usethreads=define , useithreads=define . 我有一个简单的脚本来读取4个gzip文件,每个文件包含大约750000行。我正在使用 Compress::Zlib 执行文件的解压缩和读取。我有两个实现,它们之间唯一的区别是一个包括 use threads . 除此之外,两个脚本都运行相同的子例程来执行读取。因此,在psuedocode中,非线程程序执行以下操作:

    read_gzipped(file1);
    read_gzipped(file2);
    read_gzipped(file3);
    read_gzipped(file4);
    

    线程版本如下所示:

    my thr0 = threads->new(\$read_gzipped,'file1')
    my thr1 = threads->new(\$read_gzipped,'file1')
    my thr2 = threads->new(\$read_gzipped,'file1')
    my thr3 = threads->new(\$read_gzipped,'file1')
    
    thr0->join()
    thr1->join()
    thr2->join()
    thr3->join()
    

    现在,线程版本的实际运行速度几乎是非线程脚本的2倍。这显然不是我所希望的结果。谁能解释一下我做错了什么?

    4 回复  |  直到 15 年前
        1
  •  9
  •   Andomar    15 年前

    我猜GZIP操作的瓶颈是磁盘访问。如果您有四个线程在竞争磁盘硬盘上的磁盘访问,这将大大降低速度。磁头必须快速连续地移动到不同的文件中。如果一次只处理一个文件,磁头可以靠近该文件,磁盘缓存将更加准确。

        2
  •  10
  •   jamessan    15 年前

    您正在使用线程来尝试加速受IO限制而非CPU限制的内容。这只会引入更多IO争用,这会减慢脚本的速度。

        3
  •  4
  •   user80168 user80168    15 年前

    如果你处理的事情主要是

    Parallel::ForkManager 模块。

    一般来说,Perl中的线程并不是很好。

        4
  •  0
  •   Dave Sherohman    15 年前

    top 当它运行时。像depesz一样,我倾向于假设压缩/解压缩操作(需要大量数学运算)更有可能受到CPU的限制。

    从未 [1] 改善问题—如果CPU利用率已经达到100%,那么更多的线程/进程不会神奇地增加其容量—并且很可能会增加更多的上下文切换开销,从而使情况变得更糟。

    make 使用两倍于机器处理器数量的进程,我个人的经验是,这似乎是准确的。我听到的解释是,这允许每个CPU在一个进程中忙于编译,而另一个进程则在等待从主存获取数据。如果您将编译视为CPU限制的进程,则这是正常规则的例外。如果将其视为I/O绑定的情况(I/O位于CPU和主内存之间,而不是磁盘/网络/用户I/O之间),则情况并非如此。