| 15:10.05 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 15:10.05 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congratulations to our 11 accepted GSoC students!! | |
| 16:39.26 | *** join/#brlcad Al_Da_Best (Al_Da_Best@5e0e10f8.bb.sky.com) | |
| 17:44.45 | *** join/#brlcad ksuzee (~ksu@193.151.105.83) | |
| 17:57.27 | CIA-23 | BRL-CAD: 03anrgmrty * r51540 10/brlcad/trunk/include/analyze.h: analyze.h unused functions for voxelize removed |
| 17:59.24 | CIA-23 | BRL-CAD: 03anrgmrty * r51541 10/brlcad/trunk/src/libged/voxelize.c: callback functions removed from analyze.h and included here |
| 18:01.25 | CIA-23 | BRL-CAD: 03anrgmrty * r51542 10/brlcad/trunk/src/conv/g-voxel.c: callback functions for printing voxel data, rt_prep_parallel moved to voxels.c |
| 18:06.52 | CIA-23 | BRL-CAD: 03anrgmrty * r51543 10/brlcad/trunk/src/libanalyze/voxels.c: rt_prep function added into voxelize function of voxels.c, callback removed |
| 18:34.32 | CIA-23 | BRL-CAD: 03crdueck * r51544 10/brlcad/trunk/src/librt/opennurbs_ext.h: Ray intersection using ON_Intersect() was producing strange results, the simple formula used originally works much better |
| 18:36.15 | CIA-23 | BRL-CAD: 03bob1961 * r51545 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Removed a debug statement. |
| 18:36.49 | brlcad | starseeker: so my self-consistency alarms are going haywire reading r51468 |
| 18:38.06 | brlcad | you made a *DATA() macro now need to specify a DATA path everywhere and a *MAN() macro not have to specify a path everywhere |
| 18:38.35 | brlcad | I would expect not specifying it for both everywhere or specifying it everywhere (in which case the macro seems to fail) |
| 18:40.28 | brlcad | from not to mention r51468 just made us diverge a lil farther from the GNU Coding Standards (not that it matters a whole lot, but they're at least consistent) |
| 18:42.18 | brlcad | I think the issue was that you wanted 'man' in prefix/man so you took a b-line for that door instead of dealing with the underlying issue of datadir not being what you want for a default? |
| 18:44.19 | brlcad | having mandir default to "datadir/man" unless overridden makes complete sense (and is consistent with infodir, htmldir, docdir, and probably a few others we don't use) |
| 18:58.36 | starseeker | brlcad: um... I suppose what I should have done was to rename what is currently BRLCAD_ADDDATA into something more generic and defined BRLCAD_ADDDATA as a macro that called that and tacked on DATA_DIR... |
| 18:59.28 | starseeker | to be honest, I've been paying zero attention to the GNU Coding Standards... |
| 19:07.39 | brlcad | starseeker: yeah, that would have taken care of the replication/api consistency issue |
| 19:08.31 | brlcad | but the other side effect is moving mandir, shouldn't that mean bu_brlcad_data/man is no longer valid? |
| 19:09.10 | brlcad | it'd be getting lucky on a default build because it's sitting in bu_brlcad_root |
| 19:17.43 | starseeker | brlcad: <shrug> just tell me where you want the man pages to go - I'm fine with whatever |
| 19:18.17 | starseeker | is working on fixing the ADDDATA thing now... |
| 19:28.13 | starseeker | the main point was that MAN_DIR should control where *all* the man pages go, both normal and DocBook |
| 19:35.29 | CIA-23 | BRL-CAD: 03starseeker * r51546 10/brlcad/trunk/ (40 files in 40 dirs): Fix so we don't need to use DATA_DIR everywhere - put MAN_DIR back to the DATA_DIR by default, until we figure out what we want to do as a standard behavior. |
| 19:35.59 | brlcad | unless overridden, I think they should go into data/man but then at some point we need to revisit our layout so that datadir==rootdir/share by default |
| 19:36.57 | brlcad | the original problem being solved was only partially solved with the datadir=prefix/share/brlcad/VERSION |
| 19:37.03 | starseeker | brlcad: that should be as simple as setting DATA_DIR to share instead of it's current version dependent value... |
| 19:37.46 | starseeker | why did we do that, anyway? The only advantage I know of is that bu_brlcad_data can do a consistency check to make sure it's pulling the right version of data, and we could achieve that result with a standard file in the root of the data dir... |
| 19:38.22 | brlcad | it should, but I bet it's not -- at least not across all of the places it's implied |
| 19:38.44 | starseeker | takes a deep breath and plunges in... |
| 19:38.59 | brlcad | the goal was getting closer to following the Linux Filesystem Standard |
| 19:39.06 | brlcad | for having a root-installed brl-cad |
| 19:39.10 | brlcad | prefix=/usr |
| 19:39.17 | starseeker | ah, right. |
| 19:39.23 | brlcad | supporting multiple installed versions |
| 19:39.52 | brlcad | so for *that*, /usr/share/brlcad/VERSION for data makes perfect sense, that's what you want |
| 19:39.53 | starseeker | did we give up on that finally? Most of that was being driven by the Linux distros... |
| 19:39.59 | brlcad | no, just ran out of time |
| 19:40.41 | starseeker | <snort> - if you're installing in /usr, it may be perfectly reasonable to require that only one version of BRL-CAD be around - that's probably the model most of the distros would follow |
| 19:40.57 | starseeker | plus, we'd still hit the "librt already exists" issue |
| 19:41.31 | brlcad | not necessarily, libdir needed to also be /usr/lib/brlcad/VERSION, and handling binaries was another issue |
| 19:42.24 | starseeker | could actually try those settings - would be a good workout, since in principle I should have sufficient control to do that correctly |
| 19:42.27 | brlcad | major packages that you'd compile against supported the versioned directory approach and LFS supports it |
| 19:42.33 | brlcad | well before you do |
| 19:43.11 | brlcad | I'm trying to remember, but I think the solution that brought all of the build system changes to a pause (aside from running out of time) was a change in methodology |
| 19:44.48 | starseeker | methodology? |
| 19:46.28 | brlcad | a much simpler approach is to just set prefix/root to a single path (e.g., /usr/share/brlcad/rel-7.24.0) and then have something else create symbolic links in /usr/bin, /usr/lib/brlcad/VERSION, /usr/man/brlcad/VERSION, /usr/include/brlcad/VERSION etc |
| 19:47.17 | brlcad | that way we can support multiple installs, potentially switch 'default' versions on-demand, and should comply with LFS |
| 19:47.39 | brlcad | I'd have to write it all down to make sure the paths are right, at least we should if it's going to be revisited... |
| 19:48.21 | brlcad | no sense going through the trouble if we still fail LFS or get bitching from Debianauts |
| 19:49.05 | starseeker | brlcad: hmm - not sure how the symlink part would work |
| 20:01.55 | *** join/#brlcad andrei__ (~andrei@188.25.160.102) | |
| 20:02.47 | andrei__ | hello |
| 20:02.50 | brlcad | howdy |
| 20:03.21 | ``Erik | the purpose for multiple versions is just library support for third party applications, right? wouldn't /usr/lib/librt.so.<version>.so be adequate? |
| 20:03.47 | brlcad | I believe that fails LFS |
| 20:04.21 | brlcad | and I wouldn't say that's the sole purpose |
| 20:05.07 | ``Erik | woops s/\.so//, |
| 20:05.24 | andrei__ | brlcad,``Erik : any of you had a chance of looking at the graphics ? |
| 20:05.28 | ``Erik | what are the other purposes? (7 why's, wee) |
| 20:06.37 | ``Erik | looks now O.o |
| 20:09.43 | ``Erik | seems a bit noisy, is there any kind of smoothing/curvefit that can be done? I can't really tell if there's "weirdness" from those pics :/ |
| 20:10.06 | CIA-23 | BRL-CAD: 03188.25.160.102 07http://brlcad.org * r4183 10/wiki/User:Popescu.andrei1991: /* Performance measuring */ |
| 20:10.25 | ``Erik | or maybe pick a slice of data to look at, like 1 packet size through the file sizes, or visa versa? |
| 20:10.51 | andrei__ | the last one might be more useful, I did run each test 10 times then computed an average |
| 20:11.15 | andrei__ | I mean for each set of parameters there were 10 iterations |
| 20:11.19 | ``Erik | http://i.imgur.com/AXUpN.png ? |
| 20:11.59 | andrei__ | that is the graphic with the first two merged |
| 20:12.30 | andrei__ | I don't understand the question |
| 20:12.33 | ``Erik | can you filter out the outliers in the data set? maybe a slice of data done as box plots? |
| 20:12.59 | ``Erik | is elapsed time in seconds? |
| 20:13.03 | brlcad | andrei__: what happened? those graphs don't look at all right |
| 20:13.28 | andrei__ | brlcad : I know. I checked everything, ran the script 10 times( instead of 5, because I got 4 machines) |
| 20:13.41 | andrei__ | I shall upload on the page every tool/algorithm I used for processing the data |
| 20:13.46 | andrei__ | maybe I m doing something wrong |
| 20:13.48 | ``Erik | which time are you recording? wall time? cpu time? user? system? |
| 20:13.54 | andrei__ | wall time |
| 20:14.00 | andrei__ | I use gettimeofday() |
| 20:14.10 | brlcad | andrei__: just take a step back for a second -- you had a beautifully smooth curve for one package size |
| 20:14.24 | brlcad | I should see that curve in http://i.imgur.com/OPum5.png but it's nowhere to be seen |
| 20:14.35 | brlcad | not a single one is smooth |
| 20:15.26 | brlcad | so something is very flawed, either in the data or in the way you're graphing it |
| 20:16.33 | andrei__ | after filtering the text file I obtained an array of 24 x 1024 values. Perhaps the error occurs when I convert it to a matrix |
| 20:17.46 | brlcad | those elapse_time values aren't quite believable |
| 20:18.20 | brlcad | you're trying to tell me that nothing took longer than 0.00016 seconds to transfer? |
| 20:18.22 | ``Erik | loopback with 0copy network stack might do that :/ |
| 20:18.46 | andrei__ | http://slexy.org/view/s20hQlb8zF |
| 20:18.57 | andrei__ | This is my octave plotting program |
| 20:19.04 | brlcad | you sent 8MB of data in less than 0.00016 seconds? really? :) |
| 20:20.44 | andrei__ | this is what I gathered, shall I try a single test to see how much does it take ? |
| 20:20.51 | brlcad | that's a rate of 48.8 GB/s if my numbers are right |
| 20:22.26 | andrei__ | I m transfering a 8Mb file with package size 2048 to see how much it takes |
| 20:22.33 | brlcad | if anything, youur graph doesn't show you http://i.imgur.com/H5Q2u.jpg, which like I said should be there somewhere |
| 20:23.45 | brlcad | andrei__: curious why you don't just feed your raw data to gnuplot? |
| 20:24.26 | brlcad | three columns of csv data is all you should end up with |
| 20:26.05 | andrei__ | brlcad : I manually ran a test to transfer a 8MB file on 2048 packages. Took 0.5 |
| 20:26.24 | brlcad | so your graph is only off by about 3 orders of magnitude, great ;) |
| 20:27.08 | brlcad | try to make a single csv |
| 20:27.19 | brlcad | I can graph it here on my end using other tools |
| 20:27.34 | brlcad | while you're investigating |
| 20:28.47 | andrei__ | where should I upload the raw data files ? |
| 20:30.41 | brlcad | http://slexy.org/ will probably work |
| 20:31.47 | starseeker | brlcad: yeah, when /usr/brlcad/lib becomes /usr/brlcad/lib/brlcad/VERSION some of the tclscript logic for finding things doesn't hold water |
| 20:32.08 | starseeker | need a way to find out the values of BIN_DIR, LIB_DIR, etc. from tcl |
| 20:36.25 | *** join/#brlcad andrei (~andrei@188.25.160.102) | |
| 20:37.35 | andrei | 1 - 2048 : http://slexy.org/view/s2QmctjRts 2048 - 4194304 : http://slexy.org/view/s21EopQ7BX |
| 20:40.01 | brlcad | those already don't look right |
| 20:40.16 | brlcad | the end of the first should meet up with the second set, no? |
| 20:41.41 | andrei | nope. the end of the first means transfering an 8mb file with 2048 packages, the first from second means transfering a 1byte file with 2048 package |
| 20:44.22 | brlcad | er, so then those times are something else altogether from what I thought they were |
| 20:45.08 | brlcad | this is very confusing, are you familiar with csv? |
| 20:45.35 | andrei | No but if I need to I will |
| 20:45.44 | brlcad | it's just comma-separated-values |
| 20:45.51 | andrei | ah |
| 20:46.16 | brlcad | when all is said and done, you should have a table of data with N columns |
| 20:46.32 | ``Erik | that any spreadsheet program can read in |
| 20:46.37 | andrei | I m running a test to see if what script returns( including average ) is the same of what I obtained manually |
| 20:47.35 | brlcad | still, before getting into CSV -- explain those two outputs again -- you just said 1 - 2048 : http://slexy.org/view/s2QmctjRts .. and the end of the first means transfering an 8mb file with 2048 packages |
| 20:48.17 | brlcad | so that is one graph transferring 8MB with package size set to 1, 2, .. 2048 yes? |
| 20:49.20 | andrei | One graph is : files 1 - 8MB(powers of two) in packages from 1, 2 .. 2048 |
| 20:49.26 | brlcad | if that's true, then why'd you also give 2048 - 4194304 : http://slexy.org/view/s21EopQ7BX ... they have nothing to do with each other if that's transferring a 1byte "file" with 2048-4MB sized packages |
| 20:49.59 | brlcad | no wonder the graphs are a mess.. doesn't sound like you have the data organized... :) |
| 20:51.33 | brlcad | you can't just increase the package size while increasing the file size -- you're sampling some sort of diagonal across the 3d surface |
| 20:53.07 | andrei | I am quite confused now |
| 20:53.40 | andrei | two imbricated for's should mean that for file size X it tests all package sizes, then move onto the next file size |
| 20:55.51 | brlcad | right |
| 20:56.03 | brlcad | that's not what you just said that data set represents |
| 20:56.32 | brlcad | this is why you need CSV |
| 20:57.42 | brlcad | a file with three columns: data_size, package_size, elapsed_time |
| 20:57.53 | brlcad | in fact, that's your first row |
| 20:58.19 | brlcad | so second line would be something like: 1, 1, 0.0000001234 |
| 20:58.33 | brlcad | third line: 1, 2, 0.0000001235 |
| 20:58.56 | brlcad | fourth line: 1, 3, 0.000001220 |
| 20:58.57 | brlcad | etc |
| 20:59.07 | andrei | the scripts don t take so much time now, I ll double check again that everything is correct. |
| 20:59.19 | andrei | But I did test several script results with manual results |
| 20:59.23 | andrei | and the error is of 0.001 |
| 20:59.41 | andrei | (manually computed average) |
| 21:00.07 | brlcad | after 2048 lines, the next row increases the data_size: 2, 1, .... |
| 21:00.36 | brlcad | I don't doubt that you're capturing timings -- I think maybe you're just not tabulating it right |
| 21:00.48 | brlcad | put it into a single table |
| 21:01.06 | brlcad | heck, you can make your script print that exact line for what it's testing |
| 21:01.29 | andrei | yes, I will do that now |
| 21:09.29 | *** join/#brlcad cristina (~quassel@188.24.49.125) | |
| 21:09.39 | *** join/#brlcad cristina (~quassel@unaffiliated/cristina) | |
| 22:04.10 | CIA-23 | BRL-CAD: 03crdueck * r51547 10/brlcad/trunk/src/librt/primitives/sketch/sketch_tess.cpp: added HIDDEN to declaration of auxillary functions. new algorithm for approx_bezier() to split at the point of maximum deviation, produces far less carc_segs for the same tolerance. some code cleanup |
| 22:39.18 | CIA-23 | BRL-CAD: 03starseeker * r51548 10/brlcad/trunk/misc/CMakeLists.txt: brlcad-config is executable |
| 22:44.24 | CIA-23 | BRL-CAD: 03starseeker * r51549 10/brlcad/trunk/ (8 files in 7 dirs): |
| 22:44.25 | CIA-23 | BRL-CAD: Do some experimentation with altering LIB_DIR. Need some introspective ability |
| 22:44.25 | CIA-23 | BRL-CAD: to know the relative library path, so add a command that can give us that. |
| 22:44.25 | CIA-23 | BRL-CAD: DOC_DIR needs some work - should be more like MAN_DIR and not necessarily assume |
| 22:44.25 | CIA-23 | BRL-CAD: DATA_DIR is the final destination. Looks like the main problem with moving |
| 22:44.25 | CIA-23 | BRL-CAD: things out of lib is (surprise) the Tcl/Tk initialization process and packages. |
