| 00:21.26 | *** join/#brlcad infobot (~infobot@rikers.org) |
| 00:21.26 | *** topic/#brlcad is GSoC students: if you have a question, ask and wait for an answer ... responses may take minutes or hours. Ask and WAIT. ;) |
| 02:15.40 | *** join/#brlcad KimK (~Kim__@2600:8803:7a81:7400:7427:11e9:38a:213f) |
| 03:47.01 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-hkjuqzuczvysxpcq) |
| 06:53.04 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 07:11.05 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 07:41.08 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 08:30.04 | *** join/#brlcad DaRock (~Thunderbi@mail.unitedinsong.com.au) |
| 08:48.43 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) |
| 09:53.43 | *** join/#brlcad merzo (~merzo@user-94-45-58-139.skif.com.ua) |
| 10:41.22 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 10:48.41 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 11:18.56 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 13:28.45 | *** join/#brlcad yorik (~yorik@2804:431:f720:80d8:290:f5ff:fedc:3bb2) |
| 14:45.08 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:56.31 | *** join/#brlcad merzo (~merzo@94.45.58.139) |
| 16:59.30 | *** join/#brlcad vasc (~vasc@bl14-42-37.dsl.telepac.pt) |
| 17:00.02 | vasc | hi mdtwenty[m] |
| 17:28.51 | mdtwenty[m] | hey |
| 17:30.31 | mdtwenty[m] | so the other day i tried the goliath scene with a cl_uint[16] bitvector first and it would take too much time to weave the segments |
| 17:32.23 | mdtwenty[m] | so i started to make some changes to the weave kernel to use a list structure instead of the array |
| 17:35.54 | mdtwenty[m] | the solution with the list is fast, but i am still trying to find the cause for some missing partitions when testing with csg scenes evolving difference operations |
| 17:37.45 | vasc | well, the array is slow with your present code for several reasons |
| 17:38.20 | vasc | like that this: |
| 17:38.21 | vasc | + pp = &partitions[offset]; |
| 17:38.21 | vasc | + //iterate over segments of partition |
| 17:38.21 | vasc | + for (uint i = pp->segs_start_index; i < pp->segs_start_index + pp->segs_in_partition; i++) { |
| 17:38.21 | vasc | + if (segs_in_pp[i].seg_sti == st_bit) { |
| 17:38.22 | vasc | + ret = 1; |
| 17:38.24 | vasc | + break; |
| 17:38.26 | vasc | + } |
| 17:38.28 | vasc | + } |
| 17:39.14 | mdtwenty[m] | yes, also inserting partitions on the array |
| 17:40.47 | mdtwenty[m] | the solution with 2 ints to reference the back and forward partition is fast |
| 17:40.59 | mdtwenty[m] | compared with the array version |
| 17:41.07 | vasc | well |
| 17:41.15 | vasc | i don't know if something like that can work really. |
| 17:42.06 | vasc | did you keep the other version you made friday someplace? |
| 17:42.24 | vasc | the one with the bitvector which didn't use whole segs but indexes |
| 17:42.45 | vasc | also |
| 17:43.01 | mdtwenty[m] | yes i made a backup with that version |
| 17:43.11 | vasc | good. keep that just in case. |
| 17:43.24 | vasc | in fact send it to me. |
| 17:45.53 | vasc | the thing is, without profiling the code, it's hard to know it its better to use the list or the bitvector. |
| 17:46.09 | vasc | like, what's the min and max size of the lists, or the average. |
| 17:46.41 | vasc | and how ofter is bu_ptbl_ins_unique used vs a plain list traversal |
| 17:46.44 | vasc | and so on |
| 17:47.51 | vasc | this is something which could be found out by instrumenting the ANSI C code and printing an instruction count out or something like that. |
| 17:48.46 | vasc | you can't optimize the code without knowing the data and the access patterns |
| 17:48.48 | mdtwenty[m] | posted a file: weave_segs_cl_uint16.patch (51KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/gptQETCBWOirrbuoOVcaPlwv> |
| 17:52.09 | vasc | so i think you should instrument the code and this out. |
| 17:52.40 | vasc | 1) what's the min and max size of the lists, and the average. 2) how often is bu_ptbl_ins_unique used vs a plain list traversal. |
| 17:53.07 | vasc | i suspect the list is only traversed in the bool_eval phase. |
| 17:53.57 | vasc | right. take this example code: |
| 17:53.59 | vasc | + pp = &partitions[offset]; |
| 17:53.59 | vasc | + //iterate over segments of ray |
| 17:53.59 | vasc | + for (uint k=h[id]; k!=h[id+1]; k++) { |
| 17:53.59 | vasc | + if ((pp->segs[(k-h[id])/32] & (1 << (k - h[id]) % 32)) != 0) { |
| 17:53.59 | vasc | + RESULT_TYPE segp = segs+k; |
| 17:54.00 | vasc | + if (segp->seg_sti == st_bit) { |
| 17:54.02 | vasc | + ret = 1; |
| 17:54.04 | vasc | + break; |
| 17:54.06 | vasc | + } |
| 17:54.08 | vasc | + } |
| 17:54.10 | vasc | + } |
| 17:54.12 | vasc | you're gonna execute this for every partition right? |
| 17:54.21 | mdtwenty[m] | yes |
| 17:54.31 | mdtwenty[m] | it checks for every partition |
| 17:54.39 | vasc | this is too slow i think this would be faster if the loop was inverted. |
| 17:55.21 | vasc | forall i in 0..15 |
| 17:55.59 | vasc | you check if there are set bits in that bitvector, and if there are |
| 17:56.26 | vasc | then you check if that segment's seg_sti is equal to the st_bit |
| 17:56.47 | vasc | it seems slow right? coz its 16*32 iterations |
| 17:56.54 | vasc | but it's a sparse bitvector |
| 17:57.13 | vasc | so you don't need to iterate over all bits, just the ones that are one |
| 17:57.32 | mdtwenty[m] | yes i could try that |
| 17:57.37 | vasc | you can use popcnt to know how many bits are set. |
| 17:57.52 | vasc | even better use ffs. |
| 17:58.03 | vasc | there isn't an ffs function in opencl but you can do one with clz. |
| 17:58.08 | vasc | i mean |
| 17:59.23 | vasc | like |
| 17:59.44 | vasc | you iterate the bitvector |
| 17:59.56 | vasc | and for each segs[i] |
| 18:00.07 | vasc | you use clz(pp->segs[i]) |
| 18:00.41 | vasc | and while its != 32 |
| 18:00.51 | vasc | you extract that bit and test it |
| 18:01.05 | vasc | or something like that. |
| 18:01.34 | mdtwenty[m] | hm yeah i will try that |
| 18:01.35 | vasc | i think clz is like 1-cycle. |
| 18:02.11 | vasc | its not perfect but it should be less bad. |
| 18:02.23 | vasc | we need to profile the code to know if its better to build the list or not. |
| 18:02.26 | mdtwenty[m] | but i also think that one of the problems is with inserting partitions in the partitions array |
| 18:02.32 | mdtwenty[m] | at least for huge scenes like the goliath |
| 18:02.55 | vasc | possibly. for that you need to use a linked-list instead of an array i guess. |
| 18:03.29 | vasc | the ANSI C code uses double-linked lists but i think you only need a single-linked list. |
| 18:04.30 | vasc | but i'm not sure. |
| 18:05.13 | vasc | so you're working on that? |
| 18:05.24 | mdtwenty[m] | i started implementing a list to store the partitions, and the goliath scene would only take 0.55 sec or something IIRC, against the 40+ sec with the array version |
| 18:06.25 | vasc | nice. |
| 18:06.32 | mdtwenty[m] | there is still some issues with some missing partitions for scenes with difference operators |
| 18:06.52 | vasc | show me the code and i can help debug if you want. |
| 18:09.27 | mdtwenty[m] | 1 sec |
| 18:14.05 | *** join/#brlcad ``Erik (~erik@pool-100-16-14-17.bltmmd.fios.verizon.net) |
| 18:15.49 | mdtwenty[m] | posted a file: weave_partitions_list.patch (53KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/aTomIMyTJtdGIWEZhzxmrMne> |
| 18:15.52 | mdtwenty[m] | ok this should be it |
| 18:16.15 | mdtwenty[m] | is still a work in progress |
| 18:19.54 | mdtwenty[m] | intersections and unions seems to be working |
| 18:20.43 | mdtwenty[m] | at least with the simple scenes that i have for testing |
| 18:21.12 | mdtwenty[m] | but without rt_boolfinal implemented it is hard to test with other scenes |
| 18:22.50 | vasc | seems kinda wonky |
| 18:28.13 | vasc | take this: |
| 18:28.14 | vasc | <PROTECTED> |
| 18:28.15 | vasc | + uint start_index = 2 * h[id]; |
| 18:28.15 | vasc | + tail_pp = append_partition_pp(partitions, ipartition, id, start_index); |
| 18:28.15 | vasc | +uint append_partition_pp(global struct partition *partitions, global uint *ipartition, size_t id, uint start_index) |
| 18:28.15 | vasc | +{ |
| 18:28.17 | vasc | + uint new = start_index + ipartition[id]; |
| 18:28.19 | vasc | + uint old = start_index + ipartition[id] - 1; |
| 18:28.21 | vasc | + |
| 18:28.23 | vasc | + if (ipartition[id] == 0) { |
| 18:28.25 | vasc | + //No partitions yet |
| 18:28.27 | vasc | + partitions[new].back_pp = new; |
| 18:28.29 | vasc | + partitions[new].forw_pp = new; |
| 18:28.31 | vasc | + return start_index; |
| 18:28.33 | vasc | + } |
| 18:28.35 | vasc | + |
| 18:28.37 | vasc | + partitions[new].back_pp = old; |
| 18:28.39 | vasc | + partitions[new].forw_pp = new; |
| 18:28.41 | vasc | + partitions[old].forw_pp = new; |
| 18:28.43 | vasc | + return new; |
| 18:28.45 | vasc | +} |
| 18:28.47 | vasc | why not call as append_partition_pp(partitions+start_index, ipartition, id); instead? |
| 18:28.55 | vasc | that would eliminate one variable. |
| 18:29.17 | vasc | as for the code in append_partition_pp.... |
| 18:30.15 | vasc | while it's not the case in this particular instruction |
| 18:30.26 | vasc | i thought you needed to insert the element at the end? |
| 18:30.53 | vasc | unless you're doing this like a C++ linked list |
| 18:31.08 | vasc | with a bogus node on the beggining which points to the end and start of list or something. |
| 18:32.14 | vasc | also you could just pass ipartition[id] since you never use each value seperately. |
| 18:32.54 | vasc | oh right. |
| 18:33.01 | vasc | ipartition says how many partitions there are |
| 18:33.04 | mdtwenty[m] | noted! and yes i use only the functions to update the back_pp and forw_pp values |
| 18:33.05 | vasc | so it points to the end of list |
| 18:33.15 | vasc | well |
| 18:34.14 | vasc | i disagree with this: |
| 18:34.15 | vasc | <vasc> + if (ipartition[id] == 0) { |
| 18:34.15 | vasc | <vasc> + //No partitions yet |
| 18:34.15 | vasc | <vasc> + partitions[new].back_pp = new; |
| 18:34.15 | vasc | <vasc> + partitions[new].forw_pp = new; |
| 18:34.15 | vasc | <vasc> + return start_index; |
| 18:34.17 | vasc | <vasc> + } |
| 18:34.32 | vasc | i think should be partitions[new].back_pp = partitions[new].forw_pp = 0; |
| 18:34.52 | vasc | if there's nothing else in the list there's no next or prev node. |
| 18:36.04 | vasc | in fact its better to just |
| 18:36.22 | vasc | i think should be partitions[start_index].back_pp = partitions[start_index].forw_pp = 0; |
| 18:36.30 | vasc | makes it more explicity |
| 18:36.35 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 18:36.37 | vasc | ^H |
| 18:36.59 | vasc | and this: |
| 18:37.07 | vasc | <vasc> + partitions[new].back_pp = old; |
| 18:37.07 | vasc | <vasc> + partitions[new].forw_pp = new; |
| 18:37.07 | vasc | <vasc> + partitions[old].forw_pp = new; |
| 18:37.10 | vasc | i think it should be |
| 18:37.33 | vasc | + partitions[new].back_pp = old; |
| 18:37.33 | vasc | + partitions[new].forw_pp = 0;+ partitions[old].forw_pp = new; |
| 18:37.39 | vasc | or something |
| 18:38.06 | vasc | the circular references are kinda weird. |
| 18:38.21 | vasc | so you basically know if its the end or start of the list because of the circular reference? |
| 18:38.23 | mdtwenty[m] | yes and i think the issue comes from that |
| 18:38.48 | mdtwenty[m] | ye that was my idea |
| 18:39.17 | vasc | it can be done that way i guess, but usually we just say there's no next or prev with a null pointer. |
| 18:39.19 | vasc | hm |
| 18:39.23 | vasc | now that i think about it |
| 18:39.34 | vasc | 0 itself is a valid position in our case |
| 18:39.39 | vasc | so you would have to use -1 or something |
| 18:39.44 | vasc | or MAX_INT |
| 18:40.30 | vasc | MAX_UINT ~0 |
| 18:40.42 | vasc | i guess your way also works |
| 18:40.53 | vasc | its just not very conventional... |
| 18:42.01 | mdtwenty[m] | and i am having trouble when there is only 1 partition |
| 18:43.55 | mdtwenty[m] | i think it makes more sense having the forw and back set to 0 if there is no previous/next partition |
| 18:45.05 | vasc | nah i can't be 0 because 0 is also a valid position |
| 18:45.07 | vasc | it |
| 18:45.37 | mdtwenty[m] | j = partitions[head_pp].back_pp; j != partitions[j].forw_pp; j = partitions[j].forw_pp) |
| 18:45.41 | vasc | your way of doing it with the circular references is ok. |
| 18:45.59 | mdtwenty[m] | when there is only 1 partition this for doenst work |
| 18:46.46 | vasc | wtf. |
| 18:47.11 | vasc | hm |
| 18:48.43 | vasc | well |
| 18:48.55 | vasc | the thing is your current code always skips the last element of the list from i see. |
| 18:49.20 | vasc | instead of using a while you need to use a do loop. |
| 18:49.26 | vasc | and you need to check for an empty list. |
| 18:49.29 | vasc | or something like that. |
| 18:51.02 | vasc | if its a one element list it skips the one element. or would it you didn't have that ipartition[id] == 1 check in there. |
| 18:51.13 | vasc | but in lists > 1 it skips the last element in the list as well. |
| 18:53.22 | mdtwenty[m] | hm yes i see that |
| 18:53.53 | vasc | or terminate the list with something other than a circular reference. |
| 18:54.29 | vasc | otherwise you can't disambiguate between the last element and being past the last element. |
| 18:54.53 | vasc | without extra checks. |
| 18:55.39 | vasc | we can use 0 because its also a valid position |
| 18:55.41 | vasc | so |
| 18:55.46 | vasc | MAX_UINT |
| 18:56.04 | vasc | is NULL |
| 18:57.39 | ``Erik | sweet jeebus, use a pastebin |
| 18:58.12 | vasc | we can talk private if you want. |
| 18:58.27 | vasc | its just too small to use pastebin. |
| 18:58.47 | ``Erik | public is good, but for gobs of code, chuck it on a paste bin (even if it's 3 lines) and shoot a link, then do edits/mods there or something :) |
| 18:59.35 | vasc | that's the thing though. I don't want to write code for him. :-) |
| 18:59.38 | vasc | just comment on it. |
| 18:59.55 | vasc | i'm kinda overdoing it though i guess. |
| 19:00.11 | ``Erik | if these back_pp and forw_pp linked list things are using the BRL-CAD linked list "stuff", there are macros for handling them, including an iterator iirc |
| 19:01.37 | ``Erik | BU_LIST_FOR() et al... include/bu/list.h |
| 19:02.44 | mdtwenty[m] | this is opencl code |
| 19:03.58 | ``Erik | ah, 'k, cool, n/m me O:-) *wanders back off* |
| 19:05.02 | vasc | we should make some macros eventually. |
| 19:05.46 | vasc | or at least inline functions. |
| 19:09.16 | vasc | we can't directly port the libbu macros. we don't have malloc(). |
| 19:09.29 | vasc | and we don't wanna do a malloc per node either. |
| 19:10.00 | vasc | memory allocation in opencl is done on the host code. |
| 19:10.10 | vasc | the device just uses memory. |
| 19:35.43 | *** join/#brlcad ChanServ (ChanServ@services.) |
| 19:35.43 | *** mode/#brlcad [+o ChanServ] by card.freenode.net |
| 19:40.34 | mdtwenty[m] | ok good news.. fixed the issues with that cycle and the code now seems to be working for all the test scenes i am using |
| 19:42.51 | mdtwenty[m] | i will add the code for the dynamic bit vector and optimize the bool_eval and will upload the patch later tonight |
| 19:43.27 | mdtwenty[m] | optimize the bool_eval = inverting the cycle as you suggested |
| 19:46.44 | vasc | okay |
| 20:34.27 | ``Erik | mdtwenty[m]: remember to test edge cases (last element, first element, after the last, before the first, ...) :) |
| 20:34.53 | ``Erik | vasc: port malloc? :D it ain't magic *duck* :) |
| 20:36.06 | vasc | well, it's a performance hog to call it too often. |
| 20:36.18 | vasc | we're better off with regular memory pools. |
| 20:38.56 | vasc | malloc and free need to have support for variable blocks, degrag, etc, this has a negative performance impact. |
| 20:39.14 | vasc | defrag |
| 20:47.20 | Stragus | I think of malloc/free like the rand() of memory management. Useful to get started, not for real code |
| 20:47.41 | Stragus | wrote his own memory manager about a decade ago and never looked back |
| 20:48.25 | vasc | most of the time it's not necessary to have something which supports variable sized blocks anyway. |
| 20:49.02 | Stragus | Indeed, and if all you need are constant sized blocks, you can have an overhead approaching zero bytes per block |
| 20:49.11 | vasc | yes. |
| 20:49.12 | Stragus | malloc() is darn wasteful |
| 20:49.45 | vasc | it's also a problem if you call it once per element, because of all the possible system calls. |
| 20:50.04 | vasc | malloc implementations themselves usually buffer things. |
| 20:51.01 | vasc | but malloc isn't omniscient. the programmer usually has more details on the type of memory uses to make something better than that. |
| 20:51.09 | Stragus | And that behavior depends on the libc/OS. Linux loves to buffer things for higher malloc() performance, FreeBSD and Windows free aggressively |
| 20:51.28 | ``Erik | O.o your malloc doesn't have to smell or look anything like the unix alloca malloc (which is generally split into like 4 different impls, with phkmalloc and whatever the one glibc/linux uses as the two big open source ones) |
| 20:51.44 | vasc | first game i programmed on was an ANSI C MUD, it came with its own custom allocator because of that. |
| 20:51.57 | ``Erik | like a diku? |
| 20:52.01 | ``Erik | or circle? |
| 20:52.04 | Stragus | Bottom line, use your own memory manager, and make it NUMA-aware |
| 20:52.11 | vasc | yes. a Diku Merc Envy MUD. |
| 20:53.03 | vasc | i ran one of the MUDs in our campus. |
| 20:53.39 | vasc | so i programmed custom classes and things like that. |
| 20:53.53 | vasc | first time I did socket programming. |
| 20:55.06 | ``Erik | Stragus: I'd say that's bad advice for most programmers, most aren't able to do it better than the system and will introduce unnecessary and difficult bugs attempting, and the few that can will probably never hit that situation... you do weird shit, not everyone is as weird as you... :D |
| 20:55.44 | vasc | malloc is a nice tool to have, but i think a memory pool abstraction would have been good enough for most people. |
| 20:56.07 | ``Erik | off to the library and day care with me, Excelsior! https://www.youtube.com/watch?v=otOARxAOp2g |
| 20:56.09 | gcibot | [ Excelcior!.wmv - YouTube ] |
| 20:57.43 | Stragus | ``Erik: Then people should use whatever is written by people who know that stuff. :) No use should rand() either, people grab the Mersenne Twister or any other fancy RNG of the day |
| 20:58.23 | vasc | problem with RNG is like you said with malloc, quality of implementation between OSes varies quite a lot. |
| 20:59.11 | vasc | funilly enough, that MUD also had its own custom RNG... |
| 20:59.58 | vasc | also its own custom string allocator. |
| 21:00.03 | Stragus | I'll agree that rand() is a lot far worse than malloc() |
| 21:00.43 | vasc | Shared String Manager i think was the name they gave it. |
| 21:01.34 | vasc | i've also seen games have their own disk I/O functions and things like that. |
| 21:03.08 | Stragus | Of course. Any reasonable game should have a thread dedicated to asynchronous disk I/O |
| 21:04.09 | vasc | the network code in that MUD disabled naggle and did its own buffering. |
| 21:05.05 | vasc | that was kind of fun afterwards in classes. |
| 21:05.11 | Stragus | That Naggle buffering is terrible. You can feel the 200ms delay |
| 21:05.39 | vasc | we had to write a non-blocking program. like everyone did it with UDP, and i did it with non-block TCP |
| 21:06.03 | vasc | the teacher was kinda amazed i thought about it (we didn't learn that in class) |
| 21:06.17 | vasc | well i had seen it before... |
| 21:06.45 | Stragus | I once wrote an online game too, browser-based... but it was entirely written from scratch in C, it was its own HTTP server |
| 21:06.56 | vasc | cool. |
| 21:07.04 | vasc | i thought about doing something like that once. |
| 21:07.13 | Stragus | Kind of crazy, it was so demanding in time and energy that I just gave it up one day |
| 21:07.17 | vasc | MUDs are basically a sort of telnet server usually. |
| 21:07.25 | Stragus | Also, I didn't know what I was doing so the code was terrible |
| 21:07.44 | vasc | well HTTP has a lot of its own verbiage I guess. |
| 21:07.57 | Stragus | Well, HTTP was just a tiny piece of the whole thing |
| 21:09.16 | vasc | i thought about rewriting an http server, like lighthttpd or whatever it was called, or make an apache module out of it :-) |
| 21:09.26 | vasc | or making an CGI |
| 21:09.53 | Stragus | People expect a lot more interactivity from games these days |
| 21:10.00 | Stragus | Mine generated HTML 3.0 stuff, eh |
| 21:10.17 | vasc | well, those browser game can still be quite popular |
| 21:10.22 | Stragus | It had a few thousand players (up to 2002 or so?), and I actually changed my online nickname because I felt bad answering questions from people who knew about it and asked where I had disappeared |
| 21:10.34 | vasc | heh |
| 21:10.40 | Stragus | Administrating an online game is a _lot_ of trouble |
| 21:10.59 | vasc | i had enough trouble with like 100 college MUD players. |
| 21:11.22 | vasc | when I was a Freeciv administrator we did have a game server... but I wasn't the main guy administrating it so... |
| 21:12.04 | vasc | still I think it was useful to interact with the game players to figure out where to advance the game next, so I guess I messed with it more than the average maintainer. |
| 21:12.10 | Stragus | I had set up an alert where the mods could make my computer play music to wake me up in the middle of the night if there was some serious problem/bug needing attention |
| 21:12.22 | vasc | sheesh. |
| 21:12.48 | vasc | i just let it crash and restarted it later :-) |
| 21:13.05 | vasc | that's one good thing about games, people know stability isn't always up to scratch :-) |
| 21:13.19 | Stragus | You feel bad about that when you have 4000 players logging in many times a day :) |
| 21:13.38 | Stragus | So yes, it was way too stressful, but it was a good learning experience |
| 21:13.40 | vasc | we did have an auto-restart script. |
| 21:14.19 | vasc | and perioric saves. |
| 21:14.23 | vasc | periodic |
| 21:14.45 | vasc | one of the first things I did with Freeciv was rewriting the network code. |
| 21:14.51 | vasc | it didn't use non-blocking sockets. |
| 21:14.55 | Stragus | Darn |
| 21:15.18 | vasc | it was really bad because it has simultaneous moves. |
| 21:15.45 | vasc | sometimes people had lousy dial-up connections, their connection froze, and the OS timer was like 5 minutes. |
| 21:15.54 | vasc | until it disconnected them. |
| 21:15.56 | Stragus | My HTTP thing was a single thread, non-blocking sockets. It ran pretty smoothly, the whole universe "ticks" were taking 5 seconds (so the server would delay HTTP requests for 5 seconds every 10 minutes) |
| 21:16.31 | vasc | yeah if it's well programmed its quite amazing the amount of connections you can multiplex with non-block TCP. |
| 21:16.45 | vasc | people dismiss it too easily. |
| 21:17.07 | Stragus | Well, you don't really want to go beyond a thousand sockets per thread |
| 21:17.21 | vasc | Freeciv only has like, I dunno the limit now, but usually people played with like 16 player or 8. |
| 21:17.59 | Stragus | I tried Freeciv and disliked many things about the gameplay |
| 21:18.21 | vasc | well i only enhanced it, i wasn't one of the original authors :-) |
| 21:18.31 | Stragus | :) Right |
| 21:18.47 | vasc | i wrote a game client basically. |
| 21:18.58 | vasc | at least that's how i started. |
| 21:19.15 | Stragus | I still occasionally get brief dreams about writing a game. The last time was in 2013, I did that: http://www.rayforce.net/newproject024.png |
| 21:19.34 | vasc | there's a lot of things i didn't like but it became really hard to refractor it without breaking backwards compatiblity. |
| 21:19.48 | Stragus | The hydrography is actually computed by darn Computation Fluid Dynamics, with a water cycle and underground flow |
| 21:20.03 | vasc | it looks nice. |
| 21:20.35 | Stragus | I think I am way too perfectionist to ever finish something |
| 21:20.50 | vasc | that's half the work to do a simple flight sim or strategy god game. |
| 21:21.19 | Stragus | These trees? http://www.rayforce.net/newproject032.png - Procedurally generated from 200k triangles, then reduced by an algorithm to an optimal set of just 8 triangles to represent the best geometry with the least distorsion possible |
| 21:21.32 | Stragus | And that algorithm was like 7k lines |
| 21:22.00 | Stragus | I need to learn _not_ to aim for the best job I can do. Because it takes too darn long |
| 21:22.05 | vasc | well good foliage can be really complicated. that's why most game engines used SpeedTree SDK... |
| 21:22.23 | vasc | and i'm saying game engines not games. |
| 21:22.58 | Stragus | I have a hard time using people's code, when I feel like I could write better |
| 21:23.07 | Stragus | The problem is that "writing better" can take months |
| 21:23.32 | vasc | i've wanted to design my own computer programming language more than once. |
| 21:23.45 | vasc | it's not like i haven't written a compiler before. |
| 21:24.14 | Stragus | I wouldn't personally go down that route |
| 21:24.18 | Stragus | hugs and cuddles C |
| 21:24.46 | vasc | well i've written design specs more than once. but never actually liked one of my language designs enough to go through with it. |
| 21:25.34 | Stragus | I would add a few keywords to the C language, to provide more contextual information to the compiler to produce better assembly |
| 21:25.39 | Stragus | But I wouldn't write a new language |
| 21:26.38 | vasc | well. |
| 21:27.00 | vasc | i had like module declaration and implementation like Modula-2, syntax like C, advanced array support. |
| 21:27.10 | vasc | and I think I added SIMD to the specs. |
| 21:27.44 | Stragus | GNU C has vector extensions |
| 21:27.53 | Stragus | thinks of GNU C as the one true C |
| 21:27.57 | vasc | it does. but opencl is a lot better. |
| 21:28.37 | Stragus | Yes well, that targets different hardware, with completely different approaches and algorithms |
| 21:30.23 | vasc | I mixed Pascal/Modula-2 and C |
| 21:30.25 | vasc | so it was like |
| 21:31.03 | vasc | func xpto(a, b, c: int) : (a, b: int) |
| 21:31.25 | vasc | {} |
| 21:32.07 | Stragus | Any advantage over C besides a different syntax? :) |
| 21:32.36 | vasc | like you can see it supports multiple value return in functions. |
| 21:32.44 | vasc | even if it's just syntatic sugar anyway.. |
| 21:32.50 | vasc | you can do that with a C struct. |
| 21:32.57 | Stragus | Multiple return values is good |
| 21:33.45 | Stragus | I wish C also had statements like break continue; instead of having to use goto |
| 21:34.08 | vasc | i think i had that at one point, like break 2; or something. |
| 21:34.11 | Stragus | And __attribute__((__may_alias__)) should be in the standard instead of that silly union thing |
| 21:34.31 | vasc | but it seemed kinda messed up. |
| 21:35.35 | vasc | i agree that it would be better to have some more control flow mechanisms. |
| 21:36.08 | vasc | i can't say i'm a fan of C declarations though. or should I say C++ declarations. |
| 21:36.17 | vasc | because if you look at K&R declarations they're nothing like that. |
| 21:36.25 | Stragus | And I really would like to be able to tell the compiler the probability of each branch |
| 21:36.44 | Stragus | __builtin_expect() is too absolute, it's like 100% or 0% |
| 21:37.04 | Stragus | And compilers should obey the "register" keyword, darn it |
| 21:37.32 | vasc | thing is sometimes there's register spills. so the compiler disables or ignore the hint. |
| 21:37.51 | Stragus | And if you have a switch() without a default case and the input value isn't handled, it should be undefined behavior |
| 21:38.06 | Stragus | I don't want a darn bound check every time I put a switch() |
| 21:38.12 | ``Erik | pats swift O:-) |
| 21:38.35 | Stragus | vasc: The hint is just ignored now because "compilers know better" |
| 21:39.21 | vasc | well I looked at Nim some time ago ``Erik but it just seemed to have an overly complicated syntax. |
| 21:39.49 | vasc | as for Swift is seems layered on top of the rest of the Apple runtime. |
| 21:39.51 | vasc | it |
| 21:40.42 | Stragus | I want more low-level control, and all new fancy languages "designed to replace C" tend to move _away_ from that |
| 21:40.44 | vasc | and Go has a garbage collector so... |
| 21:40.52 | vasc | exactly. |
| 21:41.00 | vasc | they're pseudo-systems programming languages. |
| 21:41.13 | vasc | they're Java wannabees rather than C replacements. |
| 21:41.24 | ``Erik | nim kinda smells pythony |
| 21:41.40 | vasc | like Go, it seems to be used mostly for what Java was used, network servers and the ilk. |
| 21:42.00 | ``Erik | vasc: yeh, I've been doing ios code lately, so apple stack, arm cpu, etc... |
| 21:42.10 | vasc | oh right forgot to mention Rust |
| 21:42.17 | ``Erik | common lisp on the back end because I'm twisted |
| 21:42.34 | vasc | i actually liked Common Lisp. |
| 21:42.57 | vasc | you might hate it or love it, but the syntax makes sense for what it does. |
| 21:43.06 | vasc | and it just feels right. |
| 21:43.27 | vasc | problem is when you have to interact with the rest of the system, quite often its designed in C. |
| 21:44.43 | vasc | oh right the complicated syntax is Rust, not Nim |
| 21:45.11 | vasc | Nim's issue is garbage collection |
| 21:46.02 | vasc | whenever someone claims to have written a "systems programming language" and then they add a garbage collector the features list. |
| 21:46.09 | vasc | it's a hint they don't have a freakin clue. |
| 21:46.51 | vasc | i mean its nice to just ignore memory allocation on a lot of programs |
| 21:47.02 | vasc | but not on systems. |
| 21:48.05 | vasc | i can guess what Linus would say about rewriting the kernel to use a garbage collected language. |
| 21:48.55 | vasc | and as much as I hate Wirth, at least he followed people's advice and actually tried to write an OS kernel with his later languages. |
| 21:49.59 | vasc | which is why Module-2 is so much better than Pascal. except it was too late for people to care about it. |
| 21:50.03 | vasc | Modula-2 |
| 21:53.05 | vasc | other than C and OpenCL i like Python and Lisp |
| 21:53.27 | vasc | Java is kinda ok. |
| 21:53.47 | vasc | the frameworks are mostly horrible, horrible. |
| 21:54.25 | vasc | Java itself, I think its good for what it was designed for, the only wart is the type system. |
| 22:01.38 | vasc | oops gotta go |
| 22:24.22 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 22:32.11 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:08.16 | Stragus | Woohoo, the first AMD Epyc motherboard is out, no dual-socket yet... It supports 1 tetrabyte of RAM though, and 7 PCIe slots for a couple GPUs |
