| 6 Jul 2020 |
 guyfleeman | This is a really good primer to DSOs on Linux http://people.redhat.com/drepper/dsohowto.pdf | 02:20:15 |
 kwstach | Really really long unit tests | 02:21:19 |
| kwstach | Order of 30 seconds in the slow version, 4-5 seconds in the fast version | 02:21:39 |
| guyfleeman | Yeah that's not gonna be the initial look up | 02:22:00 |
| guyfleeman | Okay I'ma leave it yall. Have fun ;) | 02:22:09 |
 jneiger3 | Fwiw, kick eval is one of the more optimized portions of the code base, I spent a decent amount of time getting that correct so it was almost comparable to wineval | 02:22:58 |
| jneiger3 | This is so weird though | 02:25:09 |
| jneiger3 | Valgrind unit tests and see if the distributions are different? | 02:28:57 |
 jgkamat | are you sure you're running tests with -O2? IIRC if you build optimized and then don't clean build you might keep some of the optimized bits or something
Also throwback to when we used debug binaries at comp lmao
For me if I build with debug it's 2x slower | 02:30:27 |
| jgkamat | can't test your new branch though because my cmake version is not new enough | 02:31:34 |
| jneiger3 | Are all the tests that slow down making use of the geometry 2d library? I know kick eval instantly converts to internal types and the brunt of the processing time is on those internal types | 02:47:35 |
| kwstach | This is running with -Og, but it's running with the same compiler settings on each so I'm shocked that it's so much slower. | 04:04:39 |
| kwstach | And yeah we still have a bad habit of overusing debug binaries | 04:06:00 |
| kwstach | Yeah I was thinking about that earlier. I dismissed it because I thought kick evaluator used geometry types in the hot code but if not I'll take another look | 04:07:33 |
| kwstach | (FWIW optimized they're basically identical, it's just super odd that we're seeing order-of-magnitude differences under -Og) | 04:57:56 |
| kwstach | Okay so I'm able to get similar results to what's on staging by explicitly setting -DCMAKE_BUILD_TYPE=Debug when invoking cmake (despite the fact that Debug should be the default). I still don't understand why, but at least that reduces it to build system bugs rather than actual runtime issues. | 05:24:38 |
| jgkamat | I would never do any perf work on debug binaries, because the compiler isn't trying to do anything at all basically any random changes can make really big variations between binaries | 05:31:18 |
| jgkamat | if you need symbols see the releasedebug target, I think that's what I named it. Maybe make perf? | 05:31:57 |
| kwstach | In general that's true. However it is nice to be able to run at lower optimization level considering high optimization levels are obviously more likely to break code structure (i.e. inlining) which can be frustrating while debugging. | 05:40:38 |
| kwstach | Debug builds with release symbols should obviously be the default for most work, though. | 05:41:13 |
 oswinso | lmao can confirm | 06:54:50 |
| oswinso | I've always been explicitly setting DCMAKE_BUILD_TYPE=DEBUG so I never noticed the slowdown lmao | 06:55:12 |
| kwstach | Phenomenal | 06:55:30 |
| kwstach | Really just fucking ace | 06:55:45 |
| oswinso | Lol ok cmake doesn't have a default build type, so it compiles with like no additional compile options. Here's a diff between no build type and debug build currently: https://www.diffchecker.com/UhwOqFUc | 07:08:15 |
| kwstach | Well yes, I assumed that much, but I printed out a status message with the build type with no explicit specifier...and it was "Debug" | 07:09:36 |
| jgkamat | We add the -Og in our cmakelists iirc for debug. I think Og might be a little faster than the default (O0) which might explain the difference (?). But please just dont do any perf work or benchmarks on anything less than O2 - otherwise you might be optimizing or worrying about something the compiler will actually fix for you which is a waste of everyone's time | 15:57:35 |
| jneiger3 | I think the performance things we were seeing here was causing the debug build in the ros version to run at 30 fps instead of 60 fps in the debug build in the non ros branch with very little code differences. It was less performance improvements generally | 16:02:05 |
| kwstach | Yeah. Performance of the debug (-Og) build isn't a hard requirement but it's a nice to have, and it's really not expected to fall so drastically between relatively minor changes to the overall system. Luckily this was just a fluke. | 17:57:08 |
| kwstach | Og is much, much faster than O0 - 4 to 10 times faster as we've now seen | 17:58:06 |
