Author Topic: Possible Faster Debug  (Read 8727 times)

0 Members and 1 Guest are viewing this topic.

Offline niffiwan

  • 211
  • Eluder Class
Ages back I recall reading a tip on Bruce Dawson's blog 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.

Quote
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
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
I haven't tested this yet, but I was reading the blog entry you linked and saw this:
Quote
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.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline niffiwan

  • 211
  • Eluder Class
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 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 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?)
« Last Edit: February 22, 2016, 03:31:53 pm by niffiwan »
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
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 of the feature, I'm not sure how often it's likely to even be usable.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline Swifty

  • 210
  • I reject your fantasy & substitute my own
I've used Edit and Continue maybe like five times and I frankly won't miss it if it's disabled by default.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
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.
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 

Offline AdmiralRalwood

  • 211
  • The Cthulhu programmer himself!
    • Skype
    • Steam
    • Twitter
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.
Ph'nglui mglw'nafh Codethulhu GitHub wgah'nagl fhtagn.

schrödinbug (noun) - a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.

When you gaze long into BMPMAN, BMPMAN also gazes into you.

"I am one of the best FREDders on Earth" -General Battuta

<Aesaar> literary criticism is vladimir putin

<MageKing17> "There's probably a reason the code is the way it is" is a very dangerous line of thought. :P
<MageKing17> Because the "reason" often turns out to be "nobody noticed it was wrong".
(the very next day)
<MageKing17> this ****ing code did it to me again
<MageKing17> "That doesn't really make sense to me, but I'll assume it was being done for a reason."
<MageKing17> **** ME
<MageKing17> THE REASON IS PEOPLE ARE STUPID
<MageKing17> ESPECIALLY ME

<MageKing17> God damn, I do not understand how this is breaking.
<MageKing17> Everything points to "this should work fine", and yet it's clearly not working.
<MjnMixael> 2 hours later... "God damn, how did this ever work at all?!"
(...)
<MageKing17> so
<MageKing17> more than two hours
<MageKing17> but once again we have reached the inevitable conclusion
<MageKing17> How did this code ever work in the first place!?

<@The_E> Welcome to OpenGL, where standards compliance is optional, and error reporting inconsistent

<MageKing17> It was all working perfectly until I actually tried it on an actual mission.

<IronWorks> I am useful for FSO stuff again. This is a red-letter day!
* z64555 erases "Thursday" and rewrites it in red ink

<MageKing17> TIL the entire homing code is held up by shoestrings and duct tape, basically.

 

Offline karajorma

  • King Louie - Jungle VIP
  • Administrator
  • 214
    • Karajorma's Freespace FAQ
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. :)
Karajorma's Freespace FAQ. It's almost like asking me yourself.

[ Diaspora ] - [ Seeds Of Rebellion ] - [ Mind Games ]

 
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.
The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell.

 

Offline niffiwan

  • 211
  • Eluder Class
Well, if even one person has a use for Edit & Continue then we could stick with setting Basic Runtime Checks to Default, I just need to get back to my laptop with MSVC to see exactly what menu options all the /RTC[1csu] flags correspond to.
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline The E

  • He's Ebeneezer Goode
  • Moderator
  • 213
  • Nothing personal, just tech support.
    • Steam
    • Twitter
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.
If I'm just aching this can't go on
I came from chasing dreams to feel alone
There must be changes, miss to feel strong
I really need lifе to touch me
--Evergrey, Where August Mourns

 

Offline niffiwan

  • 211
  • Eluder Class
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 :)
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Possible Faster Debug
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)



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 ;))
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline mjn.mixael

  • Cutscene Master
  • 212
  • Chopped liver
    • Steam
    • Twitter
Re: Possible Faster Debug
Oh man... Modding is about to get so much easier.
Cutscene Upgrade Project - Mainhall Remakes - Between the Ashes
Youtube Channel - P3D Model Box
Between the Ashes is looking for committed testers, PM me for details.
Freespace Upgrade Project See what's happening.

 

Offline m!m

  • 211
Re: Possible Faster Debug
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.

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Possible Faster Debug
OK; I can test what the results are with both off, give me a day or two.
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline niffiwan

  • 211
  • Eluder Class
Re: Possible Faster Debug
OK, here's the graph with both changes, and there's another small improvement over just Default Runtime Checks.



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?
Creating a fs2_open.log | Red Alert Bug = Hex Edit | MediaVPs 2014: Bigger HUD gauges | 32bit libs for 64bit Ubuntu
----
Debian Packages (testing/unstable): Freespace2 | wxLauncher
----
m|m: I think I'm suffering from Stockholm syndrome. Bmpman is starting to make sense and it's actually written reasonably well...

 

Offline Goober5000

  • HLP Loremaster
  • Moderator
  • 214
    • Goober5000 Productions
Re: Possible Faster Debug
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.

 

Offline m!m

  • 211
Re: Possible Faster Debug
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.

 
Re: Possible Faster Debug
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.
The good Christian should beware of mathematicians, and all those who make empty prophecies. The danger already exists that the mathematicians have made a covenant with the devil to darken the spirit and to confine man in the bonds of Hell.