AMD或英特尔，以及内存品牌 - 页 11

新评论
[删除]  
Mathemat >>:
Спасибо, four2one. Короче, число ядер для МТ4 не играет абсолютно никакой рояли :)

完全同意，重要的是内存的数量，这不是为了速度。

 
four2one >> :

>> 完全同意，重要的是内存大小，而不是速度。

重要的不是内存的数量，而是CPU和内存总线的速度...。

赛扬是好的，因为它有一个800MHz的总线

 
keekkenen >> :

重要的不是内存的数量，而是CPU和内存的速度...

赛扬很好，因为它有一个800MHz的总线


我不确定在脚本执行过程中，它是否与内存进行了交流。所有的本地（机器）代码都可以进入高速缓存。这就是为什么我在谈论EA的原因。如果EA被优化，SAR将是至关重要的。所以......。这证明了我已经说过的话：i7和奔腾的核心基本相同。

 
Svinozavr >> :

我不确定在脚本运行时它是否与内存进行了交流。所有的本地（机器）代码都可以进入高速缓存。

有趣的是......我怀疑终端直接与CPU缓存进行通信，绕过了脚本本身注册的内存......。

 
keekkenen >> :

有趣的是......我怀疑终端直接使用CPU缓存，绕过了内存，脚本本身就是在内存中注册的......

这有什么好的？处理器将代码（机器指令）加载到其缓存中。这就是它的作用。它可以从内存或从任何地方加载。如果它得到了所有的代码，它就不再与内存进行通信，而是从其缓存中获取指令，并由内核对其进行切割。如果它要从内存中检索指令，它的速度会慢很多。

因此，缓存越多，程序的执行速度通常越快。而像测试脚本这样的程序，或者说是由MT4代码的字节生成的本地代码，可以装进我那该死的1 mb缓存中。

 
我的意思是，它不与内存沟通......因为我所说的执行不仅是指脚本的执行，还包括它的加载和结果的返回......。
 
keekkenen >> :
我的意思是，它不与内存沟通......因为我所说的执行不仅指脚本的执行，还包括它的加载和结果的返回......。

但我说的只是执行的过程!

因为在我们的案例中，无论是将脚本加载到缓存中，还是将结果返回，都不会对速度产生影响。从内存中一次性将代码加载到缓存中是非常快的操作。 但从它那里一个一个地获取命令是很慢的。这就是缓存的想法的基础。而在输出数据方面，我甚至沉默不语。有什么样的产出？

因为--再一次！！！。- 这个测试不具有代表性!你需要石头来与记忆沟通。例如，引用历史，不必进入缓存。

 
Svinozavr >> :

而我说的完全是执行的过程!

因为在我们的案例中，无论是将脚本加载到缓存中，还是将结果输出，都不会对速度产生任何影响。从内存中一次性将代码加载到缓存中是非常快的操作。 但每次挑出一个命令的速度很慢。这就是缓存的想法的基础。而在输出数据方面，我甚至沉默不语。有什么样的产出？

因为--再一次！！！。- 这个测试不具有代表性!你需要石头来与记忆沟通。例如，报价的历史，不必进入缓存。

好吧，让我们进入：测试的操作之一是通过循环来分配一个变量

你可以把它分成几个部分，例如...;)

start=GetTickCount();
for( i=0; i<1000000; i++) { tt=iOpen[ i];} 
test2=GetTickCount()- start;
 

或不，不是靠爪子，而是靠当地时间!

start=GetTickCount();
for( i=0; i<1000000; i++) { tt=TimeLocal();} 
test2=GetTickCount()- start;
这可以理解，在一两秒钟内不会有什么变化，但吸引力会有。?
 
kombat >> :

好吧，让我们进入：测试的操作之一是通过循环来分配一个变量

你可以把它分成几个部分，例如...;)

嗯...>>你可以。但为什么呢？ 听着，从MT4中抽取一个标准的专家顾问有什么问题？我们感兴趣的是优化，而不是抽象的脚本。将历史记录保存在档案中，并与测试的EA一起发布，这样大家就可以在同一个EA上测试。我们将谈论专家顾问中可优化的参数及其范围。而所有...

1...456789101112131415161718...94
新评论