长时间计时不要用TimerDiff,应该用_Date_Time_GetTickCount

unique009 · 发表于 2012-11-26 22:57:06

回复 7# netegg

autoit对TimerDiff的说明是这样的:
Returns the time difference (in milliseconds) from a previous call to TimerInit().

说明精度是毫秒,而且返回结果居然还带n个小数位,我一直以为是纳秒级的,现在看来是被误导了.
但是长时间计时居然能比实际时间慢40%,这真让人无语啊.

其实直接调用api有时要比用autoit的原生函数的效率和可靠性更高吧,毕竟用DllCall没有太多内部参数判断,特别是计时类函数,精度不够就等于错误

annybaby · 发表于 2012-11-26 23:05:41

本帖最后由 annybaby 于 2012-11-26 23:08 编辑

回复 15# netegg

netegg · 发表于 2012-11-26 23:13:28

回复 16# unique009
以毫秒计量和精度是什么级别不是一个概念
简单的比方，1斤1两和1斤2两，是以两计量的，但是精度在斤而不在两

annybaby · 发表于 2012-11-26 23:15:57

回复 16# unique009

纳秒就别想了,什么语言的函数精度可以达到纳秒级的??更何况那个返回的结果还比纳秒小几亿倍~~
慢40%估计是程序出问题了~~
要命的是经常遇到timerdiff返回负数(主要比较小的计数)~~
刚刚试了一下用ZwDelayExecution延时1000秒测试,TimerDiff得到是998.37秒,差了一秒多,还行吧~~

netegg · 发表于 2012-11-26 23:18:47

本帖最后由 netegg 于 2012-11-26 23:27 编辑

回复 17# annybaby
但是别忘了一点，这个是乘了1000之后的，算的是毫秒，算精度要先除以这个1000才行，所以才有精度在微秒一说，纳秒那个说法有点扯淡，msdn上也没解释明白
另外再对对源码，sleep(1)，不管误差，怎么出来的10

netegg · 发表于 2012-11-26 23:36:42

本帖最后由 netegg 于 2012-11-26 23:42 编辑

防止array函数处理的时间问题，改成这样再试试
[au3]#include <WinAPIEX.au3>
#include <array.au3>
Local $time = ''
For $i = 0 To 5
$t = TimerInit()
_WinAPI_ZwDelayExecution(1000)
$time &= TimerDiff($t) & '|'
Next
$time &= '|'
For $i = 0 To 5
$t = TimerInit()
Sleep(1)
$time &= TimerDiff($t) & '|'
Next
$time &= '|'
For $i = 0 To 5
$t = TimerInit()
$time &= TimerDiff($t) & '|'
Next
Local $results = stringsplit($time, '|', 2)
_ArrayDisplay($results)
[/au3]

annybaby · 发表于 2012-11-26 23:54:56

回复 21# netegg

见鬼了,想不明白是怎么回事~~请看下面的三幅图,代码完全一样,都是你前面给出的
但结果完全不同~~

前后两幅都是直接运行剪贴板代码(写了个小程序方便运行在论坛中复制的代码进行测试),结果非常程序
中间的那幅是在编辑器中F5的,结果非常混乱~~

PS:找了下度娘,MS sleep(1)的准确值是1/64=15.625毫秒~~

annybaby · 发表于 2012-11-26 23:59:48

回复 20# netegg

我知道算的是毫秒,但你看结果:
明显延时的时间是1毫秒,但看结果~~每个都差N倍~~
所以我前面才说,AU对毫秒能处理准确些就好了,别想微秒了`

netegg · 发表于 2012-11-27 00:21:25

回复 23# annybaby
这个就是精度的意思，用上面说的斤两的说法，精度在两，是指可以测到两，但是实际保证准确值只能到斤

annybaby · 发表于 2012-11-27 00:53:51

回复 24# netegg

估计不是吧,它的极限大约是可以比较稳定测得约4微秒吧
我的机子进行一次简单加法约需要500ns,但它测得时间差为

0.0119812005936655
0.00439144027030725
0.00403039904003031
0.0035062050672084
0.00349620538298791
0.00349725798132691
0.0035014683746829
0.00334410492300243
0.00328463311684894
0.0035109417597339
0.0035146258539204
0.0035298885298359
0.00342094460174942
0.00891235013631148
0.00356357167668389
0.0035514667957854
0.0035214677431239
0.0035209414439544
0.0035340989231919
0.00332305295622244
0.0035088365630559
0.00333673673462943
0.0035362041198699
0.00360199151605739
0.00337305137732493
0.00380987968800985
0.00347989010873341
0.00329989579276444
0.0041414481647948
0.00371882993168637
0.00332515815290043
0.00332778964874793
0.00330357988695094
0.00341252381503742
0.00331621106701894
0.0035283096323274
0.0035340989231919
0.0035309411281749
0.0035367304190394
0.0035493615991074
0.00332042146037494
0.0035183099481069
0.561868046272223
0.0035551508899719
0.0035451512057514
0.0035540982916329
0.00333568413629043
0.0035440986074124
0.0035414671115649
0.0035425197099039

还算比较稳定吧~~

netegg · 发表于 2012-11-27 00:57:04

本帖最后由 netegg 于 2012-11-27 00:58 编辑

其实单点误差说明不了什么，算算概率期望值是多少就知道了

unique009 · 发表于 2012-11-27 13:19:08

回复 19# annybaby

QueryPerformanceCounter,rdtsc这些都是以纳秒计的,连zwdelayexecution都能达到100ns

另外,不要动不动就说别人程序有问题,你做个大运算量的循环在多核笔记本上多任务跑上1小时自已试试不就知道了?

annybaby · 发表于 2012-11-27 13:33:56

回复 27# unique009

我输了,你赢了,可以了,吗?

netegg · 发表于 2012-11-27 13:43:01

回复 28# annybaby
lz说的确实没错，QueryPerformanceCounter是以纳秒为单位的

annybaby · 发表于 2012-11-27 13:57:12

回复 29# netegg

唉,我以为楼主不理解我就算了,你竟然也不理解`~

我什么时候说过QueryPerformanceCounter不是以纳秒计的??
当然,我也从来没说过是!并且以后也不会说~~
由始至终,我的观点是:
AU3无法得到一个高精度的定时并准确显示~~比如说1微秒,当然,如果你觉得1微秒是小儿科的话,也可以给出个可以准确测定10ns的AU代码,让我开开眼界~~

		自动登录	找回密码
密码			加入

[系统综合] 长时间计时不要用TimerDiff,应该用_Date_Time_GetTickCount

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源

浏览过的版块