[更新376#2825]PECMD2012.1.80.13_Win32_64.多窗口多线程.裸机系统2.3.3.1+18M酷M...

2010qaqz111

SET-def 会改变变量的值吗？如果之前这个变量已经存在并且有非空的值的情况下再遇到 SET-def 的话？

mdyblog

原帖由 2010qaqz111 于 2013-4-1 13:03 发表
SET-def 会改变变量的值吗？如果之前这个变量已经存在并且有非空的值的情况下再遇到 SET-def 的话？

会的。
SET-def  A=XXX
如果本级有， 就相当于 SET A=XXXX
   值变为XXX
如果本级没有， 新建一个，值设为XXXX

2010qaqz111

那看来还是用find+set了

2010qaqz111

LOGS 感觉太简陋了，能否稍微改进一下？加上时间戳和来源文件以及线程ID，各部分之间用一个字符分离，方便EXCEL导入成表格进行分析查错，尤其是多线的时候。

EXEC --clone 的时候最好也能继承 LOGS 开关的状态，LOG 文件开另外一个也行。

mdyblog

原帖由 2010qaqz111 于 2013-4-2 13:07 发表
LOGS 感觉太简陋了，能否稍微改进一下？加上时间戳和来源文件以及线程ID，各部分之间用一个字符分离，方便EXCEL导入成表格进行分析查错，尤其是多线的时候。

EXEC --clone 的时候最好也能继承 LOGS 开关的状 ...

PECMD2012.1.75.1-130314-30.多窗口线程孵化版_win32_64.sfx.zip

1: 线程ID\t高精度计时数\t[命令] 。。。

2: EXEC --clone  需要在 最开始加一条LOGS命令，来开启自己的LOGS
这个没法继承， 因为还需要指定新的 LOG文件的。

可以
LOGS *X.%__PID%.LOG



多线程 也可类似。
可以
@LOGS *X.%__TID%.LOG
//@是防止 打到 父线程LOG， 引起干扰。

[ 本帖最后由 mdyblog 于 2013-4-2 17:33 编辑 ]

2010qaqz111

原帖由 mdyblog 于 2013-4-2 16:56 发表
2: EXEC --clone  需要在 最开始加一条LOGS命令，来开启自己的LOGS
这个没法继承， 因为还需要指定新的 LOG文件的。

可以

LOGS *X.%__PID%.LOG



多线程 也可类似。

可以

@LOGS *X.%__TID%.LOG
//@是防止 打到 父线程LOG， 引起干扰。

那么给 --clone 增加一个 --logs 开关如何？让进程在 fork 的时候视为在 LOAD 的配置文件最开始插入了一条 LOGS 命令，这个参数不知是否可以从父进程传递到子进程，如果可以的话应该就没问题，因为 --logs 可能带上 %__PID% 之类的参数，在子进程里面这个值的解释和父进程会不一样。
因为一般使用 LOGS 做分析的时候都是希望一条命令就能够掌控整个过程的 LOG 是否产生（比如，类似 C++ 的 _DEBUG 预定义宏），如果在新 fork 进程的时候每个配置文件都要来一下的话会很麻烦，而且开多线有 LOGS 开多进程要新指定 LOGS 这样类似的操作但是行为有差异貌似也不是很好的风格。




我现在用的一个生成 LOG 来辅助分析的方法是这样：
TEAM {DATE &&CT uptime|CALC &&CT=%&CT%/1000##3|WRIT %Desktop%\PECMDLOG\%&CT%-PNET-IN,,}
放在配置文件头部，PNET-OUT 放在配置文件最末尾，在文件中间可能也会放置这样的命令，不过替换的红字不一样。

我是把同类型工作放到单独的 INI 文件里面，这些是为了记录进入和完成每一个工作需要的时间，对于特别耗时间的操作就把 LOAD 改为 THREAD* LOAD 或者 EXEC --clone 的方式执行。
实际上这种分析效果很不错，几次测试下来之前一个 PE 的启动进程我用多线程和多进程配合，把启动过程加快了 10 秒左右。这是在一个很老的单核单线机器上的效果，如果在新的机器上应该能够更快的。

我是比较习惯将不同的操作分开在不同的配置文件里面进行，因为这样方便选择是用多线程还是多进程，如果是用 _SUB 的话，多线程倒是可以，但是要开多进程来执行就稍稍有些不方便（目前好像也没有比较直接的手段可以将一个 _SUB 丢到新进程去执行）。

所以，我想建议给 LOAD 加载的配置文件各自自动产生一条类似：
线程ID\t高精度计数\t[进入/完成某配置文件]
这样的信息。

之前在说到 IMPORT 的处理机制的时候，我猜想在 PECMD 的脚本代码执行之前应该是对全部代码有过一次扫描的，这样如果在文件中部出现 LOGS 的话，就在该文件开始执行的时候加上一条 【进入该配置文件】的日志，然后正常运行到 LOGS 命令之后才开始按照 LOGS 的设置进行日志生成。

[ 本帖最后由 2010qaqz111 于 2013-4-2 19:03 编辑 ]

mdyblog

HELP 支持 （循环）模糊搜索文本。如图


HELP 支持模糊书签
   HELP CALCABC
   HELP CALXXX   都 对应  SWIN  


HELP 支持 模糊查询，直达某字符串
格式： HELP ~字符串[.]
.表示不表格对齐。
如：
HELP    ~命令群.

DATE   变量名 Counter
  返回 高精度计时

DATE 变量名 Freq
返回 高精度计时 的频率

DATE   变量名 子项1   子项2  子项3  子项4 ...     //可以多个子项

DATE &V Freq  Counter
MESS %&V%
// 2241044 441890012501

[ 本帖最后由 mdyblog 于 2013-4-2 22:49 编辑 ]

mdyblog

原帖由 2010qaqz111 于 2013-4-2 19:02 发表
那么给 --clone 增加一个 --logs 开关如何？让进程在 fork 的时候视为在 LOAD 的配置文件最开始插入了一条 LOGS 命令，这个参数不知是否可以从父进程传递到子进程，如果可以的话应该就没问题，因为 --logs 可 ...

克隆方式支持 --logs: 开关

EXEC --logs:?*y2.%__PID%.log  --clone:&CMD AA BB CC

? 为： 此时已打开LOGS 时， 才有效（即继承）。

进入脚本：

线程ID\t高精度计数\t[进入配置文件:文件名]

退出脚本：

线程ID\t高精度计数\t[完成配置文件:文件名]


好复杂啊。

1. 1592 445896495093 [进入配置文件:D:\MDY\DESKTOP\Test\y2.WCS]
   
2. 1592 445896497415 [LOGS *X.LOG] <0> :操作成功完成。
   
3. 1592 445896497602 [ENVI &&&ENVIMODE=1] <0> :操作成功完成。
   
4. 1592 445896497646 [ENVI &&&FORCELOCAL=1] <0> :操作成功完成。
   
5. 1592 445896497667 [TEAM ENVI &&&ENVIMODE=1| ENVI &&&FORCELOCAL=1] <0> :操作成功完成。
   
6. 1592 445896497714 [SET &CMD=MESS ----] <0> :操作成功完成。
   
7. 1592 445896514782 [EXEC --logs:?*y2.4120.log  --clone:&CMD AA BB CC] <0> :操作成功完成。
   
8. 1592 445896515042 [SET  ::WM_LBUTTONDOWN                  =0x0201] <0> :操作成功完成。
   
9. 1592 445896521787 [ENVI @this.MSG=0x0201::wp,lp,MESS- HELLO wp=[],lp=[]@#OK] <0> :操作成功完成。
   
10. 1592 445902060118 [WIN1] <0> :操作成功完成。
    
11. 1592 445902064593 [完成配置文件:D:\MDY\DESKTOP\Test\y2.WCS]
    
12. 1592 445902065915 [完成配置文件:]

复制代码

1. 5968 446056559815 [进入配置文件:D:\MDY\DESKTOP\Test\*map:268:20]
   
2. 5968 446056562136 [LOGS *y2.4120.log] <0> :操作成功完成。
   
3. 5968 446058554371 [MESS ----] <0> :操作成功完成。
   
4. 5968 446058555995 [完成配置文件:*map:268:20]
   
5. 5968 446058557048 [完成配置文件:]

复制代码

[ 本帖最后由 mdyblog 于 2013-4-2 23:20 编辑 ]

2010qaqz111

线程ID\t高精度计数\t[命令信息]

这个“高精度计数”是返回的 QueryPerformanceCounter 的值还是时间？如果是 counter 值的话也许有些不直观，其实用 uptime 就很好。

复杂指？
如果是 LOGS 格式的话，那就除了原来只有[命令]的格式之外不规定任何格式吧，给一个自定义格式，像 sprintf 之类，自己选择线程ID uptime CurFile之类的组件自己拼去。

实现起来很复杂的话就算了，毕竟也有其他手段可以代替，这个功能的复杂化说到底也并不是必须的。

2010qaqz111

噢，你是说输出的日志看起来变复杂了。

这个其实不妨碍，毕竟做性能分析本来就涉及很复杂的数据阅读过程，不过这么看起来的话，要不就默认保持原来的格式不变，要更复杂的信息加开关自己组装输出格式，这样就符合 keep it simple 的原则了又能满足更复杂的需求。

复杂日志的分析一般都有一套专门的工具来做，像这样用制表或者其它字符分隔开的简易 LOG 因为有 EXCEL 这种现成工具可以利用，所以还算是性价比比较好的：）

[ 本帖最后由 2010qaqz111 于 2013-4-2 23:32 编辑 ]

mdyblog

原帖由 2010qaqz111 于 2013-4-2 23:28 发表
噢，你是说输出的日志看起来变复杂了。

这个其实不妨碍，毕竟做性能分析本来就涉及很复杂的数据阅读过程，不过这么看起来的话，要不就默认保持原来的格式不变，要更复杂的信息加开关自己组装输出格式，这样就 ...

不是。 是说 添加的程序代码、 改了好半天。
日志不复杂。 比程序简单多了， 比 脚本简单多了。

mdyblog

原帖由 2010qaqz111 于 2013-4-2 23:23 发表
线程ID\t高精度计数\t[命令信息]

这个“高精度计数”是返回的 QueryPerformanceCounter 的值还是时间？如果是 counter 值的话也许有些不直观，其实用 uptime 就很好。

复杂指？
如果是 LOGS 格式的话，那 ...

是 QueryPerformanceCounter。

uptime  精度不够。 我试过。 好多行的  uptime  都一样。
DATE  Freq  可以知道 其计数 频率。  

2010qaqz111

原帖由 mdyblog 于 2013-4-2 23:31 发表

不是。 是说 添加的程序代码、 改了好半天。
日志不复杂。 比程序简单多了， 比 脚本简单多了。

呵呵，辛苦了。
刚才我翻了下这个帖子前面的回复，从12年初一直坚持改进到现在，不容易啊。
我在坛子里也找过很多 PE，其中许多都是用的新版 PECMD 了，阁下的威力无处不在，哈哈。

2010qaqz111

原帖由 mdyblog 于 2013-4-2 23:35 发表

是 QueryPerformanceCounter。

uptime  精度不够。 我试过。 好多行的  uptime  都一样。
DATE  Freq  可以知道 其计数 频率。   

对的，我之前用 WRIT 写文件名的时候也是出现这个问题，而且因为是文件系统自己排序，很多顺序给颠倒了。所以如果能自己组装输出格式的话，我想 uptime.hpcounter这样的格式应该能够同时应付直观和精度两方面的问题。

又或者加上一个高精度的直观时间，以 PECMD 启动或者遇到 LOGS 命令算起，计算出一个高精度的时间来，毫秒微妙纳秒为单位都可以，小数点后的数据长度留够，格式化成统一长度。不过每行命令增加一次的除法运算不知道会不会对性能造成明显的负担。

mdyblog

原帖由 2010qaqz111 于 2013-4-2 23:42 发表

对的，我之前用 WRIT 写文件名的时候也是出现这个问题，而且因为是文件系统自己排序，很多顺序给颠倒了。所以如果能自己组装输出格式的话，我想 uptime.hpcounter这样的格式应该能够同时应付直观和精度两方面 ...

以纳秒 为单位。 （10^-9秒)再 带3位小数。
LOAD 开关（适用于 各种格式 ： FILE 和 **MEM   ##内部脚本ID）：
┃    │    │//开关 **logs:【*】log文件名]  //                                                             ┃
┃    │    │//开关 **Local  //Forcelocal=1模式                                                          ┃
┃    │    │//开关 **EnviMode  //EnviMode=1模式                                                         ┃


[ 本帖最后由 mdyblog 于 2013-4-3 08:53 编辑 ]

2011hwo1

原帖由 mdyblog 于 2013-4-2 19:30 发表
HELP 支持 （循环）模糊搜索文本。如图
158862

HELP 支持模糊书签
   HELP CALCABC
   HELP CALXXX   都 对应  SWIN  


HELP 支持 模糊查询，直达某字符串
格式： HELP ~字符串[.]
.表示不表格对齐 ...

我电脑的时钟频率是3579545hz,你的电脑时钟的频率是2241044hz?
结果测试不关是uptime不准确,utc时间一样的是不准确率,大概是精确到15ms,不知道能不能让utc时间也能提高精度

2011hwo1

原帖由 mdyblog 于 2013-4-3 00:56 发表
以纳秒 为单位。 （10^-9秒)再 带3位小数。

这所的是Counter计数所代表的最小时间单位吗?
就我的电脑时钟的周期是3579545,也就是说1个时钟的周期是1/3579545=2.79e-7,就是27.9us,不可能精确到10^-9秒秒的,最多是2.79*10^-7秒
如果你的电脑时钟的周期是2241044那精度会更低的,为1/2241044=4.46e-7秒

2011hwo1

不知道utc时间的精度能提高吗

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:42 发表

这所的是Counter计数所代表的最小时间单位吗?
就我的电脑时钟的周期是3579545,也就是说1个时钟的周期是1/3579545=2.79e-7,就是27.9us,不可能精确到10^-9秒秒的,最多是2.79*10^-7秒
如果你的电脑时钟的周期是 ...

是 4.46e-7秒

只是 为了输出 易理解的 单位， 只能 us ns 皮s

实际进度和计算机发展有关， 所以选一个 小点的单位， 能多用一段时间。 如此而已。

2011hwo1

utc时间只能精确到15ms,uptime大概精确度也是15ms,不知道能提高精度吗

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:42 发表
不知道utc时间的精度能提高吗

UTC 只是个标准形式， 以0.1us为单位。 实际的数值， 取决于计算机系统。
精度高不过 Counter 。
也别太计较了。 windwos 是非实时系统。 一个系统调用， 可能都要1us,  因此 就这样吧。
一次任务调度 引起 的误差 好多ms.

最准的就是Counter 了。


UTC 和uptime  用的是   软件系统的值。
系统软件的值， 精度为 1ms (或10ms ).
远不及  Counter 。 Counter  可达 0.5us。

[ 本帖最后由 mdyblog 于 2013-4-3 14:26 编辑 ]

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:56 发表
utc时间只能精确到15ms,uptime大概精确度也是15ms,不知道能提高精度吗

》》 utc时间只能精确到15ms,uptime大概精确度也是15ms
怎么测出来的？

2011hwo1

就是多次运行date utc uptime命令来查看变化,可以得出
_sub b1
date a3 %1
_end
date a1 utc
date a2 uptime
set a=0
set b=0
loop %a%=0,team call b1 utc|calc #a=(%a3%-%a1%)/10
loop %b%=0,team call b1 uptime|calc b=%a3%-%a2%
mess utc精度为%a%us\nuptime精度为%b%ms
//utc精度为15625us
//uptime精度为15ms

2011hwo1

upc和uptime精度为1/64秒

mdyblog

原帖由 2011hwo1 于 2013-4-3 14:50 发表
upc和uptime精度为1/64秒

utc和uptime 没这么粗糙， 用VC测试， 都是1ms精度。

你的测试程序 太复杂。 中间主要是 程序运行时间和整个系统运行时间。

UTC  已改为COUNTER 来实现，可达 0.5us精度（实际Counter决定）。
uptime  本来单位就为1ms ，受此限制, 所以提高不了。
为此增加了  uptimens  ,单位为ns.  可达 0.5us精度（实际Counter决定）。

脚本中达不到本来精度间隔，因为中间还有运行时间。     但作为计时刻度， 精度还是高的好。

mdyblog

原帖由 2011hwo1 于 2013-4-3 14:50 发表
upc和uptime精度为1/64秒

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.0036ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us               //精度1ms
// uptime精度为16000us 平均0.008ms 7.8us //精度16ms 大概1/64秒

time_test.WCS：
//LOGS *X.log
TEAM ENVI^ ENVIMODE=1| ENVI^ FORCELOCAL=1
_sub Tutc *
   date a3 utc
   date a4 utc
   CALC  #e= %a4% - %a3%
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end
_sub Tuptime *
   date a3 uptime
   date a4 uptime
   CALC  #e= %a4% - %a3%
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end

_sub Tuptimens *
   date a3 uptimens
   date a4 uptimens
   CALC  #e= %a4% - %a3%  
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end

SET &a=| SET &d=| SET &a3=| SET &a4=| SET &m=| SET &e=

TEAM set d=0| set a=10000| SET m=999999999
loop #%a%>0,team call Tutc  | CALC #a=%a% - 1
CALC jam=%m%  / 10#01
CALC #ja= %d% / 100000   //0.1us=>us

TEAM set d=0| set a=10000| SET m=9999999999
loop #%a%>0,team call Tuptime | CALC #a=%a% - 1
CALC jbm=%m% * 1000
CALC jbus= %d% / 10##01   //ms=>us
CALC jbms= %d% / 10000##04   //ms

TEAM set d=0| set a=10000| SET m=9999999999
loop #%a%>0,team call Tuptimens | CALC #a=%a% - 1
CALC jcm=%m%  / 1000##03
CALC jc= %d%   / 10000000##06   //ns=>us

mess  utc精度为%jam%us  平均%ja%us  \n uptime精度为%jbm%us 平均%jbms%ms %jbus%us  \n uptimens精度为%jcm%us  平均%jc%us   


[ 本帖最后由 mdyblog 于 2013-4-4 02:08 编辑 ]

2011hwo1

原帖由 mdyblog 于 2013-4-3 16:10 发表

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.004ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us       ...

经过测试得到:
旧版:
utc精度为15625us  平均15us  
uptime精度为0us 平均156.250ms 156250.0us
新版
utc精度为11.5us  平均12us  
uptime精度为1000us 平均0.011ms 11.4us
uptimens精度为13.409us  平均13.523842us

2011hwo1

原帖由 mdyblog 于 2013-4-3 16:10 发表

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.004ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us       ...

IFEX $%e%>%m, SET m=%e%
应该是IFEX $%e%>%m%, SET m=%e%吧
新版测试结果为:
utc精度为588.1us  平均11us  
uptime精度为1000us 平均0.012ms 12.2us
uptimens精度为522.133us  平均13.999964us
旧版结果为:
utc精度为15625us  平均20us  
uptime精度为0us 平均203.125ms 203125.0us
uptimens精度为0.000us  平均0.203125us

mdyblog

原帖由 2011hwo1 于 2013-4-3 17:58 发表

IFEX $%e%>%m, SET m=%e%
应该是IFEX $%e%>%m%, SET m=%e%吧
新版测试结果为:
utc精度为588.1us  平均11us  
uptime精度为1000us 平均0.012ms 12.2us
uptimens精度为522.133us  平均13.999964us
旧 ...

是的， 上面已改了。
要多测几次， 再最小结果， 就是 实际精度。 上面已经取了1000次的最大值。 所以多测几次，再取最小值。
这样出去系统的干扰。
中间碰到系统的任务切换、磁盘调度、内存调度，中间插入别的任务， 就会变得很大， 1000次碰到一次的几率不小啊。 很大的值基本上都忽略掉，再测。
测得：
utc精度为23.6us  平均4us  
uptime精度为1000us 平均0.004ms 3.6us  
uptimens精度为18.295us  平均4.254294us
估计在PE下测试， 稳定点。没那么多调度的。

[ 本帖最后由 mdyblog 于 2013-4-3 18:12 编辑 ]

mdyblog

DATE 加了个 *us 开关 在毫秒后加4为小数。达到UTC 的精度
date *us *space &V
MESS %&V%
// 2013 4 3 3 18 15 41 342.0130