用多核 CPU 来加速文本运算

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

这是一个创建于 4029 天前的主题，其中的信息可能已经有所发展或是发生改变。

http://www.aqee.net/use-multiple-cpu-cores-with-your-linux-commands/

用多核

CPU

文本

18 条回复 • 1970-01-01 08:00:00 +08:00

luikore

2013-10-30 09:24:41 +08:00

文章展示了 cat 命令的一个常见误用: 没有多个文件却用 cat 连接.
结果是多产生了一个进程和一个管道.

正确写法是:
<some.txt other cmd ...

像 wc -l 这类命令的瓶颈明显是硬盘, parallel 以后反而比单核的慢.

Muninn

2013-10-30 09:59:00 +08:00

恩压缩估计会好很多
io类的命令,确实很难说

felix021

2013-10-30 10:25:19 +08:00

测试过wc和grep这种非IO密集型的应用，用了parallel以后反而慢了很多很多；bzip2的话性能可以提高好几倍

oldcai

2013-10-30 11:49:04 +08:00

@felix021 wc和grep就是IO密集型吧。bzip2之类的倒是CPU密集型。
人生何处不相逢啊。。felix021君。。

felix021

2013-10-30 11:53:21 +08:00

@oldcai 嗯，我说反了。。。

est

2013-10-30 14:06:03 +08:00

@oldcai 一个反例：WinRAR的解压，IO write是瓶颈。

oldcai

2013-10-30 14:10:50 +08:00

@est 嗯，还是得具体分析，针对一般机器和一般压缩算法而言，CPU更容易是瓶颈。

bombless

2013-10-30 14:24:57 +08:00

@luikore 哈哈，的确是。他这种看的很不舒服

reusFork

2013-10-30 15:28:39 +08:00

确定这样压缩出来的文件还能解压么？
--pipe
--spreadstdin
Spread input to jobs on stdin (standard input). Read a block of data from stdin (standard input) and give one block of data as input to one job.

luikore

2013-10-30 17:15:27 +08:00

@oldcai CPU比IO快多了, 而且多数CPU瓶颈的场景都是用GPU解决的, 3000个核做data parallel比寥寥几个核做task parallel效果好很多...

guangwong

2013-10-30 21:40:12 +08:00

= = 说真的，单核分析不动了我就不用这些东西分析了，有更垂直的轮子。。。。。

Ricepig

2013-10-31 02:24:12 +08:00

@luikore 我以前也是这么想的，直到看到两篇文章。一篇是说gpu做一个算法有多牛逼。另一篇是intel写的，说是你用来比较的cpu上的代码太烂，爷给你写一个，秒杀GPU实现。

luikore

2013-10-31 09:48:55 +08:00

@Ricepig 链接? 估计那个问题不适合并行化或者不是computation bound的问题

pythonee

2013-10-31 16:24:11 +08:00

@luikore 开头这个小于号是什么原理，这个叫什么？没有见过，望指教

luikore

2013-10-31 17:25:36 +08:00

@pythonee 以文件为命令的输入流, 放前面和放后面一样, 可以和 > 对比想想. man bash 能找到更详细的阐述

luikore

2013-10-31 17:26:21 +08:00

@pythonee bash 的手册里 Redirecting Input 那段

pythonee

2013-10-31 20:32:10 +08:00

@luikore 这样写的可读性是不是有点差，个人觉得管道容易理解一些啊
不知道input哪个怎么理解好理解一点

luikore

2013-10-31 22:06:06 +08:00

@pythonee 既然理解了重定向output stream, 为什么不理解重定向input stream...