Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-11-26

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:01 jeffreykegler The obstack is important here, it's a GNU-invented structure which is optimized for memory allocations which are never resized, and which are not deallocated in a random-access fashion.
00:01 jeffreykegler Allocation is usually simply a pointer increment, so much faster than malloc
00:02 ronsavage Interesting insight. I can image people re-implementing obstacks etc in JS and then complaining how slow it is, and Marpa uses 'tricks' to make it fast!
00:02 jeffreykegler And deallocation is even better -- I don't need to follow all the structures I created to deallocate them -- I deallocate only whole obstacks at a time, and just do so by deleted the whole obstack.  All pointers within it don't matter.
00:03 jeffreykegler ronsavage: if access is through the Perl layer (which Marpa access usually is these days) ...
00:03 jeffreykegler all this is over-optimization at the C level ---
00:04 jeffreykegler all that's gained by these C language level tricks is swamped by Perl level overheads.
00:04 jeffreykegler But I was thinking long-term, and in terms of Libmarpa running as a separate library.
00:08 jeffreykegler ronsavage: Presumably if you are reimplement in JS or whatever, you ignore everything I just said ...
00:10 jeffreykegler and just use the native hashmaps and dynamic arrays
00:23 koo5 joined #marpa
01:29 ronsavage Sure, but that's exactly why it'll be slower.......
01:41 Aria I was looking at obstacks in JS: planning to use Buffers (or typed arrays) and implement all the memory management myself.
02:27 jeffreykegler joined #marpa
02:28 jeffreykegler Aria: my understanding is that you cannot do C library extensions to JS -- its charm is that it's found on everything with a browser, and compiling C code on those targets is usually out of the question.
02:28 jeffreykegler On that assumption, then
02:28 Aria True, if you target the browser.
02:29 Aria On the server, more options.
02:29 jeffreykegler Which do you have in mind?
02:30 Aria Both. But binding libmarpa has downsides in node.js, since in the current version, calling into C++ is quite expensive.
02:30 jeffreykegler Also, of the others interested in JS implementations, which do you think they have in mind?
02:30 jeffreykegler "Both" means to me lowest common denominator, which is client.
02:30 Aria I would expect pure javascript.
02:31 jeffreykegler So client, and no C library support then?
02:31 Aria Yeah.
02:31 jeffreykegler OK so on that assumption ...
02:32 Aria But modern browsers do have reasonably fast access to "raw" memory, so there are interesting primitves to work with.
02:32 jeffreykegler You have with native JS reasonably fast native data structures, which come with memory management, all of which we can assume is reasonably well implemented and ...
02:32 jeffreykegler for which you must pay the price no matter what.
02:33 jeffreykegler Implementing obstacks on top of them would, is my belief, really not make sense.
02:33 jeffreykegler The whole rigamarole I recited earlier ....
02:34 jeffreykegler only is efficient if you can program down to the metal, and without a native memory management overhead.
02:34 jeffreykegler For example, the use of a work area with a final copy to a fixed size array ...
02:35 jeffreykegler makes a lot of sense if you are forced to do your own memory management, because that re-copy after sizing can be seen as memory management, and amortized with that in mind.
02:35 jeffreykegler In the JS context, those re-copies would be kind of wasteful.
02:37 jeffreykegler Similarly, obstacks exploit abilities and solve problems which exist in the C context, but not in pure JS -- which carries with it its own abilities and problems.
02:38 jeffreykegler Bottom line: if you're implementing in JS, the strategy I recited is simply not helpful -- you want to re-design the data structures from scratch.
02:39 jeffreykegler Aria: re http://irclog.perlgeek.de/marpa/2014-11-26#i_9721083 ...
02:39 jeffreykegler Is there anywhere an open-source memory management system implemented in pure JS?
02:40 Aria I'm sure, though I've not looked deeply. The primitive is a TypedArray, like UInt8Array; allocating one is essentially malloc.
02:40 jeffreykegler Most of the point of obstacks is to *avold* malloc overhead.
02:41 Aria And the interface is raw bytes. There are interfaces on top of that for reading and writing larger types from them.
02:41 Aria So you'd do what everyone in C does to avoid malloc: allocate a big buffer and slice it up yourself.
02:41 jeffreykegler How about pointer arithmetic to offsets inside them?
02:42 Aria Offsets in typed arrays are plain integers. So the math works like you'd expect.
02:45 jeffreykegler By which I mean without the overhead of checking that the pointer actually points somewhere reasonable.
02:45 jeffreykegler It sounds a little wierd but in this context the ability to create a segment violation is a feature.
02:45 Aria Oh is it!
02:45 Aria But no, it's entirely bounds-checked.
02:45 Aria (at access time).
02:45 jeffreykegler And the bounds-checking is overhead.
02:45 jeffreykegler Which is why I call the ability to create a segment violation a feature ...
02:48 ilbot3 joined #marpa
02:48 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Pastebin: http://scsys.co.uk:8002/marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today
02:49 jeffreykegler On the other side of the balance sheet in Libmarpa, I'm always having to work around the limits of obstacks -- memory won't be released until the recognizer is destroyed, can'
02:49 jeffreykegler t resize etc.
02:49 jeffreykegler In native JS, you can just avoid thinking about that stuff and concentrate on the core algorithm.
02:56 jeffreykegler Googling this topic, I see there's an asm.js -- take your C code and compile it to a highly-optimizable Javascript subset.
02:57 jeffreykegler This field sure is complicated. :-)
03:02 jeffreykegler asm.js seems to do it by giving the C code a huge array, which is not internally bounds-checked.
03:03 jeffreykegler Some overhead still can't be optimized out, but it claims it runs C at 50% to 70% of native speed.
05:41 ronsavage joined #marpa
07:36 jluis joined #marpa
13:27 flaviu joined #marpa
13:55 lwa joined #marpa
14:14 koo5 joined #marpa
16:54 jeffreykegler joined #marpa
17:22 flaviu joined #marpa
17:37 jeffreykegler Aria: If you're so inclined, you might want to repeat the experiment with timing Warshall's algorithm, this time using asm.js
17:38 jeffreykegler It would resolve any question of how fast asm.js could bit twiddle.
18:11 aredridel joined #marpa
19:42 flaviu joined #marpa
20:28 flaviu joined #marpa
20:31 ronsavage joined #marpa
22:34 flaviu joined #marpa
23:26 jeffreykegler joined #marpa
23:37 jeffreykegler https://github.com/jeffreykegler/kollos/blob/master/design/rewrite.md
23:38 jeffreykegler I just put up a Kollos design doc, describing the grammar rewrite -- at least a first, highest-level cut at it.
23:38 jeffreykegler rns: you may be interested in this, based on what I see going on in your Github repo
23:39 jeffreykegler Also, it's possible docs at this level, plus asm.js, may be a road to a Javascript version of Kollos.
23:40 jeffreykegler Just to be clear, my first priority will stay the Lua one, but there does seem to be a lot of interest in trying to find a way to clone Marpa into JS, and I always think it best to let people follow their enthusiasms.

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary