Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: niffiwan on February 21, 2016, 05:26:05 am
-
Ages back I recall reading a tip on Bruce Dawson's blog (https://randomascii.wordpress.com/2011/07/22/visual-c-debug-buildsfast-checks-cause-5x-slowdowns/) about speeding up MSVC debug builds. I know this is currently a problem for modders as running FSO debug executables is very slow, making it hard to use debug execs for all modding. I know there's been a discussion about "fast debug" config which (IIRC) would involve optimised debugging, or essentially a MSVC release config with FSO debug, however the change Bruce suggested is super simple to make so I thought I'd give it a go as see what happened.
In your project properties go to C/C++, Code Generation, and set Basic Runtime Checks to Default. Your code will get slightly smaller, and a lot faster.
So, here's a link to some DEBUG executables built with 2015 community edition; SSE2 mode.
http://www.mediafire.com/download/z1t8w5sa5721pae/fso_fast.7z
It'd be great to have comparisons run between this and (e.g.) the nightly SSE2 builds (which might be compiled with a different version of MSVC... oh well). Note that my Windows laptop is pretty old & slow, so I don't think it'd give good test results.
Trivial diff here if anyone's interested: https://github.com/scp-fs2open/fs2open.github.com/compare/master...niffiwan:faster_debug
-
I haven't tested this yet, but I was reading the blog entry you linked and saw this:
the slowdown is triggered by a combination of Runtime Checks and Edit and Continue – disabling Edit and Continue can drastically improve debug performance.
You might also want to change the Debug Information Format to "Program Database (/Zi)" instead of "Program Database for Edit And Continue (/ZI)" (which it currently is for Debug builds)... unless it's talking about debug performance only while running the the program through VS's debugger, which isn't entirely clear to me.
-
Thanks for drawing my attention to that. It seems that it's the combo of the two that causes the slowdown. From the comments (emphasis mine)
brucedawson says:
June 3, 2015 at 9:00 am
I’m sure they’ll fix it some day… Until then, turn off the checks, or turn of (sic) edit-and-continue.
From a quick read of MSDN (https://msdn.microsoft.com/en-us/library/bcew296c%28v=vs.140%29.aspx) it seems that this feature lets you edit your program and continue to debug it without recompiling. There's limitations though so this feature seems possibly less useful than setting Basic Runtime Checks to Default, which one commenter says causes issues (https://randomascii.wordpress.com/2011/07/22/visual-c-debug-buildsfast-checks-cause-5x-slowdowns/#comment-118) in a certain game being compiled with /arch:SSE2.
Anyway, before I switch that around are there any coders that would be greatly upset at losing access to the "Edit & Continue" feature?
(ps, I've had one report via IRC that, while not hugely faster, there is some improvement with this change... although potentially mouse input events are being lost?)
-
are there any coders that would be greatly upset at losing access to the "Edit & Continue" feature?
If there are, they can always compile an Edit & Continue build themselves, but given the severe limitations (https://msdn.microsoft.com/en-us/library/0dbey757.aspx) of the feature, I'm not sure how often it's likely to even be usable.
-
I've used Edit and Continue maybe like five times and I frankly won't miss it if it's disabled by default.
-
I used to use edit and continue routinely when debugging and found it incredibly useful. It allowed me to breakpoint the code at the point where I thought the error was occurring and step through the code until I found the error. Quite often I could then add code that fixed the problem (for instance in cases where a calculation or something was missing) and then continue executing the code to see if that fixed the bug. That basically means that I don't need to shutdown FS2, recompile, and then go through all the steps to cause the bug again. In the case of hard to reproduce bugs that was invaluable.
It would be pretty annoying to lose it but if I'm the only person using it I can change things to build it myself. To be honest though I'm kinda surprised that you guys use it so little.
-
To be honest though I'm kinda surprised that you guys use it so little.
To be quite honest, I forgot it was enabled by default; that being said, I usually tend to enter the debugger after FSO has crashed rather than setting breakpoints and waiting for them to trip (which isn't to say that I've never done that, just that it's not my typical use-case); in that situation, the thing has already gone wrong (and I usually have to follow the call stack upwards and perform some manual static analysis to figure out why it went wrong) and changing it after the fact wouldn't recover the executable.
-
That's great for crashes, but I tend to have a lot of non-crash bugs to deal with.
And when you consider the amount of faffing around to reproduce a multiplayer bug, you start to see why I like it. :)
-
If you're able to set breakpoints you're able to build FSO to custom profiles. It's pretty clear that the SCP should be distributing fast debug builds, though it might well be worthwhile keeping the current ones around.
-
Well, if even one person has a use for Edit & Continue then we could stick with setting Basic Runtime Checks to Default (https://msdn.microsoft.com/en-us/library/8wtf2dfz.aspx), I just need to get back to my laptop with MSVC to see exactly what menu options all the /RTC[1csu] flags correspond to.
-
Honestly, I see no reason to have Edit and Continue active by default if it isn't useful for a majority of users. If you need it, it can be reenabled; meanwhile, let's make the experience less miserable for everyone else.
-
Sure, but if there's even less impact from setting Basic Runtime Checks to default then we may as well do that instead of disabling Edit & Continue. Either change should provide the same result (unless there's something I don't know about setting Basic Runtime Checks to Default), and yes, it seems I will need to profile this to confirm that :)
-
OK; finally got around to running some benchmarks using Artemis Station (my poor, poor underpowered laptop, mobile i5 + HD3000...). It's super easy to see which is better; the ones that have recorded the most frames per run! (and I set the last frame to zero to make it stand out where each run ended)
(http://i.imgur.com/YxRRv29.png)
It seems that:
1) Disabling either is a decent improvement over the default
2) Setting Runtime checks to Default has a slight edge over disabling Edit & Continue
Therefore I'll submit a PR shortly to set runtime checks to default, which should make it slightly less painful to run debug.
(now we just need fast-debug to be implemented; i.e. switch _DEBUG & NDEBUG in a "release" config ;))
-
Oh man... Modding is about to get so much easier.
-
What are the results if you disable both edit & continue and runtime checks? The runtime checks have caught a number of coding errors for me so it would be great to have a "Debug" configuration which would be used for development, "Fast debug" for mod development (basically release with _DEBUG and without NDEBUG) and Release modes.
The amount of work required to implement this using the current build system is obviously too much but with CMake it could be implemented fairly easily.
I would like to keep runtime checks enable if possible and disable edit & continue instead because the former actually help while developing.
-
OK; I can test what the results are with both off, give me a day or two.
-
OK, here's the graph with both changes, and there's another small improvement over just Default Runtime Checks.
(http://i.imgur.com/UFsP2YW.png)
m!m, which type of checks picked up the errors you referred to? Do you know if it was:
Stack Frames (/RTCs)
or
Uninitialised Variables (/RTCu)
I guess I could try running each of those separately to see what the differences they have?
-
I used to use edit and continue routinely when debugging and found it incredibly useful. It allowed me to breakpoint the code at the point where I thought the error was occurring and step through the code until I found the error. Quite often I could then add code that fixed the problem (for instance in cases where a calculation or something was missing) and then continue executing the code to see if that fixed the bug. That basically means that I don't need to shutdown FS2, recompile, and then go through all the steps to cause the bug again. In the case of hard to reproduce bugs that was invaluable.
It would be pretty annoying to lose it but if I'm the only person using it I can change things to build it myself. To be honest though I'm kinda surprised that you guys use it so little.
(Having only just seen this thread...)
Same here, on all counts. I typically don't need the runtime checks -- although they have come in handy on occasion -- but I use Edit & Continue fairly frequently, especially with the recent intrinsic rotation / look-at features.
-
I have implemented the "Fast debug" idea that was mentioned here in my cmake branch. That basically copies the options of the release configuration to a new "Fast Debug" configuration but also sets _DEBUG while not setting NDEBUG. That basically turns it into a release build that does the usual debug runtime checks but without disabling all the optimizations of release builds. The fast debug builds perform pretty much the same as normal release builds so mod developers won't need to sit through a slideshow just to check if there are warnings in a mission.
The "Debug" configuration could then be altered to include Edit & Continue without affecting users who don't develop code for the engine.
-
Edit and Continue, as far as I understand, requires Visual Studio and the source code of FSO to use, and therefore anyone who actually needs it is perfectly capable of building their own FSO binary with it enabled. I don't see why everyone else should take a performance hit by having it enabled in binary downloads.
-
Edit and Continue, as far as I understand, requires Visual Studio and the source code of FSO to use, and therefore anyone who actually needs it is perfectly capable of building their own FSO binary with it enabled. I don't see why everyone else should take a performance hit by having it enabled in binary downloads.
Anyone who isn't going to be building their own binary would just use Fast Debug instead.
-
To me this sounds like a pretty good case for only having one, fast debug build.
-
Fast debug is not useful for actual debugging because it optimizes a lot of stuff that is needed for stepping through the code with a debugger. The debug builds will not be needed for the nightlies but the configuration will continue to be used.
-
If you're stepping through the code with a debugger you're able to compile the code with debug symbols enabled.
-
:wtf: Of course you would compile the code using the debug symbols. That's what the Debug configuration is for. However, the binaries provided in the release and nightlies only need to be compiled for the Release and Fast Debug configurations.
-
Oh OK, I thought we were still talking about what binaries go on the download page. Yeah, obviously I see why we still need a full debug config.
-
I always wondered if the right course of action isn't having a separate debug build that isn't really a debug build, but to see if the mod checks that people use debug builds for could be toggled in a release build via a command line switch. Then those checks themselves could be present in both debug and release builds. But I'm not sure how technically feasible that is. It would probably require an overhaul of our usage of the Assertion macro.
-
I always wondered if the right course of action isn't having a separate debug build that isn't really a debug build, but to see if the mod checks that people use debug builds for could be toggled in a release build via a command line switch. Then those checks themselves could be present in both debug and release builds. But I'm not sure how technically feasible that is. It would probably require an overhaul of our usage of the Assertion macro.
I don't see why; Assertion should only be used to check for coding errors, not bad mod data.
-
Guess I got confused for a second and I'm thinking of the Warning system. Perhaps it could be modified to be sensitive to a command line option instead of a debug flag.
-
Technically, it could, but then you would lose some efficiency in release builds.
Look, we can pretty easily organize the debug builds by the type of people who will use them. I agree with AdmiralRalwood (http://www.hard-light.net/forums/index.php?topic=91557.msg1817441#msg1817441). For Nightly Builds, we need only provide Release and Fast Debug. Developers who want Edit & Continue can simply toggle that option in their local projects. It's only a minor inconvenience.