Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-15

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

All times shown according to UTC.

Time Nick Message
00:04 timotimo huh ... i don't see rakudo-moar/HEAD excel at trim_string as comparde to rakudo-moar/2014.06; does that just mean the performance didn't regress through the rewrite and optimization pass?
00:06 japhb_ jnthn, Some of the results show non-native string performance scales worse than native strings (meaning, the non-native case angles down, instead of flat across).  for_concat_2 v. for_concat_2_native, for instance.
00:07 japhb_ timotimo, Yeah, I think that's exactly it.  Because IIRC, trim regressed really hard before his latest fixes.
00:08 timotimo it *could* be that we can't constant-fold $x ~ $x in one case, but in the other?
00:09 japhb_ Interesting thought.
00:10 japhb_ Oddly it looks like any_equals regressed a little bit since 2014.06
00:10 japhb_ Hmmm, I need to fix the work estimate for trim_string, oops.
00:11 japhb_ And probably rat_harmonic too.
00:11 * japhb_ blinks twice at the plot for rc-self-describing-numbers
00:12 timotimo yeah
00:12 japhb_ Now how the heck did *that* happen
00:12 timotimo it confused me, too
00:12 timotimo did compile times increase a buttload?
00:13 japhb_ Yes, at one point, but I thought lizmat (mostly?) fixed that ...?
00:13 japhb_ It was an S11 code performance bug
00:14 timotimo that was a regression that lasted only a few days at most
00:14 timotimo i don't think it went into any release, actually
00:17 japhb_ Agreed, I was just trying to remember (since I don't backlog #perl6 anymore, I miss out on info like that -- I was lucky to see that one in passing).
00:21 timotimo well, i suppose in the weekly you only get the good news, not necessarily the bad ones that get fixed within the time frame
00:28 timotimo anyway, off to bed i go!
00:32 [Coke] ~~
00:45 japhb_ Oh yeah, the latest changes make a big difference to summary scores for nqp-moar/master and rakudo-moar/nom
00:46 japhb_ By my estimates, the overall performance of nqp-moar has more than doubled in the last 6 months -- and the overall performance of rakudo-moar has *quadrupled*.
00:47 [Coke] moar is borked.
00:47 japhb_ (startup/compile time excepted, of course)
00:47 [Coke] I did an upgrade, realclean, configure, get a ./perl6 that keeps saying:
00:47 japhb_ ankh-moarbork?
00:47 [Coke] ===SORRY!===
00:47 [Coke] Missing or wrong version of dependency 'src/gen/m-CORE.setting'
00:48 * [Coke] tries wiping ./install and a git clean -xdf
00:48 japhb_ What about `make install; install/bin/perl6` ?
00:49 [Coke] already started the wipe.
00:49 [Coke] wouldn't help since I'm doing spectesty things.
00:56 [Coke] must have been a stale build file that wasn't cleaned up. seems OK now.
01:00 [Coke] Internal error: zeroed target thread ID in work pass. whee.
01:11 [Coke] here's a backtrace for folks to play with: https://rt.perl.org/Ticket/Display.html?id=122297
01:30 FROGGS_ joined #moarvm
01:35 colomon joined #moarvm
01:49 japhb While trying to track down a missing data point in the rakudo-moar history, I discovered that rakudo-moar/2014.05 had a user-visible spesh failure running rc-mandelbrot.
01:49 japhb Thankfully, nothing since.
01:53 teodozjan joined #moarvm
02:47 avar joined #moarvm
03:13 dalek joined #moarvm
03:20 japhb joined #moarvm
03:20 japhb_ joined #moarvm
03:20 woolfy1 joined #moarvm
03:20 nebuchadnezzar joined #moarvm
03:20 moritz joined #moarvm
03:20 itz_ joined #moarvm
03:20 hoelzro joined #moarvm
03:20 jnthn joined #moarvm
03:20 xiaomiao joined #moarvm
03:20 krunen joined #moarvm
03:20 nwc10 joined #moarvm
03:20 diakopter joined #moarvm
03:20 masak joined #moarvm
03:20 BinGOs joined #moarvm
03:20 ashleydev joined #moarvm
03:20 timotimo joined #moarvm
03:20 tokuhirom joined #moarvm
03:20 harrow joined #moarvm
03:20 cxreg joined #moarvm
03:20 camelia joined #moarvm
03:20 flussence joined #moarvm
03:20 TimToady joined #moarvm
03:22 avar joined #moarvm
03:23 ChanServ joined #moarvm
06:16 ggoebel111118 joined #moarvm
06:19 sergot o/
06:57 woolfy joined #moarvm
07:09 zakharyas joined #moarvm
07:15 nwc10 jnthn: pass
07:15 nwc10 brrt (who is not here): pass
07:16 nwc10 ie ASAN is happy
07:16 nwc10 (to the end of the spectests)
07:16 diakopter we should give the asan continuous integration bot a name. also, a cookie.
07:28 teodozjan joined #moarvm
07:35 jimmyz joined #moarvm
07:35 jimmyz jnthn: I got a Segmentation fault : https://gist.github.com/zhuomingliang/5c8ddc6718a39d2ba5cf
07:36 jimmyz jnthn: when building core setting.
07:43 diakopter hm, deserialize_stable .. sounds like my code
07:55 FROGGS_ jimmyz: would be interesting to know if that also fails under MVM_SPESH_DISABLE=1
08:05 JimmyZ joined #moarvm
08:05 JimmyZ FROGGS_: yes
08:13 brrt joined #moarvm
08:21 brrt i sometimes wonder what'd have happened if instead of making the JIT compiler in C / DynASM i'd have started with the JIT compiler as a p6 module
08:56 jnthn Lots of time doing encoding of instructions and figuring out how to get the spesh graph accessed in Perl 6 and plug the thing into the pipeline I guess... :)
09:12 brrt yeah, i suppose so, too
09:22 klaas-janstol joined #moarvm
09:24 brrt ok, seems i've learned a new dynasm trick
09:24 brrt i can load addresses of labels at run time
09:25 jnthn ooh :)
09:25 brrt importantly, that includes 'local' (non-bb) labels
09:26 brrt that also means that invokish ops need not be at the end of basic blocks
09:26 jnthn ah, good
09:26 brrt (is it invokey or invokish?)
09:26 jnthn I'm not sure we settled on that :)
09:27 jnthn invokish is probably better
09:27 brrt invokey sounds american
09:27 brrt i'm good with either :-)
09:27 jnthn Well, can't be having that... :P
09:27 jnthn Let's go with the British-sounding invokish. ;)
09:28 brrt :-)
09:40 diakopter invokesque?
09:45 dalek MoarVM/moar-jit: e47f5ca | (Bart Wiegmans)++ | src/ (6 files):
09:45 dalek MoarVM/moar-jit: Load address of entry label in JIT
09:45 dalek MoarVM/moar-jit:
09:45 dalek MoarVM/moar-jit: This will allow us to load addresses of labels that aren't
09:45 dalek MoarVM/moar-jit: start of basic blocks, and thus to deal with invokish ops
09:45 dalek MoarVM/moar-jit: without putting them at the end of basic blocks.
09:45 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/e47f5caf9a
09:47 brrt invokesque, i like
09:49 brrt weird, update-ops drops the MVM_PUBLIC prefix for MVM_op_get_op
09:50 brrt should it have that?
09:54 dalek MoarVM/moar-jit: 3842c04 | (Bart Wiegmans)++ | / (3 files):
09:54 dalek MoarVM/moar-jit: Add 'invokish' field to opcode info
09:54 dalek MoarVM/moar-jit:
09:54 dalek MoarVM/moar-jit: The JIT needs to know if we've invoked something
09:54 dalek MoarVM/moar-jit: and whether we should return to the interpreter.
09:54 dalek MoarVM/moar-jit: This flags allows us to compile a guard.
09:54 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3842c04bed
09:59 brrt hmm... anyone a good name for the invokish-guard-node?
10:00 japhb joined #moarvm
10:01 nebuchadnezzar joined #moarvm
10:01 BinGOs joined #moarvm
10:01 masak joined #moarvm
10:01 diakopter joined #moarvm
10:01 nwc10 joined #moarvm
10:01 krunen joined #moarvm
10:01 xiaomiao joined #moarvm
10:01 jnthn joined #moarvm
10:01 hoelzro joined #moarvm
10:03 japhb_ joined #moarvm
10:03 moritz joined #moarvm
10:03 itz_ joined #moarvm
10:03 flussence joined #moarvm
10:03 camelia joined #moarvm
10:03 cxreg joined #moarvm
10:03 harrow joined #moarvm
10:03 tokuhirom joined #moarvm
10:03 timotimo joined #moarvm
10:03 ashleydev joined #moarvm
10:03 TimToady joined #moarvm
10:06 brrt bbi3h
10:07 brrt left #moarvm
10:08 woolfy joined #moarvm
10:49 woolfy1 joined #moarvm
11:55 carlin joined #moarvm
12:09 jnap joined #moarvm
12:15 klaas-janstol joined #moarvm
12:20 timotimo o/
12:20 hoelzro o/ timotimo
12:32 dalek MoarVM/moar-jit: 7a30d11 | (Bart Wiegmans)++ | src/ (11 files):
12:32 dalek MoarVM/moar-jit: Add support for invokish operators and decont
12:32 dalek MoarVM/moar-jit:
12:32 dalek MoarVM/moar-jit: Decont isn't actually compiled, though, so don't consider this
12:32 dalek MoarVM/moar-jit: 'tested' just yet.
12:32 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7a30d114e9
12:32 brrt joined #moarvm
12:33 timotimo oh, that was sudden
12:34 timotimo does the oplist actually have parsing for :invokish yet?
12:35 jnthn That was in the parent commit
12:35 timotimo ah
12:37 [Coke] jnthn: did you see my moar segfault?
12:38 [Coke] https://rt.perl.org/Ticket/Display.html?id=122297
12:38 jnthn [Coke]: Yeah, saw you RT'd it. Thanks.
12:38 jnthn I'll take a look after $dayjob.
12:38 [Coke] jnthn++
12:52 brrt much wow, decont actually seems to work
12:53 timotimo wowza.
12:53 timotimo that'll bring a whole slew of frames closer to completion in one fell swoop!
12:53 * [Coke] wonders if there are other swoop varieties.
12:54 dalek MoarVM/moar-jit: 6fd5469 | (Bart Wiegmans)++ | src/ (7 files):
12:54 dalek MoarVM/moar-jit: Add support for smart stringify / numify.
12:54 dalek MoarVM/moar-jit:
12:54 dalek MoarVM/moar-jit: This means that decont is also tested (and found to work).
12:54 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/6fd54690fa
12:54 timotimo this is excellent news :3
12:54 jnthn I've seen it miswritten as "one foul swoop" :)
12:55 [Coke] jnthn: mmmhehee
12:56 brrt it doesn't exactly mean that the invokish guard actually works :-) i'm not sure if that code path is actually involved much
12:56 jnap joined #moarvm
12:56 brrt unless_o was invokish, too, right?
12:57 jnthn brrt: For decont not so often; but num/str then just numify an object with a Num method a load of times...
12:57 jnthn brrt: Yes, and if_o too
12:57 jnthn brrt: 'cus they can call .Bool
12:57 brrt ok
12:57 brrt does this work in nqp or only in perl6?
12:57 jnthn istrue/isfalse also; they should be quite easy.
12:57 jnthn if_o and unless_o show up all over teh place in perl 6
12:58 jnthn The use of smrt_* is in NQP-generated code
12:58 jnthn We don't do it that way in full-blown Perl 6.
12:58 jnthn Whenever you stringify a match object with ~ in NQP, it uses the smart stringify which calls a method, for example
13:01 brrt hmmok
13:03 jnthn if_o and unless_o are harder as they want to branch *after* the method call...
13:15 brrt oh... i see
13:15 jnthn Yeah, they are amongst the funkiest of ops.
13:17 brrt o.O funky indeed
13:18 * jnthn apologises for the funk
13:18 jnthn They are common, though...
13:18 * brrt will find a way arround the funk
13:20 jnthn brrt++
13:20 brrt :-)
13:26 dalek MoarVM/moar-jit: 1d0f170 | (Bart Wiegmans)++ | src/ (3 files):
13:26 dalek MoarVM/moar-jit: Add support for istrue, isfalse
13:26 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/1d0f170690
13:27 brrt although i grant that it won't be very simple
13:29 jnthn Well, an alternative is to desugar it into istrue and if_i
13:30 jnthn Needs a place for a temporary result.
13:30 jnthn Which is the tricky-ish bit.
13:31 jnthn Though an unused args slot may do
13:32 brrt i suppose that's true
13:32 diakopter heh, talk about stack allocation
13:33 brrt if_o, unless_o, also require a place for a temporary result
13:33 jnthn Yeah.
13:34 jnthn I'd lean towards the desugar.
13:34 brrt because in the case that JIT -> boolify (interpreter) -> JIT back, i can't use a register (hasn't an address), and i can't properly use stack space either (we'll return from the JIT frame)
13:34 brrt me too
13:34 jnthn if_o and unless_o are worth it for the interpreter and keeping bytecode size down.
13:35 jnthn But the JIT doesn't carry interpreter overhead and we're only paying this for hot paths of code we actually run.
13:35 brrt i can have the JIT graph builder do the desugar, i think?
13:36 jnthn Yes.
13:37 jnthn And use args[2] or so
13:38 brrt why args[2]? will the args buffer be used otherwise?
13:38 brrt (probably, yes; the args[0] may contain the invocant)
13:39 jnthn Yes, args[0] will have the invocant, and in the unlikely case the invocant is a thingy with a postcircumfix:<( )> it may re-shuffle the args too.
13:40 timotimo is there a plan to turn bunches of those c functions we call into in-linable assembly code at some point?
13:40 jnthn Well, that's partly for spesh to do (and what it is doing already in places)
13:40 jnthn For example, many calls related to attrs are turned into object accesses.
13:41 timotimo right
13:41 jnthn And istrue and if_o on known types will be able to become cheaper too
13:41 jnthn Since we can see the boolification spec.
13:42 timotimo right; i could build that code at some point
13:42 brrt btw, there's one small annoyance i've just had - the MVM_args_get_pos_* return a struct, and that's not very cool in ASM land
13:42 brrt i.e. it can be done but there's hardly any official specification for it
13:45 jnthn Hm. What'd you prefer it to do?
13:45 jnthn Pass it a pointer to something on the stack and have it populate that, maybe?
13:47 * [Coke] keeps seeing if_o as some kind of weird smiley.
13:48 woolfy1 left #moarvm
13:51 woolfy joined #moarvm
13:52 woolfy left #moarvm
13:57 * carlin now also sees it as some kind of smiley, thanks [Coke] :|
13:59 [Coke] maybe a guy with a monocle?
14:28 brrt jnthn - that's pretty much my preference, yes
14:29 jnthn brrt: Feel free to refactor it that way
14:29 jnthn Will need changes in a few bits of the code, I suspect.
14:29 brrt ok, will do (in due course)
14:29 jnthn *nod*
14:52 brrt i suspect work[sf->work_size-1] would be a good address for the args buffer
14:52 brrt or, in other words, how large is the args buffer?
14:59 brrt dinner &
14:59 brrt left #moarvm
15:02 jnthn Always at least 3-4 slots
17:00 [Coke] S17-promise/allof.t 10 - got the right order
17:00 [Coke] I just fudged the other moar failure (has an RT)
17:00 [Coke] so, that's the last one.
17:02 [Coke] looks like that test fails randomly.
17:26 lizmat joined #moarvm
17:28 mj41 joined #moarvm
17:29 vendethiel joined #moarvm
17:50 klaas-janstol joined #moarvm
18:01 klaas-janstol left #moarvm
18:01 klaas-janstol joined #moarvm
18:09 kjs2 left #moarvm
18:09 kjs2 joined #moarvm
18:17 bcode joined #moarvm
18:24 teodozjan joined #moarvm
18:24 teodozjan joined #moarvm
18:33 carlin joined #moarvm
19:04 tgt joined #moarvm
19:12 mj41 joined #moarvm
20:12 dalek MoarVM/moar-jit: 8f5e4f0 | (Bart Wiegmans)++ | src/jit/graph.c:
20:12 dalek MoarVM/moar-jit: Added support for if_o and unless_o
20:12 dalek MoarVM/moar-jit:
20:12 dalek MoarVM/moar-jit: Due to general funkiness of if_o and unless_o operators,
20:12 dalek MoarVM/moar-jit: this is a bit hacky, but nevertheless effective. Boolification
20:12 dalek MoarVM/moar-jit: of objects is invokish in general. To deal with this, the interpreter
20:12 dalek MoarVM/moar-jit: supplies the boolification function with 'true' and 'false' continuation
20:12 dalek MoarVM/moar-jit: addresses. This is not feasibile for the JIT because bytecode
20:12 dalek MoarVM/moar-jit: addresses do not correspond directly to JIT addresses. So instead
20:12 brrt joined #moarvm
20:12 dalek MoarVM/moar-jit: these ops are transformed as it were into the sequence of istrue /
20:12 dalek MoarVM/moar-jit: isfalse followed by if_i. Register space outside of the range of locals
20:12 dalek MoarVM/moar-jit: (that is to say, in the args buffer) is used to store the temporary
20:12 dalek MoarVM/moar-jit: result of istrue/isfalse. It is conceivable this might fail, but
20:12 dalek MoarVM/moar-jit: it seems to work now.
20:13 FROGGS_ brrt++
20:14 brrt jnthn++ for suggesting the solution, by the way :-)
20:14 brrt hmm let's not celebrate all the way yet, though
20:15 brrt it appears that nqp actually has a frame that has no args space (and thus, no locals)
20:16 * brrt wonders how it ever managed to call then
20:18 brrt ehm, not no locals
20:19 jnthn no locals? o.O
20:19 brrt i'm wondering if it could be OK to increase the allocated size
20:19 jnthn I'm not sure how we can end up with a frame with no locals...
20:19 brrt no, i don't mean no locals, that's wrong :-)
20:19 brrt i mean no space for the args buffer
20:19 jnthn ...
20:20 jnthn Every frame gets that, though.
20:20 brrt i supposed so
20:20 jnthn (See allocate_frame in frame.c for details)
20:25 brrt wait, i think i see
20:25 brrt num_locals = 62, work_size=384byte (48 registers), dst reg=47
20:25 brrt i think this is inlining and /me taking the wrong work size allocated
20:26 jnthn You need to look at spesh_cand->num_locals really
20:26 jnthn Or are you?
20:26 jnthn And do we have the wrong size allocated?
20:27 jnthn This could relate to the segv [Coke]++ RT'd earlier on...
20:27 brrt i think i'll show you :-)
20:29 brrt https://github.com/MoarVM/MoarVM/commit/8f5e4f0bb1ad3af83f7a844da11579dd6a719a5d
20:30 brrt basically, i use the work_size of the staticframe, not of the spesh graph
20:30 brrt (i don't have the work size of the spesh graph, really)
20:30 brrt ah, i see
20:31 brrt work sizes are computed for candidates, not for spesh graphs, and they are related to the num_locals by the compunit max callsite size
20:31 brrt anyway, i still want the last register
20:33 jnthn Yeah, there you're using the work size of the static frame, which is going to be the wrong answer for anything with inlining.
20:34 jnthn And as you noticed, work_size lives in spesh_candidate
20:34 jnthn But I guess we didn't compute that yet..
20:35 brrt well, we did or did not, it's not important, i don't have the candidate in the jit graph building, just the spesh graph
20:35 brrt repeating the computation is simple enough, of course :-)
20:35 jnthn You can figure it out, though, by doing num_locals + sf->body.cu->body.max_callsite_size
20:35 jnthn Where num_locals is the one from the spesh graph
20:35 jnthn Oh, and - 1 on the thing I just gave you.
20:36 brrt :-)
20:36 * brrt is committing that as we speak
20:38 brrt and pushed
20:38 dalek MoarVM/moar-jit: c0d56a2 | (Bart Wiegmans)++ | src/jit/graph.c:
20:38 dalek MoarVM/moar-jit: Compute the last register index correctly
20:38 dalek MoarVM/moar-jit:
20:38 dalek MoarVM/moar-jit: Inlining changed the size of the work buffer, so it had
20:38 dalek MoarVM/moar-jit: to be recomputed. Unfortunately I'm not able to use the
20:38 dalek MoarVM/moar-jit: recomputed value in the spesh candidate as that structure
20:38 dalek MoarVM/moar-jit: is unavailable to the JIT.
20:38 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c0d56a2f2e
20:39 brrt i do notice two failing tests in nqp, although they seem to be parsing errors
20:40 jnthn Well, you're likley JITting part of the parser... :)
20:41 brrt true
20:41 brrt but that would imply i've got errors, and... that'd be an issue
20:42 jnthn ;)
20:44 brrt /if/ there's a bug, it's a subtle one, that's for sure
20:46 jnthn Well, MVM_JIT_DISABLE will tell you ;)
20:46 brrt it's a JIT bug :-(
20:52 brrt problem seems to be contained in smrt_numify / smrt_strify
20:52 brrt but let's see
20:55 brrt yep, smrt_numify is our problem
20:56 brrt seems kind of likely we're passing it the wrong thing
20:56 brrt we / i
21:00 jnthn Glad you could at least triangulate it quickly to one op
21:02 brrt yes.. but i'm not sure about what to do with it
21:02 brrt or 'why does this happen'
21:02 jnthn Well, could log what smrt_numify receives as args without JIT
21:02 jnthn Then same with JIT
21:03 jnthn And diff
21:04 brrt hmm yes
21:05 brrt not sure how much that'll help, though, and i'm afraid it could also be a decont issue
21:07 brother joined #moarvm
21:08 jnthn bbi10
21:12 brrt hmm, now i suspect deocnt is the problem
21:16 brrt smart_numify isn't the problem, that's for sure
21:16 brrt but why would decont be?
21:21 brrt (why wouldn't it, other question)
21:29 brrt y u no work!
21:29 brrt i'll look at this further tomorrow
21:29 brrt left #moarvm
22:10 * jnthn is having a hard time reproducing the SEGV [Coke] reported, or the related http://paste.scsys.co.uk/407476
22:15 timotimo aaw, no working decont yet? :(
22:15 [Coke] jnthn: the linux box is aborting the test, not sure if it's also segfaulting. my mac is definitely segfaulting.
22:16 [Coke] Do you have access to host07?
22:18 [Coke] weird. test fails when run as "prove -v -e t/fudgeandrun t/spec/integration/99problems-51-to-60.t", but not when run as ./perl6-m t/spec/integration/99problems-51-to-60.t (on host07)
22:19 [Coke] (with the fudge directive removed)
22:20 [Coke] ah. jnthn: try using this wrapper:
22:20 [Coke] #!/usr/bin/env perl
22:20 [Coke] exec "ulimit -t 120; ulimit -v 25000; ulimit -c 0; nice -20 ./perl6-m @ARGV"
22:21 [Coke] at some point, if you reduce the memory available, it segfaults.
22:21 [Coke] reduce it too much, you get nice: error while loading shared libraries: libc.so.6: failed to map segment from shared object: Cannot allocate memory
22:21 [Coke] at -v 25000 you get the segfault pretty quickly.
22:21 [Coke] s/the/a/, anyway
22:21 [Coke] (host07 lacks gdb, so I cannot verify)
22:22 [Coke] ... no clue how to ulimit on windows.
22:22 jnthn Me either, which is where I've been trying to hunt it.
22:24 jnap joined #moarvm
22:25 [Coke] most of the stuff I see is "twiddle it after it's started", which doesn't seem to help.
22:25 [Coke] jnthn: http://www.microsoft.com/en-us/download/details.aspx?id=20028 ?
22:26 [Coke] Looks like a more general tool than "limit my memory"
22:29 [Coke] Also - I asked for this for parrot ages ago - it'd be nice if moarvm took a parameter that limited how much memory it could allocate.
22:44 lizmat joined #moarvm
22:48 jnthn [Coke]: Hm, that didn't help much. I'll have to try it over on Linux, but too tired tonight.
22:48 woolfy joined #moarvm
22:54 lue joined #moarvm
22:58 * jnthn gets some rest &
23:17 [Coke] ah well. jnthn++
23:17 timotimo jnthn++ and gnite++ :)

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