§ ¶Please stop with the background tasks
My current technique for testing A/V sync in VirtualDub is to hook my capture device up to a PlayStation 2 and then play a game of Guitar Hero 2 or Rock Band through my laptop. How poorly I do indicates how much lag there is on the real-time display. (If I do well, it means that there is possibly also a problem with the universe.) I can then play back the capture file to see how well the resync engine performs and to compare VirtualDub's preview mode against DirectShow sync. And I get to hear some decent music, too.
Imagine my surprise when I started playing the capture AVI file and Media Player Classic started stuttering horribly.
My first instinct was that maybe something had gone horribly wrong with the interleaving code or that my disk was terribly fragmented, but after bringing up FileMon it was quickly apparent that the problem was actually Visual Studio. Specifically, Visual Studio had suddenly decided that it wanted to rebuild the Intellisense database for VirtualDub, and had started thrashing the disk, which in turn completely screwed my video playback. So then I had to wait a few moments while Visual Studio took its sweet time until I could actually play video again.
I'm now of the opinion that running tasks in the background is a bad idea and contributes to the opinion that computers are slow and unpredictable. In this case, the Visual Studio programmers got the idea that Intellisense could be made low impact and "invisible" by running it as a low priority background thread, which ignores the problem that it still drains a huge amount of I/O bandwidth on the hard disk. This isn't the first time the Visual Studio team has done something like this -- I love it when the .NET Framework updates and suddenly a lot of CPU is taken up by "background" NGEN tasks for minutes at a time. If everyone did this, computers would be stuck at 100% CPU for hours at a time with no apparent reason.
We've now gotten to the point where computers are fast enough to perform many everyday computing tasks much faster than necessary, which unfortunately has given rise to the opinion that we don't need efficient code anymore. While it's true that there's no need to make a window come up in 0.5ms when it currently comes up in 5ms, I think the recent trend toward low-power, quieter, and lighter-weight devices is providing a new reason for efficient code. For many programs, it'll no longer be about making the program run faster, but to make it run more efficiently, letting the CPU and GPU idle more, allowing the hard drive and fans to spin down, and prolonging battery life on laptops. This is nothing new to people who worked on older platforms or on mobile devices, but this kind of thinking isn't as common in the desktop world. Heck, in the DOS days there wasn't even a way to idle the CPU... well, unless you cared about Windows 3.1 and issued the obscure INT 2F/AX=1607/BX=0018.
Now, whether people will actually care about this, I don't know. The current trend on Windows toward rendering everything in a UI every frame and/or in software rendering isn't heartening, and "efficient operation for prolonged battery life" isn't something I normally see as a bullet point in program advertisements. With the rate of hardware advancement slowing and the rise of lower powered "netbook" devices like the Asus Eee, though, I'm hoping to see a bit of a reversal here. I don't need my laptop to run hotter than it already does.
It also randomly locks up the IDE, it's still as horribly slow as it's been since VC7 or so, and the disk thrashing is so distracting I can't do anything that I might be trying to do in VC to begin with. The feature isn't even close to worth the bother, but they don't include any way to turn it off, short of messing with DLLs directly. It should be integrated into the compiler--have the brunt work done during compilation, where everything is probably being done anyway (and forget about updating data types immediately).
I don't care if programs run idle tasks that take CPU, as long as it's actually useful, runs in low priority, and can be disabled for power-sensitive environments (better still: automatically disable if running on laptop/UPS battery). My Q9300 has more CPU than I use most of the time. I do care if they hit the disk, especially if it's not triggered by something I did. Aside from the fact that disk I/O can't be prioritized as cleanly as CPU activity (any disk access is going to slow down interactive access), nothing's more annoying than having an idle machine suddenly decide to start reading from the disk.
I'm pretty sure Windows does I/O prioritization--if the Intellisense update is happening in a low-priority thread, the video output should take priority. I don't know if that thread doesn't set its priority properly, or if this just doesn't work well enough.
Glenn Maynard - 24 08 08 - 19:51
Microsoft used to generate information from the compiler -- it was called browse info. That seems dead and buried at this point. I should note that it's not actually that easy, because Intellisense is expected to return useful data from files that don't even come close to compiling, whereas the compiler is expected not to spew 2MB of errors because you forgot a semicolon.
The disk situation is worse than I describe if you have multiple solutions open that have the same project, like a base static lib, and you edit a file in that project. In that case, ALL of the instances of Visual Studio will update Intellisense concurrently! I bugged this on Connect and the VS team didn't seem to care that it was possible to consistently bring a machine to its knees this way.
If you have installed the Intellisense hotfixes, then you can supposedly enable and disable the update via an obscure macro: http://blogs.msdn.com/vcblog/archive/200..
When I work on larger projects I just rename FEACP.DLL, though, and on smaller projects the updating isn't usually as much of a problem. VirtualDub's getting big enough that the update takes a couple of minutes, though, which is annoying.
Windows XP doesn't do any I/O prioritization and a fairly piss poor job of I/O scheduling. Windows Vista does do I/O scheduling, but I think it's a new flag you have to specify on the process/thread. I don't know if Visual Studio actually does this. Intellisense does run on a low priority thread, but that wouldn't have done squat anyway since I have a dual core CPU. It's also unclear whether Vista is able to keep seek traffic from low-priority threads to a minimum; I was playing a high-bandwidth Huffyuv file, so even moderate seek traffic is a problem. I/O reservation probably would have worked, though.
Phaeron - 24 08 08 - 20:15
I cringe when I hear "we can't fix this horrible bug, because then we couldn't fulfill this design requirement"--or put differently, when developers refuse to acknowledge something like "doesn't thrash the disk for minutes at a time" as a requirement, because they'd have to admit that they're not capable of fulfilling all of the requirements. Of course, this leads to many of those absurd "this behavior is by design" KB entries...
Glenn Maynard - 24 08 08 - 21:02
Could be partly due to insufficient granularity in the bug database -- generally the closing options all imply that the behavior is correct or incorrect. Since performance bugs are dependent upon workload and machine configuration, you can't gauge a performance bug in binary terms unless you are running specific test cases or have an egregiously bad case, like an infinite loop or close enough (projected running time exceeds the lifetime of the universe). Performance problems are thus troublesome from a project planning perspective, because there's often nothing you can point at that's definitively wrong, and the situation may not become untenable until the performance problems from several subsystems combine together to produce a generally sluggish program.
That having been said, Visual Studio could use a lot more load testing. When I can see performance problems on a 2.5GHz laptop with a program the size of VirtualDub, it's not a stretch to see that Visual Studio may have issues scaling to enterprise-class projects....
Phaeron - 24 08 08 - 21:18
On an idle machine, I can see the VS2008 find dialog render on my Q9300. The new control-tab is lagged to the point of being useless. I'm not inclined to believe they put any serious priority on IDE performance at all. (That control-tab window is absurd, too. A blurry, unreadable thumbnail of source code? Gee, thanks.)
Hey, this thing isn't changing dashes to strikeout anymore. It changes dashes to, well, dashes. A small ray of hope in this buggy universe, etc...
Glenn Maynard - 24 08 08 - 21:58
The music game snob in me insists on pointing out that Guitar Hero and Rock Band are terrible measures of input lag since both games have such huge timing windows, provide absolutely no feedback on how close to perfect timing you actually are, and have had the controllers proven to lag themselves on a hardware level (apparently because a music game with huge timing windows and no accuracy feedback doesn't require adequate input).
The author of this message would love more beatmania IIDX in the US and wished the attempt to bring it over didn't both suck horribly and sell horribly.
StarCreator (link) - 25 08 08 - 01:07
Oh sure, that's why I can manage to pass any songs at all. But hey, you know what? I like it better this way. I hated the timing perfectionism that DDR constantly pushed for.
I should note that we're not exactly talking about small errors here, though, at least when it comes to the display latency. At a minimum you're looking at 2.5 field times of delay relative to a plain old TV, two from the capture device to acquire a "frame" and another ~0.5 on average due to timing offset between the PS2 output and the computer display. Add another 1-2 frames for Direct3D buffering and you've easily got something that any player will notice. The Rock Band calibration meter measured 50-70ms of latency on VirtualDub's capture display, which is a lot. Fortunately, the captured video was largely OK. I hear that the next versions of Rock Band and Guitar Hero will have calibration sensors in the guitars, which I look forward to abusing.
By the way, this is why I think that putting "play games on your computer!!!!" on a capture card box is a bogus claim. As long as you've got a capture driver that can only hand you frames, you're lost too much motion fidelity and have too much latency to play most action games. A 60 fields/sec game like RB or GH2 looks like a complete mess in standard frame display. I do tricks in some of VirtualDub's display modes to show fields, but the latency is only good for non-action games and trying to get stable timing on Windows is a bear. You'd have to get _fields_ out of the capture driver in order to have a shot at a good display, and I know of no device that actually supports this on Windows. If anyone knows a somewhat inexpensive device that actually does support field delivery via VIDEOINFOHEADER2, I'd be very interested.
Phaeron - 25 08 08 - 02:14
"Heck, in the DOS days there wasn't even a way to idle the CPU... well, unless you cared about Windows 3.1 and issued the obscure INT 2F/AX=1607/BX=0018."
More common was INT 2F/AX=1680 and also common was INT 28.
Yuhong Bao - 25 08 08 - 02:14
INT 2F/AX=1680 sounds familiar and was probably the one I actually used... it's been so long that I had to go search for the interrupt call. Actually, now that I think about it, it would have been Windows 95. I'm not even sure that my old paint program ran in Windows 3.1, being 386 extended.
Phaeron - 25 08 08 - 02:17
"Iím not even sure that my old paint program ran in Windows 3.1, being 386 extended."
What do you mean by this? Do you mean Win32 or just 32-bit instructions?
Yuhong Bao - 25 08 08 - 02:29
"itís been so long that I had to go search for the interrupt call. "
The Ralf Brown Interrupt List is online and can be downloaded. Google for it.
Yuhong Bao - 25 08 08 - 02:30
It was a DOS program running in 32-bit protected mode -- under DOS/4GW or PMODE/W, to be exact. And saying to look through the Ralf Brown list is like saying to look up things in an unabridged dictionary.
By the way, don't take this the wrong way, but you should reduce your posting rate or at least try to consolidate your replies. You're commenting on a lot of fairly minor points. I'm not Raymond Chen and won't pick on you in the main posts, but you should focus more on the main topic.
Phaeron - 25 08 08 - 02:55
On the topic of Vista I/O scheduling, I've noticed for some time now that in Process Explorer, VirtualDub's default I/O priority (listed separately from CPU priority) is listed as "Background" rather than "Normal". Is this expected? For me sync isn't such a problem though since I capture to a separate hard disk.
earn - 25 08 08 - 03:38
I got 30ms of delay with Guitar Hero 3 and a recent LCD TV, which works out at 1.5 fields (50Hz PAL). I wonder how much of that is reaction time/console lag, and how much is actual processing delay in the TV? Unfortuantly I don't have my old CRT TV around to compare.
People do seem to have just stopped bothering with optimisation of any sort. I think the one that surprised me recently was multiplexing a MPEG2 audio and video stream together, with the output file on a USB hard disk. The program was writing in stupidly small chunks, such that it was significantly faster to store the output file on a faster local disk and then copy it afterwards with explorer.
Torkell (link) - 25 08 08 - 05:51
Writing in large chunks is good practice if you're writing a lot of data, but this one's probably Windows's fault: as of XP, it defaults to synchronous writes to USB drives, which makes them uselessly slow. You can turn it back on (don't recall where off-hand). I guess people were pulling USB drives without dismounting them, and crippling drives was their fix.
Probably at least a frame of delay is the TV's fault, probably all of it.
Glenn Maynard - 25 08 08 - 15:34
To follow up on my comment, since I have VirtualDub (1.85) doing a capture right now. Under Process Explorer, opening up the VirtualDub thread list, the subthreads have Base and Dynamic Priorities ranging from 13-15 (which I assume is in the "High" range), and Memory Priorities of 3. Yet all their I/O Priorities are set to "Low". When running Vdub under Vista, in cases of high disk activity from multitasking, etc, it would be great if I/O Priority could be also set to high - that way when doing other activities on the same disk (starting programs, etc) during high-throughput capture, frames wouldn't start dropping like crazy as they do under Vista.
earn - 26 08 08 - 04:00
"It was a DOS program running in 32-bit protected modeóunder DOS/4GW or PMODE/W, to be exact."
Then it should run in Windows 3.1.
Yuhong Bao - 27 08 08 - 16:00