| 00:07.53 | brlcad | yes, 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.12 | brlcad | alternatively 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.26 | brlcad | zero_level: post your test file somewhere so we can take a look at it |
| 01:46.38 | brlcad | and try it in other places |
| 02:00.05 | zero_level | testfile is here : http://bzflag.bz/~mohit/interleaved.c |
| 02:00.21 | zero_level | this has for interleaved 1-D array |
| 02:16.08 | zero_level | also for structure double pixel_s{double r,g,b} |
| 02:16.12 | zero_level | http://www.bzflag.bz/~mohit/structure.c |
| 02:39.30 | *** join/#brlcad mpictor_ (~mpictor_@2601:d:b280:9:7c7b:dd80:988b:1fbb) | |
| 03:41.51 | zero_level | for non interleaved data(double** data) |
| 03:41.54 | zero_level | http://brlcad.org/~mohit/seperatearrays.c |
| 03:42.26 | zero_level | huh interesting all of them have similar performance |
| 03:42.55 | zero_level | brlcad, ``Erik What do v donow ?;) |
| 04:28.56 | brlcad | zero_level: I'll run some more tests but that's already actionable |
| 04:29.02 | brlcad | that basically indicates that performance is not at all a concern and we should aim for implementation expressiveness, modularity, flexibility |
| 04:29.19 | brlcad | which of those is most flexible, expressive to you and why? |
| 04:29.45 | brlcad | and how will that translate to API implementation and use by callers |
| 04:30.07 | zero_level | i would want interleaved |
| 04:33.21 | brlcad | that doesn't any of those four questions ;) |
| 04:36.12 | brlcad | if 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.57 | brlcad | if 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.21 | zero_level | brlcad, ``Erik i guess a one dimensional array with interleaved array will be most flexible. because |
| 06:05.34 | zero_level | a) only one pointer to record |
| 06:05.59 | zero_level | b) has the abiliy to store any number of interleaved channels |
| 06:08.40 | zero_level | c) easy for reading /writting |
| 06:09.05 | zero_level | d) 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.40 | Notify | 03BRL-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.42 | Notify | 03BRL-CAD:carlmoore * 55841 brlcad/trunk/doc/docbook/system/man1/en/fbfade.xml: H replaces h in options for fbfade |
| 11:15.06 | Notify | 03BRL-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.11 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5513 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 11:15.13 | Notify | 03BRL-CAD Wiki:41.92.210.17 * 5514 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */ |
| 11:15.16 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5515 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 11:15.18 | Notify | 03BRL-CAD:carlmoore * 55843 brlcad/trunk/src/fb/fbfree.c: add h and ? for help; omit run-with-no-arguments |
| 11:15.27 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5516 /wiki/User:KeshaSShah/GSoC13/Reports: /* June 24 */ |
| 11:15.31 | Notify | 03BRL-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.35 | Notify | 03BRL-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.49 | Notify | 03BRL-CAD:carlmoore * 55846 brlcad/trunk/src/fb/fbgammamod.c: add underscores to printed names, to match the usage statement |
| 11:15.54 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5517 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 11:15.58 | Notify | 03BRL-CAD Wiki:Vladbogolin * 5518 /wiki/User:Vladbogolin/GSoC2013/Logs: |
| 11:16.24 | Notify | 03BRL-CAD:phoenixyjll * 55847 brlcad/trunk/src/libbrep/intersect.cpp: Add tolerance in the bounding box intersections. |
| 11:16.27 | Notify | 03BRL-CAD:phoenixyjll * 55848 brlcad/trunk/src/libbrep/intersect.cpp: Check duplication before appending to the array x. |
| 11:16.34 | Notify | 03BRL-CAD:phoenixyjll * 55849 brlcad/trunk/src/libbrep/intersect.cpp: If the inverse fails, we try another two directions. |
| 11:17.00 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5519 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week 2 */ |
| 11:17.02 | Notify | 03BRL-CAD Wiki:KeshaSShah * 5520 /wiki/User:KeshaSShah/GSoC13/Reports: /* Week -1 */ |
| 11:17.04 | Notify | 03BRL-CAD:phoenixyjll * 55850 brlcad/trunk/src/libbrep/CMakeLists.txt: Add tests for curve-curve intersection. |
| 11:17.06 | Notify | 03BRL-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.08 | Notify | 03BRL-CAD:phoenixyjll * 55852 brlcad/trunk/src/libbrep/intersect.cpp: Remove the set-but-not-used variable distance. |
| 11:17.10 | Notify | 03BRL-CAD Wiki:Phoenix * 5521 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 2 */ |
| 11:17.13 | Notify | 03BRL-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.22 | brlcad | zero_level: going to attempt the parallel test? |
| 14:43.38 | brlcad | zero_level: I think your decision is defensible/reasonable and will be good going forward |
| 14:43.44 | brlcad | just note that (a), (c), and (d) don't have much to do with flexibility/expressiveness |
| 14:44.19 | brlcad | (b) is the real key plus a few other points you didn't identify ;) |
| 14:45.15 | brlcad | of 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.49 | Notify | 03BRL-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.17 | zero_level | brlcad, ``Erik I guess interleaved data with (double*) it is. |
| 15:29.30 | zero_level | Then today i am chaging the existing use of the icv library with the new structure definition. |
| 15:36.31 | Notify | 03BRL-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.03 | Notify | 03BRL-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.12 | Notify | 03BRL-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.53 | Notify | 03BRL-CAD:brlcad * 55856 (brlcad/trunk/src/libbrep/intersect.cpp brlcad/trunk/src/libbrep/libbrep_brep_tools.cpp and 5 others): indent cleanup |
| 16:02.00 | Notify | 03BRL-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 | ``Erik | zero_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 | ``Erik | downloads 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.08 | Notify | 03BRL-CAD:carlmoore * 55858 brlcad/trunk/src/fb/fbgammamod.c: implement h,? help; explain the last 13 items in Usage |
| 16:49.59 | Notify | 03BRL-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.09 | Notify | 03BRL-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.04 | Notify | 03BRL-CAD Wiki:41.92.210.17 * 5523 /wiki/User:Izak/GSOC_2013_logs: /* From June 24th to June 28th */ |
| 17:37.40 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5524 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 17:45.00 | Notify | 03BRL-CAD:erikgreenwald * 55861 (brlcad/trunk/misc/CMake/BRLCAD_CMakeFiles.cmake brlcad/trunk/misc/CMakeLists.txt): remove libtool.m4 |
| 17:46.51 | Notify | 03BRL-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.49 | Notify | 03BRL-CAD Wiki:NyahCh3ck20 * 5525 /wiki/User:NyahCh3ck20/GSoc2013/Coding_Repor: /* 24 June - 30 June */ |
| 18:00.34 | zero_level | ``Erik are u suggesting to use strucutre (pixel_s) instead of interleaved array ? |
| 18:00.56 | zero_level | brlcad 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.04 | brlcad | zero_level: I think he's responding to the way you tested the struct |
| 18:12.43 | brlcad | instead of allocating an array of struct pointers, allocating an array big enough to directly contain the number of structs desired |
| 18:34.12 | Notify | 03BRL-CAD Wiki:Harman052 * 5526 /wiki/User:Harman052/GSoc2013/Logs: |
| 18:40.13 | Notify | 03BRL-CAD:erikgreenwald * 55863 brlcad/trunk/src/adrt/isst: add mode menu |
| 18:42.21 | Notify | 03BRL-CAD:erikgreenwald * 55864 brlcad/trunk/src/adrt/isst: remove quit button from bottom, use menu instead |
| 18:44.16 | zero_level | brlcad: I used this |
| 18:44.20 | zero_level | bif->data = (struct pixel_s*) malloc(HEIGHT*WIDTH*sizeof(struct pixel_s)) |
| 18:44.41 | brlcad | okay |
| 18:44.48 | brlcad | so then he didnt' see your test ;) |
| 18:45.38 | zero_level | i think ``Erik is suggesting to use sructure as imd data and not the interleaved array |
| 18:46.03 | zero_level | will be clarified in a minute :-) |
| 18:46.19 | brlcad | well I think your testing already showed that to be moot |
| 18:47.03 | brlcad | the only value that has is semantic, so either interleaved or non-interleaved double array ends up being more adaptive |
| 18:48.24 | zero_level | but non interleaved has a risk of handling a number of pointers at one time |
| 18:48.39 | brlcad | what risk? |
| 18:49.15 | brlcad | handling a pointer isn't a risk by itself |
| 18:49.33 | brlcad | no more than having an if statement is risky because it's conditional |
| 18:51.20 | zero_level | i meant it will be clumsy |
| 18:51.33 | zero_level | say u have u two images |
| 18:51.53 | zero_level | and u want to perform an operation on them |
| 18:52.01 | zero_level | and both images are three channel images |
| 18:52.03 | brlcad | I think you're letting a lack of familiarity cloud your objective reasoning |
| 18:52.07 | brlcad | they're basically the same thing |
| 18:52.36 | zero_level | then u will have to maintain 6 pointers if it is not interleaved |
| 18:52.49 | zero_level | else u only maaintain 2 pointers |
| 18:53.41 | brlcad | it's data[offset+RED],data[offset+GRN],data[offset+BLU] vs. data[RED][offset],data[GRN][offset],data[BLU][offset] |
| 18:54.51 | brlcad | there's no "maintaining" needed because you only allocate either container and free it exactly once |
| 18:54.57 | brlcad | access is just semantic sugar |
| 18:55.12 | brlcad | no pointer management involved |
| 18:55.51 | brlcad | note: i'm not saying use it or not, I'm saying your reason for not wanting to use it is unreasoned :) |
| 18:56.29 | brlcad | it's actually a fairly common pattern for image processing APIs, some file formats are even stored that way |
| 18:57.05 | brlcad | think of it this way too -- you can do interleaved AND non-interleaved with just double *data too |
| 18:57.52 | zero_level | yes |
| 18:57.55 | brlcad | technically faster, but not as pretty syntax to index into the array -- you want macros |
| 19:00.36 | ``Erik | I 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 | ``Erik | in 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.26 | zero_level | ok ``Erik |
| 19:02.41 | zero_level | ``Erik i didnt get that function you were talking in rt |
| 19:02.59 | zero_level | i want double data from the raytracer |
| 19:03.05 | brlcad | ``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.15 | zero_level | to modify the existing uses |
| 19:03.17 | brlcad | functionally at least |
| 19:04.35 | brlcad | that they are basically the same thing was the point of last night's test too |
| 19:05.17 | brlcad | arguments 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.53 | brlcad | if an interleaved double *data array with a channel count is comfortable enough, that will work just fine |
| 19:07.17 | brlcad | even 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.43 | Notify | 03BRL-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 | ``Erik | indirect/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) | |