[00:01] "It's a testing page for the "setTimeout, exit early, and then busywait" idea. You need to do a surprisingly long busywait to have a good chance of being accurate." [00:08] *** A_Scanner has joined #jsmess [00:16] *** binji has quit IRC (Leaving) [00:59] *** chartreus has quit IRC (Remote host closed the connection) [00:59] *** chartreus has joined #jsmess [01:05] *** cairnsh has joined #jsmess [01:08] Hi! I made this testing thing: https://skeletonplanet.com/test/timeout_tester.html#explanation [01:08] Sorry, without the fragment identifier [01:08] https://skeletonplanet.com/test/timeout_tester.html [01:11] I don't know if it works, it's pretty weird [01:12] It tests the method where you do a setTimeout for a shorter interval and then finish with a busywait. [01:13] I notice that the results are hugely different depending on the time interval, on this browser (Firefox Quantum 57.0 64-bit on Windows 8.1) [01:14] Timeout of 15 ms works great, with all but 13% of calls happening within 1 ms of the scheduled time, but timeout of 20 ms is a lot worse, with 38% off by more than 1 ms and 15% off by more than 6 ms [01:17] on the other hand, on this other browser (Opera 49.0) 15 ms is not a good time... [01:17] Wow, and if I run them on two different browsers at the same time they affect each other's behavior [01:17] :v [01:19] Well, ok, that's not so surprising [01:20] What's surprising is that the stats got BETTER when the other browser was doing its thing and WORSE when it was closed [01:20] so I guess I have no idea what's going on [01:25] yeah, that's the fun part :D [01:25] setTimeout isn't really a particularly accurate method unfortunately [01:27] *** chartreus has quit IRC (Read error: Operation timed out) [01:27] what's super interesting to me is that there are some intervals that are more accurate than others [01:28] and that it's different depending on the browser? [01:28] and possibly on your environment [01:29] maybe if you searched through the parameters for a good interval when you started, you could get something very accurate? [01:29] although it looks like the good parameters can also change depending on the other programs that are running [01:35] yeah, and probably varies wildly depending on the other stuff your app is doing as well [01:36] on the other hand, requestAnimationFrame fires pretty regularly every 16.6667ms, unless you're pushing more work than you can handle per frame, then the time between calls goes up proportionally [01:37] *** chartreus has joined #jsmess [01:37] so I don't think we really need setTimeout as it can be wildly unpredictable, and can instead just rely on the fact that requestAnimationFrame will be called in the next (16.6667 - timeTakenByThisFrame) ms [01:45] someone had a suggestion to use setjmp/longjmp to pause and resume the context in the sleep function, so if you're asked to sleep for more than the number of ms that would take you into the next 16.6667ms block, you basically set a jump point and allow control to return to the browser, then on the next requestAnimationFrame handler we longjmp() back to that stored context, so we resume inside of the sleep [01:45] function, which now says "oh, I now only have .2ms left to sleep" [01:49] *** binji has joined #jsmess [01:50] *** i0npulse has quit IRC (Ping timeout: 248 seconds) [01:50] *** Rai-chan has quit IRC (Ping timeout: 248 seconds) [03:00] that works well for me but the percentage of time spent busywaiting varies a lot [03:01] well, under my specific browser under my special circumstances [03:02] actually, that's only if I busywait until 17 ms has passed, which you wouldn't be doing. waiting 16.67 ms is fine. never mind [03:17] cairnsh: Are you comfortable jumping in with code? [03:17] Or test casing is what you prefer [03:19] I will take a shot at it! I don't have an Emscripten installation yet. [03:27] But I have a Linux machine that I can install it on. (I don't need a VM inside that, right?) [04:09] What would you want me to do? [04:42] *** A_Scanner has quit IRC (Leaving) [04:46] *** chartreus has quit IRC (Read error: Operation timed out) [04:54] Well, make this happen. :) But any insights into approach are welcome. [04:54] Bai could do it if he focused exclusively on it, but his start-up needs to make money [05:26] well, this has been productive in terms of suggestions people have made [05:28] I think there were two main realizations both from typing it out like this and from suggestions made by others....the setjmp/longjmp part is a missing piece to what I was doing before, and then after talking through the problem and looking moe closely at the profiling graphs, I think there's really only one main source of all that sleeping [05:37] *** balrog has quit IRC (Read error: Operation timed out) [05:42] *** balrog has joined #jsmess [05:57] I'll just keep throwing you people until it looks like the beginning of Matrix:Reloaded [05:58] https://i.makeagif.com/media/6-24-2015/0wQta0.gif [06:48] *** Rai-chan has joined #jsmess [06:51] *** i0npulse has joined #jsmess [07:07] *** Vito` has joined #jsmess [07:08] huhn [07:08] I think IRCCloud died like 2+ weeks ago but reported it was still connected [07:55] You missed EVERYTHING [07:56] Microsoft bought us for $3bil [07:56] I paid $1bil to have Notch... "upgraded" [07:56] worth it [08:01] $75 million firepit [08:02] We posted a thing you'll like [08:03] https://t.co/cEesFk0mPm [08:06] I saw, great to put it all in one place [08:38] Yeah, let's bust this thing wide open! [09:14] *** chartreus has joined #jsmess [09:39] *** chartreus has quit IRC (Read error: Operation timed out) [10:07] *** binji has quit IRC (Read error: Operation timed out) [15:01] *** cairnsh has quit IRC (Quit: Leaving) [15:06] *** cola_ has joined #jsmess [15:06] *** cola_ is now known as cairnsh [15:06] Hi again, sorry [15:06] Can I ask some stupid questions? [15:07] I guess that's more of a rhetorical question, ok here goes [15:10] Emscripten seems to do something like compile the C program to assembly language and then convert the assembly language instructions into Javascript. Is that really necessary?? [15:15] :) [15:16] Yes [15:16] You mean asm.js? [15:16] *** cairnsh has left Leaving [15:16] *** cairnsh has joined #jsmess [15:16] (ASM.JS isn't assembly language) [15:16] whoops, sorry [15:17] I mean, when I run emcc tests/hello_world.c -o hello.html, it produces a Javascript file that looks like [15:18] I don't know, here's the main function: [15:18] function _main() { [15:18] var $0 = 0, $vararg_buffer = 0, label = 0, sp = 0; [15:18] sp = STACKTOP; [15:18] STACKTOP = STACKTOP + 16|0; if((STACKTOP|0) >= (STACK_MAX|0)) abortStackOverflow(16|0); [15:19] $vararg_buffer = sp; [15:19] $0 = 0; [15:19] (_printf(384,$vararg_buffer)|0); [15:19] STACKTOP = sp;return 0; [15:19] } [15:19] I don't know at what level you want me to cover this. [15:20] A lot of Emscripten is dealing with something that should never have had to happen, now happening [15:22] emscripten compiles the C program to a bytecode called LLVM and then converts that into an assembly-like subject of javascript called asm.js [15:22] asm.js is valid normal javascript but browsers that are expecting it can quickly compile it back into something closer to machine language before executing it [15:23] Oh! Okay. [15:23] it's cheesy and that's why WebAssembly was invented [15:23] to be a proper solution [15:24] Thank you. [15:35] But we support the old way, for a while to come. [16:16] *** Lord_Nigh has quit IRC (Read error: Operation timed out) [17:01] *** Lord_Nigh has joined #jsmess [22:25] I like the suggestions [22:25] We're getting a LOT of people visiting the page. [22:25] A LOT. [22:26] I wonder how many are bots. They try and comment, and it's sometimes garbagy