| 00:12.08 | starseeker | brlcad: could this be involved with the timespec business? https://sourceware.org/bugzilla/show_bug.cgi?id=21371 |
| 00:12.10 | gcibot | [ 21371 â Missing timespec definition when compiled with _XOPEN_SOURCE and _POSIX_C_SOURCE ] |
| 00:41.12 | starseeker | Stragus: what is the mtSignalWaitTimeout function trying to accomplish? |
| 00:43.33 | starseeker | brlcad: unless I'm misreading this, cnd_timedwait is a C11 function: http://en.cppreference.com/w/c/thread/cnd_timedwait |
| 00:43.33 | gcibot | [ cnd_timedwait - cppreference.com ] |
| 00:45.58 | starseeker | winces - bit of a rabbit hole here... |
| 00:50.23 | Stragus | It waits on a condition variable with a timeout |
| 00:50.45 | Stragus | It's my wrapper for pthreads/winthreads, hence the unusual terminology |
| 00:51.27 | Stragus | C11 threads aren't supported by many compilers... besides, a thin inline wrapper that works "everywhere" is trivial |
| 00:52.31 | Stragus | Not sure what version you got, but here's current: http://www.rayforce.net/mmthread.h |
| 00:54.34 | starseeker | yeah, that looks very different from src/librt/primitives/bot/gct_decimation/auxiliary |
| 00:55.26 | starseeker | Stragus: we're planning to bump the minimum standards after the next release to C++11 and as much as C11 as works with MSVC - once we do that, hopefully it'll be easier to integrate your newer code |
| 00:56.11 | Stragus | Cool. I'm usually all C99 with optional GNU and MSVC extensions, and some kind of fallback without either |
| 00:57.49 | starseeker | ah, right... could be C99 or C11 I guess |
| 00:58.06 | starseeker | C++11 for sure |
| 00:59.03 | Stragus | I very much prefer C unless I'm forced to go C++ (I like when the code is explicit, and does exactly what it shows and nothing else) |
| 01:00.27 | Stragus | It would be fun to contribute something to BRL-CAD... Preferably paid work, otherwise it would be pieces that I write for myself |
| 01:00.45 | Stragus | has been writing a high performance fancy PBR OpenGL engine lately |
| 01:03.22 | starseeker | cool! |
| 01:21.12 | *** join/#brlcad drmjsxpcunzonmcr (~armin@dslb-088-065-184-243.088.065.pools.vodafone-ip.de) |
| 02:26.47 | starseeker | well, so far, I can't find a way to spoof this that both tinycthread and librt will accept |
| 02:30.55 | Stragus | tinycthread eh, any reason for that? |
| 02:31.42 | Stragus | A simple .h wrapper around pthreads/winthreads works great, no libraries needed |
| 02:50.28 | starseeker | Stragus: preferred to outsource it if possible and use a C standard(ish) API |
| 02:50.48 | starseeker | unfortunately, it would seem the rest of the world has moved on from C90 for some odd reason |
| 02:53.21 | starseeker | brlcad: I'm not seeing an easy answer - if I'm understanding this correctly the bu_timer doesn't have the right functionality for what Stragus wants here |
| 02:54.16 | Stragus | What do I want? gettimeofday() for pthread_cond_timedwait()? |
| 02:54.41 | starseeker | you mentioned condition variable with a timeout |
| 02:54.48 | Stragus | Ah, yes |
| 02:55.06 | Stragus | That seems like a very basic thing to have in any threading API |
| 02:55.36 | starseeker | sure - and probably a pthreads + Win32 threads implementation is quite possible |
| 02:56.07 | starseeker | that may even be what your new mmthread.h offers, but retrofitting it to the existing code in librt may or may not be straightforward |
| 02:56.56 | Stragus | You are certainly welcome to use the latest mmthread.h above, even the Winthreads backend requires something like... Windows 98 |
| 02:58.04 | starseeker | nods - the problem here is this is looking like an increasingly non-trivial effort to support a standard we want to get off of for a feature that's not really production ready at the moment |
| 02:58.43 | starseeker | for this feature I'd rather try to get your newer version of the code in and working if I was going to tangle with it in a big way |
| 02:58.50 | starseeker | from what I recall you made a lot of improvements |
| 02:59.14 | starseeker | but I sure don't want to do that until we get off of C90, and that's what's apparently causing a problem here |
| 02:59.29 | Stragus | All right |
| 02:59.50 | starseeker | so I'm faced with a bit of a dilemma |
| 03:01.43 | starseeker | Stragus: I can't remember - do you usually turn on all the pedantic compiler warnings? |
| 03:02.41 | Stragus | I don't test beyond -Wall -std=c99 |
| 03:03.00 | starseeker | ah - ok |
| 03:03.01 | Stragus | Or -std=c89 actually, when trying to make code compile with MSVC |
| 03:05.12 | Stragus | I don't think you'll touch that with a 10 feet pole, but here's something else I use and love, atomics: http://www.rayforce.net/codedump/mmatomic.h http://www.rayforce.net/codedump/mmatomic-gnucx86.h http://www.rayforce.net/codedump/mmatomic-gnuc.h http://www.rayforce.net/codedump/mmatomic-msvc.h |
| 03:05.46 | Stragus | With backends of x86/amd64 assembly, GNU sync, MSVC interlocked, etc. |
| 03:08.05 | starseeker | Stragus: very cool |
| 03:09.31 | starseeker | Stragus: it's not so much that I don't want to look into these things - it's more that we need to get out of the quickstand of ancient standards first |
| 03:10.00 | Stragus | Sure, right |
| 04:00.00 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 05:02.57 | brlcad | seems simple enough .. the first problem was calling timespec_get() which can be changed to gettimeofday(). cnd_timedwait() didn't come up yet, but also simple enough to deal with. looks like part of the motivation for tinycthread is somewhat covered in this newer version of mmthread.h too. |
| 08:48.13 | *** join/#brlcad gabbar1947 (uid205515@gateway/web/irccloud.com/x-utarplinktshxmkq) |
| 08:52.44 | *** join/#brlcad merzo (~merzo@211-23-133-95.pool.ukrtel.net) |
| 08:54.34 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 09:00.44 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 10:36.48 | Stragus | Eh, GCC 7.1 does a decent job at auto-vectorization when you give it a proper memory layout designed for SIMD, and telling it pointers are aligned with __builtin_assume_aligned() |
| 10:37.29 | Stragus | The unreadable intrinsics path is... 23% faster, yay |
| 10:43.16 | *** join/#brlcad teepee- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 11:03.11 | *** join/#brlcad merzo (~merzo@185.39.197.205) |
| 13:15.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:29.27 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-ledjafxhmtrarvlj) |
| 13:32.52 | brlcad | yep, there's been a lot of effort in that area the past few years |
| 13:33.21 | brlcad | that's why I've been pressing hard to get rid of aliasing in brl-cad ... that shuts off autovec wholesale |
| 13:36.04 | Stragus | Indeed. I always have been a big fan of C99's restrict, now I'm a big fan of __builtin_assume_aligned() |
| 13:42.48 | Stragus | Okay... Nevermind that, my intrinsics were only 23% faster because GCC and -ffast-math turned some sqrt() and divisions into approximates |
| 13:45.31 | starseeker | there are more issues with C90 gct than just tinycthread, looks like... |
| 13:47.31 | starseeker | or maybe it's the older POSIX standard |
| 14:48.57 | starseeker | wow... https://www.youtube.com/watch?v=j9uRckJLqLk |
| 14:48.57 | gcibot | [ The 3D-Printed Curta Calculator - YouTube ] |
| 16:06.06 | *** join/#brlcad amarjeet (~amarjeet@27.34.244.249) |
| 16:08.26 | *** join/#brlcad amarjeet_ (~amarjeet@27.34.244.249) |
| 16:27.52 | *** join/#brlcad yorik (~yorik@2804:431:f721:6f54:2268:9dff:fef9:3113) |
| 16:56.02 | starseeker | Stragus: out of curiosity, does mmthread implement the C11 API for threads or is that API not ideal for performance situations? |
| 17:01.03 | *** join/#brlcad DenisP (d40d70a2@gateway/web/freenode/ip.212.13.112.162) |
| 17:21.47 | starseeker | phew - OK, at least locally, I'm building again with r70833 |
| 17:31.51 | starseeker | sigh... scanning online, it seems the concensus is that C11 threads haven't taken off and pthreads+win32 wrapping is still the preferred approach for C |
| 18:02.34 | Stragus | starseeker: The C11 threads API is far from universally supported |
| 18:02.49 | Stragus | There is no compiler on Windows that implements them as far as I know |
| 18:03.23 | Stragus | Regarding the API, it's closely modelled on the pthreads API except with different names |
| 18:03.42 | Stragus | (the mmthread API that is) |
| 18:04.27 | Stragus | I heard complaints about the C11 thread API, design flaws or something, but I can't see I have paid much attention. I have something that works and wouldn't care about C11 threads either way |
| 18:23.01 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 18:32.22 | *** join/#brlcad AdityaGulati (ca034dcc@gateway/web/cgi-irc/kiwiirc.com/ip.202.3.77.204) |
| 18:34.47 | *** join/#brlcad raingloom (~raingloom@C2267141.catv.pool.telekom.hu) |
| 19:37.10 | *** join/#brlcad yorik (~yorik@2804:431:f720:db49:290:f5ff:fedc:3bb2) |
| 23:11.51 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |