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

新评论
 
komposter:

因此，你将不得不通过其他序列的几百万笔交易!这正是我的意思。

好吧，我说的是检查一个单一的数字（序列号），对于这样一个基本的操作，一百万并不算多。如果我们以递归的方式计算标准，那就只能是文件的一次通过，无论如何我们都要这样做。另外要考虑的是，递归数据图将包含同样的几百万个元素（乘以一个序列的参数数）。

另一个选择是在排序前 完全重新计算和存储标准。同样，使用递归的可能性也很关键。

很明显，会有很多操作，但在原来的版本中会不会比较少？

 
ALXIMIKS:

在C++中，如果没有解析器，你可以做到这一点。

将这个想法推10次--用另一个文件中序列位置的起始值启动另一个文件，那么你甚至不需要在序列结构中存储交易数量。

你将得到一个普通的索引，这在前面已经提到过了。

 

我实现了我上面描述的算法。

在X=20的情况下处理我的数据（对20个交易的标准计算）大约花了112分钟（没有准确地抓住它），大部分的份额被数组转移吃掉了（根据分析器，40%）。

经过数组的循环和其他一些优化，处理速度变得更快。

  • 对于X=20：48分钟
  • 在X=50时：60分钟

内存只够65个交易（乘以一百万个序列）。当然，这还不够--我还指望着至少有100个。

下一步是摒弃所有不必要的交易信息。只留下开盘和收盘时间，以及以点为单位的利润，设法以X=185起飞。

下一步--只是加快对文件的工作，FileReadXXX现在需要30%的时间（而且调度员说没有对磁盘进行工作，但CPU已经加载）。

FileRead正好是FileSeek之后的第一个，也就是说，连续读取的效果很快。

我将让你知道新的结果。

kazakov.v:
在C++中，它是由fread在64K-128K的缓冲区中完成的，由你自己的分析器来解析它更好，因为scanf-es非常慢。

我将尝试通过WinAPI来处理这些文件，这是服务台给我的建议。

ALXIMIKS。

我把这个想法推了10遍--用另一个文件中的序列的起始位置的值做一个文件，那么在序列的结构中甚至不需要存储交易的数量。

我不明白该指数将做什么。

写下交易的数量并没有什么区别，顺序读取工作很快，问题是在文件中移动后确切地读取块。

请写一个建议的算法。

C-4:

这个问题非同小可，但目前还没有一行代码。安德烈，这里很多人都很感兴趣--提出问题并提供测试数据。让我们来组织一些体育节目。

我们需要测试数据+伪代码，有数据工作的一般原则。

任务从开始到结束都是制定的。

而测试数据可以用一个稍加修改的脚本来生成，我在前面发布了这个脚本。

我稍后会这样做。

joo:
为什么要从基础上进行选择呢？根据标准在历史上产生交易会更好吗？ 不是吗？这不是和要求一样吗？

如果是为了测试，当然可以，但如果是为了解决问题，当然不行 )


烛光。

好吧，我们正在谈论检查一个单一的数字（序列号），对于这样一个基本的操作来说，一百万并不是那么多。如果我们递归地考虑批判，这只是文件的一次传递，我们无论如何都要这样做。另外要考虑的是，递归数据图将包含同样的几百万个元素（乘以一个序列的参数数）。

另一个选择是在排序前 完全重新计算和存储标准。同样，使用递归的可能性也很关键。

很明显，在任何情况下都会有大量的操作，但在原始版本中是否较少？

在最初的变体中，当从通过的历史记录中找到最后一笔交易时，你可以计算一次该标准。

而你需要读取这样一个文件片段，它将包含所有 序列的X个交易。它将比X*序列数大得多，因为有不同数量的交易，它们可能不是均匀分布的。


2所有。

无论如何，感谢你的支持。

如果你不介意的话，请运行测试脚本 并分享结果。

 
komposter:

而测试数据可以用我之前发布的稍加修改的脚本来生成。

我附上更新后的脚本，现在它不只是记录相同的交易，而是按照指定的设置（寿命--从和到，利润--从和到）生成随机序列。

要想得到一个与我相似的文件，请以默认设置运行该脚本。

2014.08.28 04:12:36.044 sTest_ReadWriteBIN EURUSD,M15:140,000 secuences writown in57.1 sec
2014.08.28 04:13:20.688 sTest_ReadWriteBIN EURUSD,M15: 在44.0秒 内加载6632Mb(150.7 MB/sec)

