需要帮助!无法解决这个问题，我遇到了硬件限制 - 页 2

新评论
 
ALXIMIKS:

我记得有一个网站 讨论了一个类似的问题和在C++中的解决方案的变种。

谢谢，我会读的。

伊万-伊万诺夫。
我很抱歉，如果我尝试64位或mt只能旋转32位怎么办？
我天真地以为，这样一个高度数学化的东西应该在64位上旋转。
以空气动力学计算软件为例，它们在32位上无法工作。
关于主要的论点，即32倍的计算机运行速度更快，我知道，但这是一个硬件问题，我认为。

切换到x64只是把天花板往后推，而且推得不是很远。我将不必跑出去买16Gb的内存。;)

 
anonymous:

1.当然，要使用x64系统。

2.在亚马逊EC2云中租一台更强大的机器，在上面做计算。

3.使用压缩数据，在内存中即时解压。如果你把真实数据分成流（符号/尾数/指数），压缩效果会更好；你可以使用12位浮点数（以牺牲精度为代价）。

4：用能处理大数据的东西（Matlab/R/等）做一个非顾问的计算。

1,2：这是关于推回天花板的问题，你想解决这个问题而不被一个具体的数字所束缚。

3.问题不在于磁盘上的数据量，而在于内存中的数据量。我可以再压缩10-20%，但同样，这也解决不了问题。

4.我抱着希望，暂时留在沙盒里。这样，后来的复制者/同步者就不必写...

谢谢你的参与!

 
komposter:
切换到x64只会将上限推后，而且不会很远。我没有必要跑出去再买16Gb的内存，对吗？;)

你不是一直在处理这种数据，对吗？为x64编写，需要时在亚马逊上运行。你也可以在微型实例上进行调试。

然而，如果你一直面临这个问题--你可以用大约1千美元购买64GB的内存，例如。Corsair Vengeance Pro CMY64GX3M8A2133C11.

要么重新考虑算法的设计，使其能够在数据上单次工作。

p.s. 你也可以在内存中存储压缩数据，并在需要时解压缩，以获得足够的时间来处理它

 
komposter:

谢谢你，我将阅读。

切换到x64只会把上限推后，而且不会很远。我不会再跑去买16GB的内存了吧？;)

你一定是在跟我开玩笑 :-)
我是一个有8个G的傻瓜，可以玩的。
 

方案1：将文件切成碎片。

方案2：将文件切成碎片，但也要将其系统化。就像字典里的一个词。以 "A "开头，搜索 "A.txt"。这样你就可以以树状形式排列数据（类似于字典：文件夹A、B......在文件夹A中的文件夹AA、AB等），搜索会非常快。

 
komposter:

所以你要读很多遍，这就是。

  • 非常、非常缓慢。
  • 将在驱动器上擦出一个洞。

虚拟RAM磁盘的救援;)

而且你不会有一个洞，你会喜欢这个速度。

并立即提供整卷资料。

不要切成碎片，因为碎片不适合任务。

 
我会尝试把文件切成几块，然后根据需要加载每一块（也就是迪马建议的那样）。很难说清楚，因为这取决于具体的任务。但这个问题很有趣，请随时向我报告你的发现。
 
komposter:

1.这是缓存...或者我不明白你的意思。我的选择是不断阅读必要的大块内容？

好吧......通过其包装器读取文件，包装器会在内存中保留一小部分文件，并在不读取的情况下进行替换。我的意思是，你知道文件是如何被使用的，所以包装器应该会变得相当有效。

康帕斯。

哦，该死...

同样的鸡蛋，只是从侧面看。阅读速度可能会加快，但并不能在全球范围内解决问题。

好吧，我在想小范围内的重复性行动。

映射的用途是使用wind的缓存，而不是写自己的缓存。装入大块，读取它，卸下它。如果该块被经常使用，winds会将其保留在内存中。

匿名 的。

3.使用压缩的数据，在飞行中解压。如果你把真实数据分成流（符号/尾数/指数），压缩效果会更好；你可以使用12位浮点数（以牺牲精度为代价）。

4.用能处理大数据的东西（Matlab/R/等）做一个非顾问的计算。

或如此（c）。
 
如果不了解数据结构的 具体情况和要进行的操作，就只能给出一般性建议。其中一个选择是将原始数据转换为较小尺寸的元数据--同样是4Gb--一次或多次完成（但不擦拭磁盘），然后再处理元数据（聚合值，按某些参数切割，等等）。如果这不起作用，那就把数据装入DBMS。
 
komposter:

有大量的信息（大约20GB的文本文件）。

...

如果这个文件是用存档器压缩的，它有 多大（因为文本应该被压缩得非常好）？

123456789...21
新评论