| 01:11.56 | starseeker | lands back in MD |
| 02:22.55 | starseeker | hah: http://public.kitware.com/pipermail/cmake-developers/2011-November/002490.html |
| 02:23.52 | starseeker | "I have also successfully tested [ninja+CMake building] with the build systems for OpenCV, Bullet Physics, BRL-CAD, kdelibs and Path64." |
| 02:24.00 | starseeker | must test this |
| 03:25.26 | starseeker | BRL-CAD - CMake + ninja: full compilation time 8 minutes 43 seconds, empty rebuild 0 sec (e.g. < 1 - not measurable by the build delta calculation) |
| 03:27.01 | starseeker | BRL-CAD - CMake + make: full compilation time 9 minutes 8 seconds, empty rebuild 12 sec |
| 03:27.44 | starseeker | (empty rebuild means running ninja/make -j3 after the complete, successful compile, when there's nothing left to do |
| 03:28.31 | starseeker | make will obviously do better on machines with more parallel mojo (yay 2 cores...) |
| 03:29.04 | starseeker | but then, ninja also uses all available cores... |
| 03:29.30 | starseeker | either way, nifty |
| 03:31.18 | starseeker | editing search.c in librt and doing a full rebuild... 19 sec. for ninja, 31 for make -j3 |
| 03:33.25 | starseeker | ninja librt and ninja rt work as expected |
| 03:33.41 | starseeker | sweet |
| 03:41.20 | CIA-28 | BRL-CAD: 03starseeker * r48197 10/brlcad/trunk/TODO: Add a reminder to expand documentation on building BRL-CAD to other tools CMake opens up support for. Low priority. |
| 03:44.01 | CIA-28 | BRL-CAD: 03starseeker * r48198 10/brlcad/trunk/TODO: |
| 03:44.02 | CIA-28 | BRL-CAD: These two DocBook items are addressed - other DocBook TODOs need review - in |
| 03:44.02 | CIA-28 | BRL-CAD: particular, many formatting elements have at least some examples of improved |
| 03:44.02 | CIA-28 | BRL-CAD: formatting, and need to be reworked comprehensively through the DocBook books |
| 05:00.25 | Computer | .window close |
| 05:00.28 | *** part/#brlcad Computer (~Computer@unaffiliated/computer) |
| 11:47.31 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 12:05.09 | *** join/#brlcad merzo (~merzo@189-243-132-95.pool.ukrtel.net) |
| 14:32.25 | *** join/#brlcad merzo (~merzo@35-70-132-95.pool.ukrtel.net) |
| 15:07.57 | brlcad | starseeker: welcome back |
| 15:09.06 | brlcad | starseeker: what's the ninja time without -j* on an empty rebuild? |
| 16:23.08 | ``Erik | starseeker made it sound like ninja doesn't take a -j option... wonder if it has a 'throttle down to 1 cpu' option, though |
| 16:37.46 | starseeker | yeah, ninja uses all CPUs by default |
| 16:38.18 | starseeker | brlcad: thanks! good to be back |
| 17:12.15 | starseeker | ah, I'm wrong |
| 17:12.21 | starseeker | ninja uses 10 cpus by default |
| 17:12.33 | starseeker | ninja DOES support the -j flag |
| 17:38.50 | brlcad | so then the interesting question becomes how long ninja takes on a -j1 empty rebuild |
| 17:39.53 | *** join/#brlcad Stattrav (u3131@gateway/web/irccloud.com/x-yvvqjpomjuxlqxfk) |
| 18:07.34 | starseeker | brlcad: seems to be less than a second |
| 18:08.38 | brlcad | cool, must avoid all the I/O of multiple files/dirs |
| 18:09.21 | starseeker | on a machine with more cores than my home box... build time for make - 3min, 51 sec. ninja 2min, 17sec |
| 18:09.41 | starseeker | isn't sure he believes that, sets up a repeat |
| 18:15.53 | starseeker | yeah, thought so |
| 18:18.05 | starseeker | make -j10 - 2 minutes 24 seconds; ninja (default) - 2 minutes 13 seconds |
| 18:18.59 | starseeker | no-op: make -j10 4sec; ninja (default) - < 1 sec |
| 18:20.51 | brlcad | so faster.. but not dramatically |
| 18:20.59 | brlcad | neat |
| 18:22.20 | starseeker | bets the compiler time is hugely dominant, at least ones things are in cache |
| 18:22.42 | starseeker | Mac might be interesting, with its higher io overheads |
| 18:22.44 | brlcad | like the smp-by-default, but not enough to motivate installing ninja everywhere I build to say the least |
| 18:22.56 | starseeker | nods |
| 18:23.43 | starseeker | pays off more on slower machines like my home box, where the empty opts do go significantly faster |
| 18:24.14 | brlcad | sure |
| 18:24.48 | brlcad | it looses value as you get more cross-platform, having to do installs |
| 18:24.57 | starseeker | right. |
| 18:24.58 | brlcad | that time is minimal for a single platform, but adds up |
| 18:25.43 | brlcad | it'd nominally take a half hour to install across a half-dozen host platforms, assuming nothing goes wrong |
| 18:26.03 | brlcad | ~ (30 * 60) / 4 |
| 18:26.03 | ibot | 450 |
| 18:26.13 | brlcad | that's a lot of empty builds .. :) |
| 18:26.20 | starseeker | heh |
| 18:26.46 | starseeker | letsee... as long as we're at it... how many do we do per day |
| 18:29.23 | brlcad | generous ten times a day would be about 2 months of full-time coding before it started to pay off assuming (falsely) that no new platforms need installs |
| 18:29.34 | starseeker | right |
| 18:30.40 | brlcad | ccache probably saves more than that :) |
| 18:31.21 | starseeker | heh |
| 18:31.31 | brlcad | eventually will pay off, especially if it were bundled with cmake |
| 18:31.53 | starseeker | was kinda hoping they might - would potentially be hugely useful on Windows... |
| 18:31.56 | starseeker | doubt it though |
| 18:32.40 | brlcad | we could probably cut our compilation time in half just through header cleanup alone |
| 18:33.07 | brlcad | definitely would take more than a half-hour, but bigger savings there |
| 18:33.15 | starseeker | really? I figured there would be some improvement, but I hadn't expected it to be that drastic |
| 18:34.43 | brlcad | not hugely significant on an optimized build, maybe 5%-50% .. but non-opt should fly |
| 18:35.10 | brlcad | it's parsing thousands of lines of code for every file |
| 18:36.05 | brlcad | stub in an empty int main() {return 0;} and it takes nearly as long to compile as a 20k-line bool.c |
| 18:36.29 | brlcad | all because including one header like raytrace.h ends up including nearly all of include/*.h |
| 18:36.35 | starseeker | ah |
| 18:36.48 | starseeker | wow |
| 18:37.05 | brlcad | that's 30k lines of logic it has to parse just for decls and macros |
| 18:37.17 | brlcad | breaking up the headers would cut that down by an order |
| 18:37.24 | starseeker | that cleanup is pretty non-trivial though, isn't it? (or at least, highly invasive) |
| 18:37.40 | brlcad | supremely trivial |
| 18:37.46 | brlcad | doesn't get much more trivial |
| 18:37.51 | brlcad | just tedious |
| 18:38.27 | starseeker | hmm... ok |
| 18:38.56 | starseeker | would have thought there would be some structural planning involved |
| 18:39.10 | brlcad | only non-obvious part is updating the .c files to only include the headers they actually need instead of higher-level headers like raytrace.h |
| 18:39.19 | brlcad | but even that is pretty easy |
| 18:39.26 | *** join/#brlcad Stattrav (u3131@gateway/web/irccloud.com/x-wdywtbmtuqrdhppo) |
| 18:39.45 | starseeker | right - worst case, yank 'em all and add in what's missing |
| 18:39.57 | brlcad | exactly |
| 18:40.24 | brlcad | time consuming, tedious, but very trivial |
| 18:45.38 | archivist | or use pre-compiled headers |
| 18:47.12 | ``Erik | that'd be the ccache part, and it doesn't help on the first run |
| 18:48.32 | ``Erik | likes the minimal header inclusion approach to minimize coupling |
| 18:49.01 | starseeker | agrees |
| 18:49.46 | ``Erik | the big #include allIneed header approach smells similar to the jabba "class MyObject extends Object" antipattern |
| 20:24.16 | *** join/#brlcad Technicus (~Technicus@DSLPool-net208-2.wctc.net) |
| 20:25.49 | brlcad | alrighty, all coverity accounts created |
| 20:26.24 | brlcad | anyone else in here (seriously) interested in helping out fix coverity issues? |
| 20:26.34 | brlcad | we're going to be hitting them all up hard next week |
| 21:21.46 | ``Erik | yipes, one of mine is #3 on the defect/kloc list :( |
| 21:22.22 | brlcad | heh |
| 21:22.48 | brlcad | I think I saw that one, free'd then read |
| 21:23.29 | ``Erik | I don't see a way to pull up 1 file and view all the issues with it, or annotate a file or anything |
| 21:23.56 | ``Erik | though I do see some hackish stuff that'd trigger coverity... using =NULL instead of UNUSED() |
| 21:29.42 | brlcad | that coverity run is from before the verbose strict mode work was completed, several months back |
| 21:29.53 | brlcad | so much of it will likely be obe |
| 21:30.05 | brlcad | i'm going to push another run here this weekend |
| 21:30.09 | brlcad | before we get started |
| 21:31.04 | brlcad | alas, fixing the issues is only half the work .. peer review, testing, and docs are going to be part of our fixing process |
| 21:32.24 | brlcad | especially while adhereing to DRY... :) |
| 21:32.47 | ``Erik | write everything twice... WET |
| 21:34.37 | brlcad | especially while adhereing to DRY... :) |
| 21:34.52 | brlcad | there, WET and DRY |
| 21:35.34 | brlcad | mmm... chipped beef on either wed or thurs |
| 21:39.01 | n_reed | ...or Write Every Time |
| 21:42.33 | ``Erik | ALL THE TIMES!!@~! </meme> |
| 22:12.06 | CIA-28 | BRL-CAD: 03n_reed * r48199 10/brlcad/trunk/src/libbn/plane.c: generalize bn_mkpoint_3planes for non-unitized direction vectors |