之后，你就可以在上面计算出算法。

对于最懒的人来说，把文件存档在谷歌硬盘上。

附加的文件：
sTest_ReadWriteBIN.mq4  5 kb
 

komposter:

1.在原来的变体中，你可以在从通过的历史中找到最后一笔交易时计算一次标准。

在你的变体中，你需要读取这样一个文件，它将包含所有 序列的 X个交易。它将远远大于X*序列的数量，因为交易的数量不同，它们可能不是均匀分布的。

1 这一点不是很清楚，如果我们要寻找最大（最小）的标准，我们最后还是要计算所有候选人的标准。至于寻找的是局部还是全球的极端现象，这甚至并不重要。

2.显然，更多的是在所需的内存方面，可接受的尺寸或不可接受的问题。此外，就磁盘读取速度而言，更大的块大小在理论上甚至更好。当然，对RAM来说还不是问题。最重要的是，阅读要按顺序进行，而且只读一次。

然而，在排序前计算标准的变体需要阅读两次。但它也有自己的优势，特别是考虑到将数据分割成几个小文件并随后联合处理的可能性。

然而，如果没有实施，所有的论据都将是抽象的。因此，在讨论的这一点上，我将不得不离题 :)

 
komposter:

如何对文件进行拼接，并对哪个位是哪个文件的开始和结束进行索引。

例如，将1000个文件做成1000个元文件，如果标准已知，则进行统计排序，将类似的文件装入一个元文件。

最好用FileOpen 做个实验，在打开一个大文件或一个小文件时，它的工作速度是怎样的，是打开1000次大文件等于1000次小文件还是打开1000000次小文件？

结果可能是，这些文件不应该被合并，而应该被分割。

 
Urain:

如何对文件进行拼接，并对哪个位是哪个文件的开始和结束进行索引。

例如，将1000个文件做成1000个元文件，如果标准已知，就进行统计排序，将类似的文件装入一个元文件。

最好用FileOpen做个实验，在打开一个大文件或一个小文件时，它的工作速度是怎样的，是打开1000次大文件等于1000次小文件还是打开1000000次小文件？

结果可能是，文件不应该被合并，而应该被拆分。

我目前正在用一个大文件工作，但想去做一百万个小文件。

首先，它们可以被追加，其次，它们可以通过名称被访问（不需要存储 "每个序列的开始"）。

我在服务台询问了关于不同文件的一百万次打开的问题（我以这种方式实现了高速缓存）。答案是明确而直接的。

我将对一个大文件和一百万个小文件测试api-function，我将公布结果。

烛光。

然而，如果没有实现，所有的论据都将是抽象的。因此，在讨论的这个阶段，我退出是合适的 :)

我应该从它开始;)

但无论如何，感谢你的参与，没有代码的想法也是有价值的。

 

有了一百万个文件，你就会以这样的方式毁掉ntfs，你会从微软这个疯狂的创意中哭出来，它把每个人都永远锁在它疯狂的弱智的文件系统的实现中。

ms在他们的文件系统中所做的一切，都是畸形的重量、弱智和愚蠢的行为。糟糕的是，这些白痴没有做出任何努力来优化和提高速度，而且api也只是原始的。在2014年，这一点可以毫不含糊地说明。好了，哭了。

 

任何想提高在windows中处理一堆文件的效率的人，他们做的第一件事就是进入大块--在一个文件中进行分组和自己的数据结构。

一旦你开始在windows中存储超过一千（更不用说几万或几十万）个不同的文件，你就完蛋了。

 

MQL4/5中的文件操作通过我们非常有效的缓存机制，这使我们能够实现非常有效和高的读写速度。

你可以一个字节一个字节地流传数据--所有的数据将被迅速收集到内部缓冲区，并只以大块的形式写入磁盘。WinAPI调用的数量是最少的，这给了人们高速的操作。读取是类似的--它主动地工作，大块地读取，很少调用WinAPI，并以最小的开销非常迅速地从其缓存中回馈数据。

粗略地说，与Build 509相比，我们在MQL4/5中的文件操作速度提高了一个数量级（如果我们指的是基于块的常规操作，而不是 "按兆字节块写入以最大化速度测量"）。

1...12131415161718192021
新评论