IRC log for #brlcad on 20130626

00:07.53brlcadyes, we need to know the time it takes to generate random numbers so we can make sure they're not included in the time to fill the data structure
00:09.12brlcadalternatively could fill a simple double array with random values beforehand, and time how long it takes to read all of them, the write from that array to the data structure
00:34.21*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
01:46.26brlcadzero_level: post your test file somewhere so we can take a look at it
01:46.38brlcadand try it in other places
02:00.05zero_leveltestfile is here : http://bzflag.bz/~mohit/interleaved.c
02:00.21zero_levelthis has for interleaved 1-D array
02:16.08zero_levelalso for structure double pixel_s{double r,g,b}
02:16.12zero_levelhttp://www.bzflag.bz/~mohit/structure.c
02:39.30*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
03:41.51zero_levelfor non interleaved data(double** data)
03:41.54zero_levelhttp://brlcad.org/~mohit/seperatearrays.c
03:42.26zero_levelhuh interesting all of them have similar performance
03:42.55zero_levelbrlcad, ``Erik What do v donow ?;)
04:28.56brlcadzero_level: I'll run some more tests but that's already actionable
04:29.02brlcadthat basically indicates that performance is not at all a concern and we should aim for implementation expressiveness, modularity, flexibility
04:29.19brlcadwhich of those is most flexible, expressive to you and why?
04:29.45brlcadand how will that translate to API implementation and use by callers
04:30.07zero_leveli would want interleaved
04:33.21brlcadthat doesn't any of those four questions ;)
04:36.12brlcadif you really want to tackle a follow-on test, use bu_parallel() to have multiple threads access different scanlines in the image data, perhaps try calculating the average of all pixel values in parallel
04:36.57brlcadif one method vs another is more SMP-friendly or cache-friendly, that would be signficant
04:44.45*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
06:05.21zero_levelbrlcad, ``Erik i guess a one dimensional array with interleaved array will be most flexible. because
06:05.34zero_levela) only one pointer to record
06:05.59zero_levelb) has the abiliy to store any number of interleaved channels
06:08.40zero_levelc) easy for reading /writting
06:09.05zero_leveld) easier processing due to less number of pointers to record
06:50.40*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
06:59.32*** join/#brlcad caen23 (~caen23@92.81.190.86)
08:04.15*** join/#brlcad kesha (~kesha@49.249.9.138)
08:19.15*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
08:54.53*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
09:07.05*** join/#brlcad vladbogo (~vlad@86.124.248.54)
09:16.55*** join/#brlcad vladbogo_ (~vlad@86.121.100.242)
10:03.01*** join/#brlcad kesha (~kesha@49.249.9.138)
10:24.55*** join/#brlcad mpictor (~mpictor_@2600:1015:b126:bc6c:0:34:de85:bd01)
10:31.29*** join/#brlcad mpictor_ (~mpictor_@2600:1015:b126:bc6c:0:34:de85:bd01)
10:41.31*** join/#brlcad kesha__ (~kesha@49.249.9.138)
10:44.43*** join/#brlcad mpictor_ (~mpictor_@2600:1015:b126:bc6c:0:34:de85:bd01)
10:46.30*** join/#brlcad kesha (~kesha@49.249.9.138)
10:53.58*** join/#brlcad kesha__ (~kesha@49.249.9.138)
11:14.16*** join/#brlcad Notify (~notify@66-118-151-70.static.sagonet.net)
11:14.40Notify03BRL-CAD:carlmoore * 55840 brlcad/trunk/src/fb/fbfade.c: implement h,?, run-with-no-args for help; old h is replaced by H
11:14.42Notify03BRL-CAD:carlmoore * 55841 brlcad/trunk/doc/docbook/system/man1/en/fbfade.xml: H replaces h in options for fbfade
11:15.06Notify03BRL-CAD:carlmoore * 55842 (brlcad/trunk/doc/docbook/system/man1/en/fbframe.xml brlcad/trunk/src/fb/fbframe.c): remove h,a ('a' was unused); h becomes, along with ? and no-arguments, a help option
11:15.11Notify03BRL-CAD Wiki:NyahCh3ck20 * 5513 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */
11:15.13Notify03BRL-CAD Wiki:41.92.210.17 * 5514 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */
11:15.16Notify03BRL-CAD Wiki:NyahCh3ck20 * 5515 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */
11:15.18Notify03BRL-CAD:carlmoore * 55843 brlcad/trunk/src/fb/fbfree.c: add h and ? for help; omit run-with-no-arguments
11:15.27Notify03BRL-CAD Wiki:KeshaSShah * 5516 /wiki/User:KeshaSShah/GSoC13/Reports: /* June 24 */
11:15.31Notify03BRL-CAD:carlmoore * 55844 brlcad/trunk/src/fb/fbgamma.c: change h to H, because of no alternative for high-res; now use h,? for help (run-with-no-arguments already works)
11:15.35Notify03BRL-CAD:carlmoore * 55845 brlcad/trunk/doc/docbook/system/man1/en/fbgamma.xml: fix the man page for fbgamma, because I changed h to H
11:15.49Notify03BRL-CAD:carlmoore * 55846 brlcad/trunk/src/fb/fbgammamod.c: add underscores to printed names, to match the usage statement
11:15.54Notify03BRL-CAD Wiki:Vladbogolin * 5517 /wiki/User:Vladbogolin/GSoC2013/Logs:
11:15.58Notify03BRL-CAD Wiki:Vladbogolin * 5518 /wiki/User:Vladbogolin/GSoC2013/Logs:
11:16.24Notify03BRL-CAD:phoenixyjll * 55847 brlcad/trunk/src/libbrep/intersect.cpp: Add tolerance in the bounding box intersections.
11:16.27Notify03BRL-CAD:phoenixyjll * 55848 brlcad/trunk/src/libbrep/intersect.cpp: Check duplication before appending to the array x.
11:16.34Notify03BRL-CAD:phoenixyjll * 55849 brlcad/trunk/src/libbrep/intersect.cpp: If the inverse fails, we try another two directions.
11:17.00Notify03BRL-CAD Wiki:KeshaSShah * 5519 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 2 */
11:17.02Notify03BRL-CAD Wiki:KeshaSShah * 5520 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week -1 */
11:17.04Notify03BRL-CAD:phoenixyjll * 55850 brlcad/trunk/src/libbrep/CMakeLists.txt: Add tests for curve-curve intersection.
11:17.06Notify03BRL-CAD:phoenixyjll * 55851 brlcad/trunk/src/libbrep/intersect.cpp: More work on the tolerance value to get a more accurate and correct result.
11:17.08Notify03BRL-CAD:phoenixyjll * 55852 brlcad/trunk/src/libbrep/intersect.cpp: Remove the set-but-not-used variable distance.
11:17.10Notify03BRL-CAD Wiki:Phoenix * 5521 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 2 */
11:17.13Notify03BRL-CAD Wiki:Pauljenn10 * 0 /wiki/User:Pauljenn10:
11:33.59*** join/#brlcad AndChat|321536 (~AndChat32@49.249.19.221)
11:34.24*** join/#brlcad kesha (~kesha@49.249.19.221)
14:41.22brlcadzero_level: going to attempt the parallel test?
14:43.38brlcadzero_level: I think your decision is defensible/reasonable and will be good going forward
14:43.44brlcadjust note that (a), (c), and (d) don't have much to do with flexibility/expressiveness
14:44.19brlcad(b) is the real key plus a few other points you didn't identify ;)
14:45.15brlcadof course, ease of implementation is *another* factor, and a good one to also evaluate, and that's where a/c/d come in
14:47.47*** join/#brlcad kesha__ (~kesha@49.202.239.103)
14:56.35*** join/#brlcad vladbogo (~vlad@86.121.100.92)
15:00.34*** join/#brlcad kesha (~kesha@49.202.239.103)
15:00.49Notify03BRL-CAD:brlcad * 55853 brlcad/trunk/TODO: leave a comment about implementing support for raw voxel data per a discussion last summer during g-voxel's development
15:26.17zero_levelbrlcad, ``Erik I guess interleaved data with (double*) it is.
15:29.30zero_levelThen today i am chaging the existing use of the icv library with the new structure definition.
15:36.31Notify03BRL-CAD Wiki:Level zero * 5522 /wiki/User:Level_zero/GSOC13/logs: /* WEEK 2 */
15:36.32*** join/#brlcad cstirk (~quassel@96.255.19.39)
15:38.03Notify03BRL-CAD:brlcad * 55854 (brlcad/trunk/src/libbrep/libbrep_brep_tools.cpp brlcad/trunk/src/libbrep/libbrep_brep_tools.h brlcad/trunk/src/libbrep/opennurbs_ext.cpp): folks need to fix their editors to show your trailing whitespace turds... :)
15:46.07*** join/#brlcad Kimz (~AndChat32@49.202.239.103)
15:57.12Notify03BRL-CAD:brlcad * 55855 brlcad/trunk/src/libbrep/PullbackCurve.cpp: messy, reduce the ifdef to the actual isolated difference. remove dead code for clarity.
15:58.53Notify03BRL-CAD:brlcad * 55856 (brlcad/trunk/src/libbrep/intersect.cpp brlcad/trunk/src/libbrep/libbrep_brep_tools.cpp and 5 others): indent cleanup
16:02.00Notify03BRL-CAD:brlcad * 55857 brlcad/trunk/src/libbrep/intersect.cpp: style conformance
16:02.39*** join/#brlcad vladbogo_ (~vlad@86.121.96.23)
16:05.09``Erikzero_level: my thought was that the structs would be in a single packed array, not an array of pointers to structs... img.pixels = (struct pixel_s *)bu_malloc(img.w * img.h * sizeof(struct pixel_s));
16:09.52``Erikdownloads wikipedia O.o
16:21.28*** join/#brlcad vladbogo__ (~vlad@86.121.101.33)
16:35.37*** join/#brlcad kesha (~kesha@49.202.239.103)
16:47.08Notify03BRL-CAD:carlmoore * 55858 brlcad/trunk/src/fb/fbgammamod.c: implement h,? help; explain the last 13 items in Usage
16:49.59Notify03BRL-CAD:carlmoore * 55859 (brlcad/trunk/doc/docbook/system/man1/en/fbgrid.xml brlcad/trunk/src/fb/fbgrid.c): old 'h' dropped in favor of 'S 1024'; implement h,?,run-with-no-arguments for help
17:03.09Notify03BRL-CAD:carlmoore * 55860 brlcad/trunk/src/fb/fbhelp.c: provide h,? help; omitted run-with-no-arguments, because that currently gives help regarding the framebuffer!
17:22.04Notify03BRL-CAD Wiki:41.92.210.17 * 5523 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */
17:37.40Notify03BRL-CAD Wiki:NyahCh3ck20 * 5524 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */
17:45.00Notify03BRL-CAD:erikgreenwald * 55861 (brlcad/trunk/misc/CMake/BRLCAD_CMakeFiles.cmake brlcad/trunk/misc/CMakeLists.txt): remove libtool.m4
17:46.51Notify03BRL-CAD:erikgreenwald * 55862 brlcad/trunk/doc/PROJECTS: remove bit about autogen.sh and gnu build system tools
17:47.31*** join/#brlcad vladbogo (~vlad@86.124.248.68)
17:53.49Notify03BRL-CAD Wiki:NyahCh3ck20 * 5525 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */
18:00.34zero_level``Erik are u suggesting to use strucutre (pixel_s) instead of interleaved array ?
18:00.56zero_levelbrlcad suggested some tests. I hope u saw those test files.?
18:01.24*** join/#brlcad kesha__ (~kesha@49.202.239.103)
18:03.50*** join/#brlcad kesha__ (~kesha@49.202.239.103)
18:12.04brlcadzero_level: I think he's responding to the way you tested the struct
18:12.43brlcadinstead of allocating an array of struct pointers, allocating an array big enough to directly contain the number of structs desired
18:34.12Notify03BRL-CAD Wiki:Harman052 * 5526 /wiki/User:Harman052/GSoc2013/Logs:
18:40.13Notify03BRL-CAD:erikgreenwald * 55863 brlcad/trunk/src/adrt/isst: add mode menu
18:42.21Notify03BRL-CAD:erikgreenwald * 55864 brlcad/trunk/src/adrt/isst: remove quit button from bottom, use menu instead
18:44.16zero_levelbrlcad: I used this
18:44.20zero_levelbif->data = (struct pixel_s*) malloc(HEIGHT*WIDTH*sizeof(struct pixel_s))
18:44.41brlcadokay
18:44.48brlcadso then he didnt' see your test ;)
18:45.38zero_leveli think ``Erik is suggesting to use sructure as imd data and not the interleaved array
18:46.03zero_levelwill be clarified in a minute :-)
18:46.19brlcadwell I think your testing already showed that to be moot
18:47.03brlcadthe only value that has is semantic, so either interleaved or non-interleaved double array ends up being more adaptive
18:48.24zero_levelbut non interleaved has a risk of handling a number of pointers at one time
18:48.39brlcadwhat risk?
18:49.15brlcadhandling a pointer isn't a risk by itself
18:49.33brlcadno more than having an if statement is risky because it's conditional
18:51.20zero_leveli meant it will be clumsy
18:51.33zero_levelsay u have u two images
18:51.53zero_leveland u want to perform an operation on them
18:52.01zero_leveland both images are three channel images
18:52.03brlcadI think you're letting a lack of familiarity cloud your objective reasoning
18:52.07brlcadthey're basically the same thing
18:52.36zero_levelthen u will have to maintain 6 pointers if it is not interleaved
18:52.49zero_levelelse u only maaintain 2 pointers
18:53.41brlcadit's data[offset+RED],data[offset+GRN],data[offset+BLU] vs. data[RED][offset],data[GRN][offset],data[BLU][offset]
18:54.51brlcadthere's no "maintaining" needed because you only allocate either container and free it exactly once
18:54.57brlcadaccess is just semantic sugar
18:55.12brlcadno pointer management involved
18:55.51brlcadnote: i'm not saying use it or not, I'm saying your reason for not wanting to use it is unreasoned :)
18:56.29brlcadit's actually a fairly common pattern for image processing APIs, some file formats are even stored that way
18:57.05brlcadthink of it this way too -- you can do interleaved AND non-interleaved with just double *data too
18:57.52zero_levelyes
18:57.55brlcadtechnically faster, but not as pretty syntax to index into the array -- you want macros
19:00.36``ErikI didn't see the test, was just going by comments... 'technically faster' should have technically gone away; both are just pointer math and compilers are getting good at optimizing that :)
19:02.01``Erikin the end, zero_level, I'd say use the one that you feel most comfortable with... there are pros and cons to both ways *shrug*
19:02.26zero_levelok ``Erik
19:02.41zero_level``Erik i didnt get that function you were talking in rt
19:02.59zero_leveli want double data from the raytracer
19:03.05brlcad``Erik: well, except his original way was struct {r,g,b,a} and I think that won't work in the long run
19:03.15zero_levelto modify the existing uses
19:03.17brlcadfunctionally at least
19:04.35brlcadthat they are basically the same thing was the point of last night's test too
19:05.17brlcadarguments about unqualified "clumsiness" or somehow that having [insert pointer count here] was a problem is what I was disputing, not to suggest using it or not (as stated)
19:05.53brlcadif an interleaved double *data array with a channel count is comfortable enough, that will work just fine
19:07.17brlcadeven better would be to make that structure be entirely opaque to the API, access pixel elements by function or macro, never directly, and it won't matter
19:07.43Notify03BRL-CAD:carlmoore * 55865 brlcad/trunk/src/fb/fblabel.c: implement h and ? help (run-with-no-arguments already works); old h gives way to 's 1024'; 2 variables are initialized so we don't depend on the system (they are given new values by program options)
19:37.39*** join/#brlcad mpictor (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
19:40.12``Erikindirect/encapsulated was what I was hoping for :) (had even pondered mentioning a union with an 'internal type' flag)
19:42.02*** join/#brlcad mpictor_ (~mpictor_@c-67-177-102-131.hsd1.in.comcast.net)
19:50.55*** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
19:58.52*** join/#brlcad mpictor (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb)
20:02.27*** join/#brlcad mpictor_ (~mpictor_@c-67-177-102-131.hsd1.in.comcast.net)
20:47.36*** join/#brlcad kesha__ (~kesha@49.249.1.41)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.