受VCL影响的基准化 [英] Benchmarking affected by VCL

问题描述

今天我移植了旧的内存基准测试

Today I ported my old memory benchmark

从 Borland C ++ Builder 5.0 到 BDS2006 Turbo C ++ ，发现了奇怪的东西.

from Borland C++ builder 5.0 to BDS2006 Turbo C++ and found out weird thing.

BCB5 中的
• exe运行正常且稳定
BDS2006 中的
• exe仅在启动主窗体之前(在其构造函数内部)并且在主窗体为Activated之后甚至在任何 VCL之后再次启动基准测试，都可以确定为正常". strong>组件更改(例如主窗体的Caption)，则基准线程的速度会受到很大影响.

• exe from BCB5 runs OK and stable
• exe from BDS2006 measure OK only before main Form is started (inside its constructor) and if the benchmark is started again after main form is Activated or even after any VCL component change (for example Caption of main form) then the speed of benchmark thread is strongly affected.

经过研究，我发现:

• 如果测试不在线程内，则不起作用.
• 进程/线程的优先级，亲和力也不会对此造成影响.
• 任何窗口(Visibility,Enabled)的隐藏都不会对此造成影响.
• 调用测试表OnIdleEvent不会对此造成影响
如果时间是用RDTSC或PerformanceCounter 测量的，则
• 不重要

• Does not mater if test is inside thread or not.
• The process/thread priority,affinity does not affect this either.
• Hide of any window (Visibility,Enabled) does not affect this.
• call the test form OnIdleEvent does not affect this
• does not mater if time is measured by RDTSC or PerformanceCounter

我的结论是 VCL 库在后台运行一些代码/线程，所以我的问题是:

My conclusion is that VCL library runs some code/thread on the background so my questions are:

1. 是否可以暂时暂停VCL代码/填充?

理想的是Application->Pause();和Application->Resume();之类的东西，或者仅仅是Forms.

ideal something like Application->Pause(); and Application->Resume(); or just Forms.

还有什么可能导致这种现象以及如何避免这种现象?

PS.

测试应用程序除主表单外没有其他 VCL 组件.基准测试只是通过rep stosd进行的具有不同块大小的少量内存传输(没有有趣的内容).来源在此相关的问题/答案中.我知道 BDS2006 已经过时，但是我现在不打算升级，因此请跳过有关它们根本无法满足要求的任何评论.

Test application has no VCL components other than main form. Benchmark is just a few memory transfers by rep stosd with different block sizes (no funny stuff). Source is in this related Q/A. I know BDS2006 is out-dated but I am not looking for upgrade right now so please skip any comments about that they are not help-full at all.

在 Windows7 pro x64 ，32bit应用程序

推荐答案

我在 BDS2006 :: VCL invalidates CACHE s中发现了wndproc./p>

I found out that wndproc in BDS2006::VCL invalidates CACHEs.

1. 我尝试用winapi

1. I have tried to override wndproc by winapi

很简单，但是不会停止Form的消息处理.当我尝试Form1->Handle作为窗口时，会出现error 1400(无效的窗口句柄)

for Application->Handle is this easy but it does not stop the processing of messages for Form. When I tried Form1->Handle as window then error 1400 occurs (not valid window handle)

我尝试通过VCL覆盖wndproc

I have tried to override wndproc by VCL

用于TApplication events的应用程序，以及Form通过覆盖虚拟wndproc成员的Form.消息处理停止了，但是它们的调用顺序仍然存在，问题也没有解决.

for Application by TApplication events and for Form by override of virtual wndproc member. Message processing stops but their calling sequences remains and the problem is not solved either.

因此，在消除了所有可能思考的可能性之后，我得出的结论是，在设置基准测试的进程/线程之后，我需要以某种方式更深入地冲洗 CACHE .

So my conclusion after eliminating every possibility I can think off is that I need to flush CACHE more intensively somehow after setting process/thread for benchmarking.

在 DOS 中，我可以通过一条指令完成操作，但是在 windows 上则比较棘手.好吧，以前版本的内存基准测试仅使用内存填充，对于 BDS2006 exe来说显然是不够的.我认为 CACHE 指令涉及此问题，而不是数据缓存，因此我对其进行了一些更改，终于解决了问题.

In DOS I would done it by single instruction but on windows it is more tricky. Well The previous version of memory benchmark used just memory filling which is obviously not enough for BDS2006 exe. I think that instruction CACHE is involved in this problem not data cache so I change it a bit and it finally worked thing out.

刷新CPU缓存:

for (DWORD i=0;i<(128<<20);i+=7)
    {
    dat[i]+=i;
    dat[i]*=i;
    dat[i]&=i;
    }

为dat 128MB分配的内存块(或更大)，并且必须在所有进程/线程优先级和亲和力更改或基准测试之前的所有 winapi 调用之后完成.

Where dat is 128MB allocated memory chunk (or bigger) and must be done after all process/thread priority and affinity changes or all winapi calls prior to benchmarking.

这篇关于受VCL影响的基准化的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！