| 00:18.06 | IriX64 | err just noticed, never mind the index :) i screwup like that regularly. |
| 00:25.50 | *** join/#brlcad docelic (n=docelic@212.15.170.57) | |
| 01:04.32 | *** join/#brlcad CIA-21 (i=cia@cia.navi.cx) | |
| 01:58.58 | IriX64 | what frequency? :) |
| 02:00.11 | Maloeran | Perhaps to see if there's some bug left? I left it run with distributed processing on 3 boxes for about 36 hours, I'm hoping it's fine |
| 02:40.15 | CIA-21 | BRL-CAD: 03brlcad * 10brlcad/src/external/EndgameFramework/Makefile.am: include the defs file so we get additional rules |
| 02:41.07 | CIA-21 | BRL-CAD: 03brlcad * 10brlcad/misc/enigma/Makefile.am: stub rules so recursion completes cleanly |
| 02:41.36 | brlcad | possibly |
| 04:19.56 | IriX64 | Hah you may have another customer, the local mill has people watching my antics with brlcad. |
| 07:03.53 | *** join/#brlcad clock_ (i=clock@84-72-61-171.dclient.hispeed.ch) | |
| 08:24.41 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 13:21.01 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 14:35.38 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 15:20.43 | *** join/#brlcad cad46 (n=5b1736b3@bz.bzflag.bz) | |
| 16:18.35 | ``Erik | and now I'm on vacation for a week, w00t :D |
| 16:24.47 | *** join/#brlcad Elperion (n=Elperion@p54877b4b.dip.t-dialin.net) | |
| 16:28.46 | Maloeran | Erik, send me a big endian cache! You told me that already :p |
| 16:29.02 | Maloeran | It can't be much to fix, but I need a big endian cache |
| 16:39.33 | brlcad | should just always write the cache out in network order, then the format is well known |
| 16:41.02 | brlcad | that's why all the posix routines exist for this :) |
| 16:41.39 | ``Erik | I'd need to get approval to send ya that... I like just writing out in network (correct) order... um |
| 16:41.52 | ``Erik | rtcmp has a triangle cache file that's held that way... I think it even works |
| 16:41.54 | ``Erik | O.o |
| 16:46.42 | Maloeran | Network order involves unnecessary byte swapping |
| 16:47.35 | Maloeran | If graphs are to be synchronized in a distributed processing network, with geometry being constantly modified, avoiding the byte swapping just makes sense |
| 16:47.57 | ``Erik | um, depends on what endian your machine is |
| 16:48.36 | Maloeran | I also prefer big endian for obscure reasons, but reality is different |
| 16:54.38 | ``Erik | um, it "fails" as part of its regular process :/ |
| 16:54.47 | ``Erik | which is why there's all that setjmp/longjmp crap going on |
| 16:56.13 | Maloeran | All right, cool |
| 16:58.12 | ``Erik | um, have you looked at rtcmp over the weekend? I'm trying to abstract out the BRL-CAD crap in it some to simplify rayforce/rayforce.c |
| 16:58.56 | Maloeran | I looked last week, I'll update |
| 17:02.28 | ``Erik | all the librt stuff was removed from adrt/adrt.c and put into tri.c, which does caching out to a file |
| 17:02.53 | ``Erik | which means all you have to do is cope with a simple linked list with straight xyz float data |
| 17:25.36 | ``Erik | http://www.eatliver.com/i.php?n=1284 |
| 17:31.13 | Maloeran | If I knew any modelling software rather than writing code to do it, I suspect the task would be easier |
| 17:36.14 | brlcad | uhm.. you're reading/writing to disk .. which is usually at least an order of magnitude more time-consuming than any "unnecessary byteswapping" .. which is why it flat out doesn't matter -- if you have a profile that shows otherwise, that would probably be worthy of academic publication |
| 17:37.31 | Maloeran | brlcad, graph caches are also used for distributed processing synchronisation |
| 17:39.25 | brlcad | i don't think you're stupid, you just make bizzare statements that smell of inexperience or pedantic religion where it really doesn't matter (sometimes) |
| 17:39.43 | brlcad | think you're quite brilliant actually, novel approaches |
| 17:39.54 | *** join/#brlcad digitalfredy_ (n=digitalf@200.71.62.161) | |
| 17:40.14 | brlcad | but i still fail to see how the use of the files/data has any bearing on byte swapping -- educate me? :) |
| 17:40.53 | brlcad | if you have to read disk, and that is the IF .. then byte swapping doesn't matter since 99% or better of your time is spent on an uncontrolled I/O variable |
| 17:41.11 | Maloeran | Indeed |
| 17:41.50 | brlcad | if you're not reading disk or talking about memory mapped stuff that might be optimized to avoid I/O then things can change.. but nothing you've said indicated this |
| 17:41.53 | Maloeran | When updating graphs over a network for distributed processing though, any unnecessary work should be avoided |
| 17:42.13 | Maloeran | The same graph caches are used for disk storage or synchronisation |
| 17:44.35 | brlcad | there's certainly some disjoint in the conversation, or something you're just not saying perhaps |
| 17:44.50 | brlcad | that's all fine and well understood -- that doesn't change the nature of I/O |
| 17:45.02 | brlcad | disk I/O in particular |
| 17:46.09 | Maloeran | Of course, I don't deny that any disk I/O will be a far bigger bottleneck than swapping bytes |
| 17:46.11 | brlcad | having it be one encoding in a heterogenous environment is what makes it necessary, else you just punt on portability and only support big/little |
| 17:46.22 | ``Erik | or network i/o, even with smokin' fast network |
| 17:46.41 | brlcad | exactly.. that's all utterly dwarfed |
| 17:46.41 | Maloeran | But during distributed processing, the nodes don't necessary "block" waiting for the data to arrive, they can be kept busy with previously queued work |
| 17:48.25 | Maloeran | The impact might be small, but it wasn't much more trouble in the code either. I'm sure it will be quickly fixed as soon as I can see a big endian cache |
| 17:48.41 | brlcad | er, I wouldn't have imagined that you'd make the processing nodes swap bytes - whatever *actually* reads/writes to disk would |
| 17:49.02 | brlcad | which with distributed, would be a different node, so the non-blocking becomes irrelevant |
| 17:49.40 | ``Erik | brlcad, are you in the office today? |
| 17:49.47 | brlcad | the other point is that hton*() functions aren't just little/big endian -- there are other formats |
| 17:49.59 | brlcad | ``Erik: no |
| 17:50.02 | ``Erik | bah |
| 17:50.05 | Maloeran | I see, I didn't really consider other formats |
| 17:50.29 | ``Erik | hrm |
| 17:50.41 | ``Erik | been a long time since I've heard of any of the other formats, like 'middle' endian |
| 17:51.45 | brlcad | this is true, it's a minor consideration, but part of the overall purpose and portability |
| 17:53.56 | brlcad | aside from the other reasons mentioned .. I mean eventually something is effectively doing a write()/read() .. |
| 17:54.34 | ``Erik | heh, "bits is bits" at the end of the day, yes :) |
| 17:55.47 | brlcad | i can understand a "don't want to do it", or "don't like it" even, or one of several other reasons, but just not in the namesake of performance |
| 17:56.17 | Maloeran | As I said, it's just that the processors are not necessarily idle while receiving data from the network |
| 17:57.00 | Maloeran | Performing byte swapping on network I/O is clearly unnecessary if nodes are of the same endianness |
| 18:00.56 | brlcad | disk, man .. disk! are these caches only in memory or something (a critical detail failed to be mentioned)? |
| 18:02.32 | Maloeran | When doing distributed processing synchronisation, there is no disk I/O involved! |
| 18:02.55 | ``Erik | network i/o can be almost as horrible as disk i/o :) |
| 18:03.30 | ``Erik | now with decent hw and drivers (dma) and "zero-copy" networking we see in SOME os's (um, linux, fbsd, and MAYBE solaris?), that's an offloaded task |
| 18:03.32 | ``Erik | but it's still there |
| 18:03.51 | brlcad | you could have mentioned that earlier (distributed sync has no implication of whether disk is involved) .. though similar holds for network I/O too |
| 18:06.19 | brlcad | and even for in-memory is seriously prematurely-optimizing in a manner that impacts the architecture |
| 18:07.10 | ``Erik | also makes assumptions about the basic paradigms |
| 18:07.12 | brlcad | imho at least, it seems counterproductive to the goal and unnecessarily complicates |
| 18:07.14 | ``Erik | um |
| 18:07.35 | ``Erik | does every node carry a complete copy of the data set? or are nodes specialized? |
| 18:07.49 | ``Erik | is this only a hit at the very beginning? or does it happen through "regular processing"? |
| 18:07.49 | brlcad | but hey, i'm not writing it, so have fun :) |
| 18:07.50 | ``Erik | etc |
| 18:11.18 | *** join/#brlcad Twingy (n=justin@74.92.144.217) [NETSPLIT VICTIM] | |
| 18:18.31 | ``Erik | http://www.wreckedexotics.com/newphotos/weird/weird796.shtml |
| 18:18.36 | ``Erik | holy crap, the driver survived |
| 18:18.55 | ``Erik | at least my dead exotic isn't shown there, heh, yet |
| 18:24.32 | Maloeran | ``Erik, all nodes maitain a complete copy of the data set, any changes on the master node is spread on the network |
| 18:25.07 | Maloeran | Graph caches are used to provide or update graphs, so it happens during "regular processing" if dynamic geometry is involved |
| 18:25.14 | ``Erik | so if I have 79 gigs of triangle data... *cough* O:-) |
| 18:25.34 | Maloeran | In a single model? Then you may have a problem :) |
| 18:26.08 | Maloeran | It just means you won't be able to enable master/slave relationship, instead using "peers" and manage state yourself using different smaller models |
| 18:37.53 | ``Erik | mal! didja grab an update of rtcmp? |
| 20:04.40 | *** join/#brlcad dli (n=dli@400exp229.anlgh.org) | |
| 20:05.12 | dli | can I label dimensions with brlcad? like in the traditional blueprint |
| 20:25.16 | brlcad | dli: not easily -- that's more of a drafting facility than one specific to solid modeling and (as such) hasn't really been well developed |
| 20:25.28 | brlcad | would be a great feature to have though, and not too complicated |
| 20:27.37 | dli | brlcad, yeah, after getting my design, it's a pity that all dimensions are known but not be able to show |
| 20:46.07 | brlcad | not a great solution in the least, but you could add them manually with an image editor, depending on the purpose |
| 20:54.07 | *** join/#brlcad CIA-21 (i=cia@cia.navi.cx) [NETSPLIT VICTIM] | |
| 21:00.15 | Maloeran | Erik, your configure script gave me : "checking for rt_prep in -lrt... no" because it doesn't find tcl. Next, I get tri.c:234: error: too few arguments to function 'bu_realloc |
| 21:00.30 | Maloeran | error: 'nmg_bool_eval_silent' undeclared too |
| 21:26.12 | *** join/#brlcad Elperion (n=Elperion@p54877b4b.dip.t-dialin.net) | |
| 22:07.10 | *** join/#brlcad docelic (n=docelic@212.15.173.175) | |
| 22:11.23 | Maloeran | The undocumented and obscure SDL 1.3 CVS sure is hard to figure how to patch N-buffering, they changed the whole video API |
| 22:19.06 | Maloeran | As far as I can see, they are mostly dropping 2d capabilities, buffer flipping sure is gone |
| 22:51.29 | Maloeran | Grah! Why is ./configure not putting anything in its .h file from a AC_CHECK_FUNCS(SDL_SetScreenSurface) ? It is found : checking for SDL_SetScreenSurface... yes |
| 23:19.03 | Maloeran | ( Solved, deleting the cache did it ) |