!AruGtDGEakIrccthIK:matrix.org

RoboJackets/robocup-software

80 Members
RoboJackets/robocup-software development chat23 Servers

Load older messages


SenderMessageTime
6 Jul 2020
@_slack_robojackets_U1T86AW4B:matrix.orgguyfleeman This is a really good primer to DSOs on Linux http://people.redhat.com/drepper/dsohowto.pdf 02:20:15
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Really really long unit tests 02:21:19
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Order of 30 seconds in the slow version, 4-5 seconds in the fast version 02:21:39
@_slack_robojackets_U1T86AW4B:matrix.orgguyfleeman Yeah that's not gonna be the initial look up 02:22:00
@_slack_robojackets_U1T86AW4B:matrix.orgguyfleeman Okay I'ma leave it yall. Have fun ;) 02:22:09
@_slack_robojackets_U2YQPBPM2:matrix.orgjneiger3 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
@_slack_robojackets_U2YQPBPM2:matrix.orgjneiger3 This is so weird though 02:25:09
@_slack_robojackets_U2YQPBPM2:matrix.orgjneiger3 Valgrind unit tests and see if the distributions are different? 02:28:57
@jgkamat:matrix.orgjgkamatare 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 slower02:30:27
@jgkamat:matrix.orgjgkamatcan't test your new branch though because my cmake version is not new enough 02:31:34
@_slack_robojackets_U2YQPBPM2:matrix.orgjneiger3 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach And yeah we still have a bad habit of overusing debug binaries 04:06:00
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach (FWIW optimized they're basically identical, it's just super odd that we're seeing order-of-magnitude differences under -Og) 04:57:56
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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:matrix.orgjgkamatI 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 binaries05:31:18
@jgkamat:matrix.orgjgkamatif you need symbols see the releasedebug target, I think that's what I named it. Maybe make perf?05:31:57
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Debug builds with release symbols should obviously be the default for most work, though. 05:41:13
@_slack_robojackets_UCQD8V57W:matrix.orgoswinso lmao can confirm 06:54:50
@_slack_robojackets_UCQD8V57W:matrix.orgoswinso I've always been explicitly setting DCMAKE_BUILD_TYPE=DEBUG so I never noticed the slowdown lmao 06:55:12
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Phenomenal 06:55:30
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Really just fucking ace 06:55:45
@_slack_robojackets_UCQD8V57W:matrix.orgoswinso 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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:matrix.orgjgkamatWe 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
@_slack_robojackets_U2YQPBPM2:matrix.orgjneiger3 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach 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
@_slack_robojackets_UCPA3EW7Q:matrix.orgkwstach Og is much, much faster than O0 - 4 to 10 times faster as we've now seen 17:58:06

There are no newer messages yet.


Back to Room List