| 01:39:05 | * | q66 quit (Quit: Quit) |
| 01:54:56 | * | fowl quit (Ping timeout: 264 seconds) |
| 02:29:46 | * | fowl joined #nimrod |
| 06:14:02 | * | FreeArtMan quit (Ping timeout: 260 seconds) |
| 07:14:18 | * | gour joined #nimrod |
| 09:51:29 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0/20121119183901]) |
| 10:23:39 | * | silven quit (Ping timeout: 252 seconds) |
| 10:26:19 | * | silven joined #nimrod |
| 11:08:24 | * | Trix[a]r_za is now known as Trixar_za |
| 12:04:00 | * | Araq_ joined #nimrod |
| 12:18:50 | * | q66 joined #nimrod |
| 12:24:45 | * | fowl quit (Read error: Operation timed out) |
| 12:34:40 | * | Trixar_za is now known as Trix[a]r_za |
| 12:38:00 | * | fowl joined #nimrod |
| 12:40:50 | * | Araq_ quit (Read error: Connection timed out) |
| 12:43:10 | * | Araq_ joined #nimrod |
| 13:13:51 | * | zahary joined #nimrod |
| 13:49:46 | Araq_ | hi zahary |
| 13:51:11 | zahary | hi |
| 13:52:06 | Araq_ | so ... we need unpack/pack for the FFI |
| 13:54:11 | Araq_ | and what's worse, we need to unpack the data again for every FFI call |
| 13:54:41 | Araq_ | because the C code could write to the passed array, for instance |
| 13:55:11 | Araq_ | and at that point FFI is really slow and we should store the data in the packed form all the time |
| 13:57:06 | Araq_ | so that's what I planned to implement |
| 14:02:01 | Araq_ | and the AST interpreter will be replaced by a bytecode interpreter |
| 14:02:11 | Araq_ | any objections? ;-) |
| 14:06:41 | dom96 | Araq_: seems the sockets docs for ssl functions do not show up. |
| 14:07:01 | dom96 | Does the doc generator skip 'when defined(ssl)'? |
| 14:08:26 | Araq_ | yep :P |
| 14:09:06 | Araq_ | it's easy to fix |
| 14:09:26 | Araq_ | just edit nimweb to pass -d:ssl to the compiler |
| 14:11:21 | dom96 | ok |
| 14:17:41 | zahary | well, packing is orthogonal to having a proper bytecode |
| 14:18:52 | zahary | it only affects how struct types are represented - currently with a hash table, possibly replaced by a blob + layout description |
| 14:19:32 | Araq_ | structs and arrays, yes |
| 14:23:07 | zahary | so, start with that |
| 14:23:12 | zahary | I think the iterator problem is solvable too btw, haven't thought it through, but just like exceptions are represented by "special values" that pop all the way up, the iterator return could be such a special value that records the current context |
| 14:23:47 | zahary | i.e. records which side of the if was taken, are we in the 6th or 7th statement in the statement list, etc |
| 14:24:42 | zahary | having this on record should be enough to restore the recursive context, no? |
| 14:25:22 | Araq_ | you may be right |
| 14:25:42 | zahary | don't get me wrong. I'm not against proper bytecode, but it sounds like a lot of work |
| 14:26:22 | Araq_ | well I'm evaluating libjit and gnu lightning now |
| 14:27:12 | Araq_ | and supporting yield in the AST interpreter sounds at least as much work as implementing bytecode |
| 14:27:27 | Araq_ | if it works at all, I still have doubts |
| 14:27:47 | Araq_ | you can't just 'return' back into the proper nesting level |
| 14:28:12 | Araq_ | the 'return' and 'break' tokens all go up the eval stack |
| 14:28:22 | Araq_ | 'yield' needs to go down |
| 14:29:27 | zahary | in what I suggested above, it goes up too (but it would be quite slow, unarguably) |
| 14:29:47 | Araq_ | I know |
| 14:30:02 | Araq_ | and thus it sounds wrong |
| 14:30:07 | Araq_ | :-) |
| 14:30:52 | Araq_ | plus I've written bytecode interpreters before; can't imagine what would be more fun :D |
| 14:33:02 | Araq_ | I agree it's not really that important for now |
| 14:33:52 | Araq_ | but since I'm too tired to work on fixing bugs the alternative would be me doin' nothing :P |
| 14:37:27 | zahary | btw, I've a mix of good and bad news about the GC |
| 14:38:27 | zahary | the good news is that after some final codegen fixes, the compiler server doesn't leak memory between compilations, yay :) |
| 14:43:02 | zahary | but the bad news is that now collect cycles in the compiler is massively more expensive. this is partly because the new algorithm is doing more work there, and also because TNode is not really acyclic type and this amplified the amount of work further |
| 14:43:07 | Zor | 14:26:14 < Araq_> well I'm evaluating libjit and gnu lightning now <-- both useless |
| 14:44:22 | zahary | to understand why it isn't acyclic, consider a recursive proc. there is cycle in it that goes like this |
| 14:44:27 | zahary | proc body -> nkCall -> proc sym -> proc.ast[bodyPos] |
| 14:46:07 | Araq_ | I'm aware |
| 14:46:12 | Araq_ | of this cycle |
| 14:47:52 | Araq_ | however a PSym is involved here |
| 14:48:02 | Araq_ | so the idea was to use this as a root candidate |
| 14:48:47 | Araq_ | every cycle can only be introduced via some PType or PSym |
| 14:49:12 | zahary | so, why did you make TNode acyclic then? this probably leads me to the next point |
| 14:49:17 | zahary | it turned out that the old GC never collected a single cyclic object within the compiler (didn't you bother to test it there?) |
| 14:49:22 | zahary | so if I disable mark and sweep or just use some very high threshold, bootstrap times and memory footprint is preserved in bootsrapping |
| 14:50:32 | Araq_ | welll yeah my testing of the cycle code was *cough* foolish |
| 14:51:07 | Araq_ | iirc, I tested it, optimized it to the broken version |
| 14:51:12 | zahary | your reasoning is wrong. it doesn't matter how cycles are introduced. you still have to account for the internal refcounts within the cycle |
| 14:51:32 | Araq_ | and by that time I only had the gc tests taht you can see in tests/gc |
| 14:52:52 | Araq_ | that's true but you can start the cycle checking at the "root" of the cycle |
| 14:54:02 | Araq_ | but if it's too slow we can always implement mark&sweep |
| 14:55:32 | Araq_ | what is the new bootstrapping time for you with the fixed cycle collector? |
| 14:55:42 | zahary | it's the size of the cyclic graph that's killing performance, not the number of candidates. |
| 14:56:22 | zahary | without the acyclic fix for TNode, it goes from 1.7 to 1.77 for me. with the fix it goes to 2 seconds |
| 14:57:12 | Araq_ | that's not as bad as I imagined :D |
| 14:57:42 | Araq_ | I still don't get why TNode needs to be cyclic |
| 14:57:47 | zahary | with mark and sweep disabled, the new GC may be slightly faster, because it's more efficient in some other areas |
| 14:58:32 | Araq_ | well the internal pointer substraction stuff does 3 passes over the graph |
| 14:58:42 | Araq_ | proper mark&sweep does only 2 |
| 14:58:47 | zahary | well, when you traverse the graph for decref/incref, you can ignore acyclic objects, because they cannot contribute to the internal refcounts |
| 14:59:02 | zahary | internal refcounts == these that are only part of the cycle |
| 14:59:22 | zahary | so when TNode is acyclic this cuts a very large areas of the graph |
| 14:59:47 | Araq_ | but that's not what .acyclic does |
| 15:00:12 | Araq_ | .acyclic is only concerned with potential cycle roots |
| 15:00:17 | zahary | it changes a bunch of things - this being one of them |
| 15:00:42 | Araq_ | I have to go ... we need to continue this talk later |
| 15:00:47 | Araq_ | bye |
| 15:00:52 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0/20121119183901]) |
| 15:00:57 | zahary | I can leave TNode acyclic and disable the acyclic cut-off (what I described above), but this has pretty much the same cost |
| 15:01:12 | zahary | to repeat what I said: it's the size of the cyclic graph that's killing performance, not the number of candidates. |
| 16:12:33 | * | zahary quit (Quit: Leaving.) |
| 16:25:53 | * | XAMPP quit (Read error: Connection reset by peer) |
| 17:12:43 | Araq | Zor: so .. please elaborate why gnu lightening and libjit are worthless? |
| 17:26:28 | * | Vladar joined #nimrod |
| 17:46:03 | * | fowl quit (Ping timeout: 255 seconds) |
| 17:59:03 | * | fowl joined #nimrod |
| 18:48:29 | reactormonk | hmm - should I tinker a bit further with emacs so I can use nimrod to script kwin? :-) |
| 18:49:14 | Araq | reactormonk: using nimrod is always a good idea |
| 18:49:49 | reactormonk | Araq, I'll be using elisp though |
| 18:50:44 | Araq | meh |
| 18:52:54 | reactormonk | how can I compile nimrod code on-the-fly? |
| 18:53:04 | reactormonk | with a tempfile or can I pipe through nimrod? |
| 18:53:34 | Araq | tempfile |
| 19:01:29 | * | FreeArtMan joined #nimrod |
| 19:03:04 | reactormonk | good |
| 19:05:34 | reactormonk | but then I wonder why I not just link to the C++ sources |
| 21:06:55 | * | Vladar quit (Quit: Leaving) |
| 21:30:25 | * | FreeArtMan quit (Quit: Out of this 3D) |
| 22:01:45 | * | gour quit (Disconnected by services) |
| 22:01:50 | * | gour_ joined #nimrod |
| 23:02:25 | * | gour_ quit (Quit: WeeChat 0.3.8) |