Windows 性能调优的资源建议(实时)

发布于 2024-09-24 20:07:48 字数 233 浏览 0 评论 0原文

对于 Windows 应用程序调整资源(书籍网站等)有什么建议吗?

我有一个 C++ 控制台应用程序,需要以相当高的速率向硬件设备提供大量数据。 (缓冲区大小为 32K,每秒消耗约 800k 字节)

它将流式传输数据而不会运行不足,除非我执行文件 IO(如打开文件夹等)...(它似乎勉强满足其计时要求)。

不管怎样..一本好书或资源来温习 Windows 的实时性能会很有帮助。

谢谢!

Any recommendations out there for Windows application tuning resources (books web sites etc.)?

I have a C++ console application that needs to feed a hardware device with a considerable amount of data at a fairly high rate. (buffer is 32K in size and gets consumed at ~800k bytes per second)

It will stream data without under runs, except when I perform file IO like opening a folder etc... (It seems to be marginally meeting its timing requirements).

Anyway.. a good book or resource to brush up on realtime performance with windows would be helpful.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

半岛未凉 2024-10-01 20:07:48

您对商用 Windows 所能期望的最好结果是“通常满足时序要求”。如果系统正在运行目标应用程序以外的任何进程,它偶尔会由于调度不一致而错过最后期限。但是,如果您的应用程序/硬件可以处理罕见但偶尔的失误,您可以采取一些措施来减少失误次数。

  1. 将进程的优先级设置为 REALTIME_PRIORITY_CLASS
  2. 通过 timeBeginPeriod() 函数(Windows 多媒体库的一部分)将调度程序的粒度更改为 1 毫秒
  3. 避免主循环中尽可能多的系统调用(这包括分配内存) )。每个系统调用都是操作系统让进程进入睡眠状态的机会,因此,也是非确定性调度程序错过下一个截止日期的机会

如果这不能为您完成工作,您可能会考虑尝试 Linux应用了实时内核补丁的发行版。我发现它们可以提供近乎完美的计时(在几个小时的过程中精度在 10 微秒以内)。也就是说,真正的实时操作系统实际上不会给您带来完美,但实时 Linux 发行版比商用 Windows 更接近。

The best you can hope for on commodity Windows is "usually meets timing requirements". If the system is running any processes other than your target app, it will occasionally miss deadlines due scheduling inconsistencies. However, if your app/hardware can handle the rare but occasional misses, there are a few things you can do to reduce the number of misses.

  1. Set your process's priority to REALTIME_PRIORITY_CLASS
  2. Change the scheduler's granularity to 1ms resolution via the timeBeginPeriod() function (part of the Windows Multimedia libraries)
  3. Avoid as many system calls in your main loop as possible (this includes allocating memory). Each syscall is an opportunity for the OS to put the process to sleep and, consequently, is an opportunity for the non-deterministic scheduler to miss the next deadline

If this doesn't get the job done for you, you might consider trying a Linux distribution with realtime kernel patches applied. I've found those to provide near-perfect timing (within 10s of microseconds accuracy over the course of several hours). That said, nothing short of a true-realtime OS will actually give you perfection but the realtime-linux distros are much closer than commodity Windows.

闻呓 2024-10-01 20:07:48

我要做的第一件事就是将其调整到尽可能精简的位置。 我使用这种方法。 由于这些原因。由于它是一个控制台应用程序,另一个选择是尝试< a href="http://www.lw-tech.com/" rel="nofollow noreferrer">LTProf,它将向您显示是否有任何可以有效优化的内容。完成后,您将处于寻找缓冲区计时问题的最佳位置,正如 @Hans 所建议的那样。

The first thing I would do is tune it to where it's as lean as possible. I use this method. For these reasons. Since it's a console app, another option is to try out LTProf, which will show you if there is anything you can fruitfully optimize. When that's done, you will be in the best position to look for buffer timing issues, as @Hans suggested.

澉约 2024-10-01 20:07:48

优化 C++ 软件,来自 agner.com 是一本很棒的优化手册。

正如 Rakis 所说,您需要非常在处理循环中小心:

  • 没有内存分配。请改用堆栈和预分配内存。
  • 没有投掷。异常是相当昂贵的,在 win32 中,即使不抛出异常也会产生成本。
  • 无多态性。您将节省一些间接。
  • 广泛使用内联。
  • 没有锁。尽可能尝试无锁方法。

Optimizing software in C++ from agner.com is a great optimization manual.

As Rakis said, you will need to be very careful in the processing loop:

  • No memory allocation. Use the stack and preallocated memory instead.
  • No throws. Exceptions are quite expensive, in win32 they have a cost even not throwing.
  • No polymorphism. You will save some indirections.
  • Use inline extensively.
  • No locks. Try lock-free approaches when possible.
愁以何悠 2024-10-01 20:07:48

缓冲区仅持续 40 毫秒。在具有如此严格的时序要求的 Windows 上,您无法保证零欠运行。在用户模式领域,当内核线程执行其需要执行的操作时,您可能会看到数百毫秒的时间。它们以您可以获得的更高优先级运行。工作站版本上的线程量子是时钟周期的 3 倍,已经超过 40 毫秒 (3 x 15.625 毫秒)。您甚至无法可靠地与提高优先级并享受美好时光的用户模式线程竞争。

如果无法选择更大的缓冲区,那么您正在寻找设备驱动程序来获得这种服务保证。或者介于两者之间可以提供更大缓冲区的东西。

The buffer will last for only 40 milliseconds. You can't guarantee zero under-runs on Windows with such strict timing requirements. In user mode land, you are looking at, potentially, hundreds of milliseconds when kernel threads do what they need to do. They run with higher priorities that you can ever gain. The thread quantum on the workstation version is 3 times the clock tick, already beyond 40 milliseconds (3 x 15.625 msec). You can't even reliably compete with user mode threads that boosted their priority and take their sweet old time.

If a bigger buffer is not an option then you are looking at a device driver to get this kind of service guarantee. Or something in between that can provide a larger buffer.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文