Timestamps are in GMT/BST.
| 00:45:35 | | watusimoto has joined |
| 00:45:35 | | ChanServ sets mode +o |
| 00:50:21 | raptor | oh Lua stack! oh Lua stack!... thy ways are so frustrating; |
| 00:54:51 | raptor | ok, without modifying the c++ code |
| 00:54:56 | raptor | i ran two tests: |
| 00:55:17 | raptor | test #1 use table.clear() on a global 'items' array |
| 00:55:44 | raptor | test #2 create the array each tick and pass that into bf:findAllObjects() |
| 00:56:23 | raptor | #1 averaged 105ms over 10000 iterations |
| 00:56:31 | raptor | #2 averaged 113ms over 10000 iterations |
| 00:57:10 | raptor | so that's like an 8% difference |
| 00:57:39 | raptor | this is with LuaJIT |
| 01:01:15 | | Invisible has joined |
| 01:06:58 | raptor | for reference, i did a test with just object construction in straight Lua |
| 01:07:28 | raptor | so instead of calling bf:findAllObjects(), I just filled up a table with integers |
| 01:07:43 | raptor | then compared the items = {} construction every tick, or clearing it |
| 01:08:28 | raptor | since the table had 300 items in it, it was faster to create the table every tick: 119 ms vs 129 ms |
| 01:08:52 | raptor | but obviously the garbage collector probably didn't have time to kick in |
| 01:12:42 | raptor | ah ha! calls with the C API are not JIT-compiled |
| 01:14:05 | raptor | "Calls to C functions can be inlined in JIT-compiled code, unlike calls to functions bound via the classic Lua/C API" |
| 01:14:19 | raptor | from here: http://luajit.org/ext_ffi.html |
| 01:14:38 | raptor | so basically, with LuaJIT - we're slowing ourselves down by using the C API |
| 01:18:19 | raptor | ok time for bed |
| 01:18:27 | raptor | night! |
| 01:18:27 | | raptor Quit () |
| 01:24:55 | | Invisible Quit (Ping timeout: 264 seconds) |
| 02:02:55 | | sam686 Quit (*.net *.split) |
| 02:08:04 | | sam686 has joined |
| 02:08:05 | | orwell.freenode.net sets mode +v |
| 02:09:01 | | sam686 is now known as sam686_ |
| 02:13:38 | | sam686_ is now known as sam686 |
| 05:18:59 | | LordDVG has joined |
| 05:30:56 | | LordDVG Quit (Remote host closed the connection) |
| 12:25:15 | | LordDVG has joined |
| 12:29:04 | | raptor has joined |
| 12:29:04 | | ChanServ sets mode +o |
| 12:29:13 | raptor | good day! |
| 13:08:57 | watusimoto | hello |
| 13:09:06 | watusimoto | man, I fell asleep early again last night |
| 13:09:09 | watusimoto | what gives?? |
| 13:09:43 | watusimoto | I will admit I've been feeling great getting 9-10 hours of sleep each night more or less since thanskgiving |
| 13:10:05 | watusimoto | close to 11 sometimes... but it really cuts into my day |
| 13:27:49 | raptor | you probably have a bug |
| 13:28:07 | raptor | and your body is forcing you to handle it |
| 13:28:28 | raptor | I sent you an e-mail that may or may not be understandable |
| 13:48:07 | watusimoto | I don't feel at all sick |
| 13:48:10 | watusimoto | I feel great! |
| 13:48:32 | watusimoto | reading your email... |
| 13:49:09 | watusimoto | so... lua/jit is faster than c++... interesting |
| 13:49:21 | watusimoto | so for our table clearing, call a lua scriptlet? |
| 13:49:56 | watusimoto | two options for doing that: |
| 13:49:58 | raptor | i did that test, too |
| 13:50:09 | watusimoto | 1) have scriplet be called from c++ when we need it |
| 13:50:11 | raptor | for table clearing calling table.clear() in Lua (with LuaJIT) is faster |
| 13:50:31 | watusimoto | 2) wrap calls to findObjects in a lua helper function that does the clearing before c++ gets the table |
| 13:50:50 | raptor | 2 would definitely be faster |
| 13:51:17 | raptor | because it doesn't call the C API which uses the standard intepreter |
| 13:51:38 | raptor | or more accurately: it doesn't call the C API which is not JIT-compiled |
| 13:51:51 | raptor | also |
| 13:52:32 | watusimoto | but when the c API calls a lua script, that gets jit'ed, right? |
| 13:52:36 | raptor | it turns out that object construction each tick is cheaper in LuaJIT than clearing larger tables on the order of 100 or so objects |
| 13:53:19 | watusimoto | time to clear table with 100 objects > time to throw away table and create new one |
| 13:53:26 | raptor | i'm not sure about that |
| 13:53:36 | watusimoto | though in most cases, we'll have far fewer than 100 objects |
| 13:53:37 | raptor | not sure about the JIT'd code from C API |
| 13:53:42 | watusimoto | ok |
| 13:54:19 | watusimoto | so maybe we write a wrapper that gurantees the table is empty before it gets to c++ |
| 13:54:58 | raptor | yes, but i'm not sure how to stick that in |
| 13:55:08 | watusimoto | we wrap other functions, no? |
| 13:55:26 | raptor | yes, but I don't remember if we put them into the 'bf' or 'levelgen' namespaces |
| 13:55:45 | watusimoto | how do we call findObjects currently? |
| 13:55:57 | watusimoto | like what does the lua code look like? |
| 13:56:22 | watusimoto | findObjects(MineType, resultsTable) ? |
| 13:56:31 | watusimoto | there must be some namespaces in there somewhere |
| 13:56:40 | watusimoto | I know MineType needs a namespace |
| 14:00:36 | watusimoto | I can probably take care of this, since I "created" (discovered, really) the problem |
| 14:00:41 | watusimoto | and I know I can clear the table in Lua! |
| 14:01:12 | watusimoto | I guess one thing to test would be whether clearing in lua would be faster than clearing in c++ using a lua script |
| 14:01:18 | watusimoto | though I think it hardly matters |
| 14:01:38 | watusimoto | ^^ using a cached/precompiled lua script |
| 14:02:43 | watusimoto | btw, as for portable apps, I don't recall rejecting it for any specific reasons; I think I decided it wasn't worth the effort. I don't think I ever contacted them, and am happy to slot them into our release process if they host our app |
| 14:24:49 | raptor | clearing in Lua with LuaJIT is faster than in the C API |
| 14:25:04 | raptor | if we weren't using LuaJIT then it may be slower |
| 14:49:17 | watusimoto | yes, but that is not what I am saying |
| 14:49:44 | watusimoto | I am comparing clearing in Lua vs. clearing in a Lua fragment called from C++; not writing the clearing action using the C++ api |
| 14:51:47 | | Nothing_Much Quit (Read error: Connection reset by peer) |
| 14:56:15 | raptor | ohhhh |
| 14:56:17 | raptor | oh ok |
| 14:56:18 | raptor | i get it |
| 15:17:52 | | Nothing_Much has joined |
| 15:40:27 | watusimoto | I think we can precompile a snippet and if it is compiled with jit internally (which is probably is) it should be pretty fast, and might be cleaner than a lua wrapper |
| 15:49:04 | raptor | yes |
| 15:49:06 | raptor | i agree |
| 15:50:16 | | Nothing_Much Quit (Read error: Connection reset by peer) |
| 15:52:28 | | Nothing_Much has joined |
| 16:24:50 | | Darrel has joined |
| 17:30:50 | raptor | we could rewrite all lua bindings in the FFI: http://luajit.org/ext_ffi.html |
| 17:31:34 | watusimoto | you're kidding, right? |
| 17:31:35 | raptor | but then we'd be tying ourselves to luajit instead of lua |
| 17:31:46 | raptor | heh, yes |
| 17:32:08 | watusimoto | I think our current binding system is not too bad, and is largely complete |
| 17:32:11 | raptor | unless we wanted easier maintainable code that was faster and less complex |
| 17:32:17 | watusimoto | ha |
| 17:32:20 | raptor | but it would sure be an enormous job |
| 17:32:35 | watusimoto | ffi has an alarmling looking syntax |
| 17:33:45 | watusimoto | well, maybe less alarming than I first thought |
| 17:34:04 | watusimoto | I saw the lua code and thought it was supposed to be c++ code |
| 17:34:06 | watusimoto | :-) |
| 17:34:16 | raptor | yeah... it looks pretty slick - the only thing is that I think it uses 0-indexed code |
| 17:34:21 | watusimoto | but ffi only steems to talk about c, not c++ |
| 17:34:26 | raptor | which is nice, but might be confusing with working with Lua 1-indexes |
| 17:34:37 | watusimoto | for us, yes... for others, not sure |
| 17:34:53 | watusimoto | but that is one of my big complaints about lua |
| 17:35:17 | raptor | well, I've heard, and this is just a rumor, that there exists someone that understands the Lua stack intimately enough, although I haven't met them... |
| 17:41:06 | watusimoto | yes, the ffi does actually look pretty cool |
| 17:41:25 | watusimoto | I wonder if we can try it without committing to a full conversion |
| 17:44:41 | watusimoto | though i will say that with jit, I don't feel we're really hurting for speed |
| 17:52:32 | watusimoto | another thought related to findObjects |
| 17:53:01 | watusimoto | reading through the roadmap for jit 2.1 (which may or may not ever get written) shows me a big planned feature is a new GC system |
| 17:53:27 | watusimoto | specifically designed to remedy the way devs (like us) take great pains to avoid creating/deleting lots of objects |
| 17:53:54 | watusimoto | if that happens, passing a table to findObjects will feel clunky |
| 17:54:10 | watusimoto | so maybe we should consider removing it now |
| 17:54:22 | watusimoto | but even as I write that I feel myself saying no, keep it for now |
| 17:54:34 | watusimoto | if we are going to make a change like that, why rush into it? |
| 17:54:40 | watusimoto | why not wait for luajit2.1? |
| 18:15:12 | raptor | it's a trap! |
| 18:15:15 | raptor | (premature optimizations) |
| 18:17:48 | | LordDVG Quit (Remote host closed the connection) |
| 18:39:58 | | fordcars has joined |
| 18:40:24 | fordcars | Hey raptor, what was kaen's shader project again? |
| 18:40:48 | raptor | he started a clone |
| 18:40:57 | raptor | go to the google code clones page for bitfighter |
| 18:41:02 | raptor | and search for 'shader' |
| 18:41:09 | fordcars | Okey I'll check it out |
| 18:41:16 | raptor | it may have 'bkconrad' in it |
| 18:41:24 | | Darrel is now known as Darrel[OFF] |
| 18:42:18 | fordcars | Ok got it |
| 18:42:52 | fordcars | Wow, that looks interesting |
| 19:28:44 | | raptor Quit () |
| 20:02:34 | | Raven67854 has joined |
| 20:24:21 | sam686 | watusimoto, still having a joystick crash problem? I can't get it to crash on me and i also have a joystick/gamepad. My thinking is there might be a problem with a compiler? I used visual C++ 2008, does it crash if you use my build? http://sam6.25u.com/upload/bitfighter_019d_59415d660678.zip |
| 20:25:31 | sam686 | oops, you need to add in joystick_presets.ini |
| 20:27:04 | sam686 | just added joystick_presets.ini to that zip file |
| 20:30:57 | sam686 | it could also be maybe outdated boost files not working too well on newest version of visual studio maybe, got warnings before about it in boost if using newest version of visual studio |
| 21:51:14 | | watusimoto Quit (Quit: Leaving.) |