d*******o
发帖数: 5897 | 1 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
NRow，列数为NCol吧。
要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
算不需另一个element的信息；
2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
等的element的信息；
3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
个输出element，所以会有总共NRow * NCol个输出element，这些输出element都在一个
输出文件里；
4. 最后输出文件数目和输入文件数目相等，每个输出文件也包含一个和输入文件同样
大小的矩阵
这么大的数据量，不可能一次全读进内存，所以只能分次读；因为在处理某个输入文件
的某个element时要用到前面输入文件的内容，所以理想情况下是一次打开这几百文件
，这样就不用反复去open、close前面的文件，但一个程序要同时打开几百个file
pointers，好像不行。
我现在能想到的可行方法几乎是最慢的了，给定一个element（由一个行号一个列号确
定），open、close几百个输入文件，完后处理下一个element（更新行号、列号），再
open、close几百个输入文件……直至所有文件所有元素处理完。但这样子文件open、
close的次数是10亿多次了，没有测试过这么频繁的文件读写需要多少时间，但觉得会
很慢。
有啥好的办法没有？ |
l***y
发帖数: 4671 | 2 想起俺们最近申请到了一个服务器群的账户，问到系统可用资源时，被告知，对于每个
项目，内存 2T ~ 10T，CPU 是 100k ~ 500k 个 core，而且我们可以开 n 个项目。如
果需要更多资源就需要写个 justification。。。
俺突然就发现自己不会编程了。。。
【在 d*******o 的大作中提到】
: 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
: 阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
: NRow，列数为NCol吧。
: 要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
: 1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
: 算不需另一个element的信息；
: 2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
: 排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
: 等的element的信息；
: 3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
|
t****t
发帖数: 6806 | 3 一次打开几百个文件本身没有问题. 比如fedora, 缺省核心的限制是同时1024个
descriptor.
【在 d*******o 的大作中提到】
: 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
: 阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
: NRow，列数为NCol吧。
: 要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
: 1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
: 算不需另一个element的信息；
: 2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
: 排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
: 等的element的信息；
: 3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
|
d*******o
发帖数: 5897 | 4 每个用户1024还是整个系统？
不过1024也不大够，我的程序极端情况下会有2、3千个文件，几百个是一般情况。
【在 t****t 的大作中提到】
: 一次打开几百个文件本身没有问题. 比如fedora, 缺省核心的限制是同时1024个
: descriptor.
|
t****t
发帖数: 6806 | 5 当然是每个进程了, 你不会认为整个linux同一时刻一共只能开1024个文件吧
要调整的话, 看这里
http://www.cyberciti.biz/faq/linux-increase-the-maximum-number-
【在 d*******o 的大作中提到】
: 每个用户1024还是整个系统？
: 不过1024也不大够，我的程序极端情况下会有2、3千个文件，几百个是一般情况。
|
w***g
发帖数: 5958 | 6 看不出你这个问题有什么难的，唯一要考虑的就是避免disk seek。几千万个元素的矩
阵的话N差不多是10000, 也就是一行读入后占差不多100K。 你有几百个文件，每个文
件一行加起来差不多是100M。你一次读100行，那么总共占10G内存，每次从每个文件读
差不多10M数据，基本上disk seek就可以不考虑了。
【在 d*******o 的大作中提到】
: 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
: 阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
: NRow，列数为NCol吧。
: 要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
: 1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
: 算不需另一个element的信息；
: 2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
: 排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
: 等的element的信息；
: 3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
|
t*****n
发帖数: 4908 | 7 你的问题很有强度。即使超级计算机也不一定能跑下来。难道是天气预报，还是分子计
算？我觉得还是要进一步简化。首先你的算法有数学理论基础吗？有点话看看别人是怎
么处理的。没有的话恭喜楼主了，未来paper大大的。其次这些矩阵是正定稀疏矩阵吗
？有专门的算法，内存也用的少。
如果你的element与其他element无关，只关联到其他文件行号、列号分别相等的
element，我觉得你可以预处理一下。把这些相关性整理到文件。然后你对这些整理后
的文件进行计算。内存要求就小多了。多算算总有结果。
..............
【在 d*******o 的大作中提到】
: 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
: 阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
: NRow，列数为NCol吧。
: 要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
: 1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
: 算不需另一个element的信息；
: 2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
: 排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
: 等的element的信息；
: 3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
|
d*******o
发帖数: 5897 | 8 农业系的人接了个啥项目，估计他们系的人搞不定，来找我老板，我老板就让我干。前
面有人回帖说了，其实问题是不难的，难就难在数据量太大，怎么能快点算出来。
【在 t*****n 的大作中提到】
: 你的问题很有强度。即使超级计算机也不一定能跑下来。难道是天气预报，还是分子计
: 算？我觉得还是要进一步简化。首先你的算法有数学理论基础吗？有点话看看别人是怎
: 么处理的。没有的话恭喜楼主了，未来paper大大的。其次这些矩阵是正定稀疏矩阵吗
: ？有专门的算法，内存也用的少。
: 如果你的element与其他element无关，只关联到其他文件行号、列号分别相等的
: element，我觉得你可以预处理一下。把这些相关性整理到文件。然后你对这些整理后
: 的文件进行计算。内存要求就小多了。多算算总有结果。
:
: ..............
|
t*****n
发帖数: 4908 | 9 10亿次读写。假设每次1秒。10亿要277777小时或者11574天。超级计算机跑个1年也许
有结果。所以我说你的问题很有挑战性。还是需要简化，不然有难度。
【在 d*******o 的大作中提到】
: 农业系的人接了个啥项目，估计他们系的人搞不定，来找我老板，我老板就让我干。前
: 面有人回帖说了，其实问题是不难的，难就难在数据量太大，怎么能快点算出来。
|
x****u
发帖数: 44466 | 10 什么地方的读写一次要一秒？就算硬盘在月球上，也可以通过cache解决这个问题。
【在 t*****n 的大作中提到】
: 10亿次读写。假设每次1秒。10亿要277777小时或者11574天。超级计算机跑个1年也许
: 有结果。所以我说你的问题很有挑战性。还是需要简化，不然有难度。
|
l******u
发帖数: 1174 | 11 Google一下 memory-mapped files.
【在 d*******o 的大作中提到】
: 在linux下面。有几百个text输入文件，每个文件2GB，每个文件里包含一个double 矩
: 阵，大概几千万个elements吧，每个文件的矩阵行数相等、列数也相等,假设行数为
: NRow，列数为NCol吧。
: 要对每个输入文件的每个elements做些计算，这些计算有下面这些特点/约束：
: 1. 同一个输入文件里，不同行、列号的element是互相独立的，即对某一element的计
: 算不需另一个element的信息；
: 2. 不同文件里，行号、列号分别相等的element，它们是有关系的。如果把几百个文件
: 排序，对一个文件里的一个element的计算，需要用到前面的文件里行号、列号分别相
: 等的element的信息；
: 3. 对同一输入文件的所有（NRow * NCol个）element计算后,因为每个element对应一
|
d****n
发帖数: 1637 | 12 同时打开1000个文件，程序肯定会卡死。
你要用amortize 法则。buffer IO.
譬如，你不能同时装入全部文件。
但是你可以把每个文件得1000行顺序读入。
充其量也就是1000＊1000个array大小再内存里面。
然后纪录每个文件得lseek，用一个独立得 array。
处理前1000个文件得1000行。
输出这些到文件。
读入lseek 得 array，读入下1000个文件得各1000行，继续重复处理。
一般这个buffer理想应该在10million。这样做，你能实现计算。
又不至于让内存用干。 |
