|
00:06
skids joined
|
|||
| [Coke] | (hesi | 00:24 | |
| timotimo | he what? | 00:26 | |
| geekosaur | ...hesiod? | 00:40 | |
| [Coke] | weird. | 01:08 | |
|
01:18
stmuk_ joined
|
|||
| geekosaur | (for maximum confusion that probably should have been "odd." :p ) | 01:20 | |
| [Coke] | he! | 01:25 | |
|
02:11
lizmat_ joined
07:11
FROGGS joined
|
|||
| [Tux] | test 21.727 | 07:59 | |
| test-t 12.210 | |||
| csv-parser 25.203 | |||
|
08:57
RabidGravy joined
|
|||
| dalek | ast: 4626476 | lizmat++ | S03-operators/buf.t: Add some Blob/Buf.allocate/reallocate tests |
12:55 | |
| ast: 90c27df | lizmat++ | S03-operators/buf.t: Also check Blob.reallocate failure And some better messaging |
13:51 | ||
|
13:56
RabidGravy joined
|
|||
| lizmat | afk for the next 10 hours or so& | 14:07 | |
|
15:04
skids joined
|
|||
| [Coke] | I'll get the release out the door tomorrow; sorry, busy day or three at work. | 15:26 | |
| perlpilot | [Coke]++ | 16:54 | |
| jnthn | m: say 1.87 / 69.83 | 17:39 | |
| camelia | rakudo-moar 54ce66: OUTPUT«0.026779» | ||
| jnthn | m: say 1.87 R/ 69.83 | ||
| camelia | rakudo-moar 54ce66: OUTPUT«37.342246» | ||
| jnthn | wow :) | ||
| timotimo | i really want to see what that wow is for now :) | 17:48 | |
|
17:48
geekosaur joined
|
|||
| timotimo | .o( maybe the size of a heap dump vs the size of a program that doesn's dump ) | 17:49 | |
| perlpilot | whatever it is is 37 times better/faster/stronger ;) | ||
| jnthn | No, nothing to do with heap dumps directly | ||
| More that I'm going to write my heap dump analyzer in Perl 6. | 17:50 | ||
| timotimo | what, really? | ||
| jnthn | And checked one thing I thought would bottleneck it | ||
| And now am fixing it somewhat | |||
| timotimo impressed | |||
| jnthn | timotimo: Yes, because we really need to be able to handle this size of data. | ||
| timotimo | yeah, we do have to | 17:51 | |
| jnthn | And since I'm working on performance stuff, it makes sense that I bang my own head against the places we're just too slow | ||
| timotimo | aye | 17:52 | |
| so this ratio was one thing you tried in your script vs another thing, eh? | |||
| jnthn | Will push soon when spectest is done...provided it comes out ok :) | ||
| [Coke] | jnthn: better you than most other people, for sure. ;) | ||
| dalek | p: 034121e | jnthn++ | src/vm/moar/HLL/Backend.nqp: Put "my" heap snapshot output in place. This replaces the timotimo++ work on this with the format I had in mind and was still putting together locally. |
17:55 | |
| p: 0a8327f | jnthn++ | tools/build/MOAR_REVISION: Bump MOAR_REVISION for heap snapshot support. |
|||
| jnthn | timotimo: If there's anything you're unhappy about in my run of it, let me know :) | ||
| timotimo | only if i get to also change your analyzer script at the same time :) | 17:56 | |
| psch | m: .say for $*ARGFILES | 17:57 | |
| camelia | rakudo-moar 54ce66: OUTPUT«write string requires an object with REPR MVMOSHandle in block <unit> at /tmp/HYZGP9ziKa line 1» | ||
| psch | happens locally with or without a file as @*ARGS[1] | 17:58 | |
| timotimo | too optimized, eh? | ||
| psch | not even sure what it wants to write there... | ||
| timotimo | well, you're calling .say on a file handle | ||
| m: .say("hi") for $*ARGFILES | |||
| camelia | rakudo-moar 54ce66: OUTPUT«write string requires an object with REPR MVMOSHandle in block <unit> at /tmp/WD1_JfyQjX line 1» | ||
| psch | hm, still at 2016.02-194-g5eaa15d locally | ||
| dalek | kudo/nom: 72ba5a1 | jnthn++ | src/core/Str.pm: Add a fast-path for simples cases of Str.Int. This gets a factor of 37 speedup for things like '100'.Int. |
||
| jnthn | As you might imagine, the heap analyzer will need the .Int a lot of Strs :) | 17:59 | |
| timotimo | *neat* | ||
| we recently had a little benchmark in the channel that read a file of an-int-per-line and sorted that | 18:00 | ||
| [Coke] | jnthn: doesn't Perl 6 need that also? | ||
| timotimo | i imagine that becomes a bit faster now | ||
| but it'll not handle a - at the beginning | |||
| jnthn | [Coke]: Need what also? | ||
| [Coke] | the ability to convert a string to an int when parsing perl 6. | ||
| Just wondering if that speeds up the compiler itself. | 18:01 | ||
| timotimo | hm, the compiler will go via nqp's built-in | ||
| jnthn | [Coke]: I think the parser already figures out what it's looking at and manages to do the same thing already. :) | ||
| (So, it already has the win.) | 18:02 | ||
| timotimo | jnthn: you don't get all the warnings from the heap compiler about incompatible pointer types? | 18:04 | |
| jnthn | Nope | ||
| timotimo | src/profiler/heapsnapshot.c:15:13: note: expected ‘void **’ but argument is of type ‘MVMHeapSnapshotCollectable ** {aka struct MVMHeapSnapshotCollectable **}’ | ||
| static void grow_storage(void **store, MVMuint64 *num, MVMuint64 *alloc, size_t size) { | |||
| ^- this times ten or twenty :) | |||
| jnthn | wtf | ||
| I thought the point of a void pointer was to not bitch :/ | |||
| MSVC doesn't :) | 18:05 | ||
| Wonder if void ** doesn't count | |||
| timotimo | that's a possibility | 18:06 | |
| jnthn | Guess we could try taking that and casting to ** :) | ||
| But then you lose the wrong indirection warnings which are useful :/ | |||
| timotimo | taking void * and casting to void **? | ||
| jnthn | Yeah | ||
| Anyways, time for a break :) | 18:08 | ||
|
19:03
sortiz joined
19:22
FROGGS joined
|
|||
| nine | Oh, it seems like I've made it through compilation of the EVAL itself and it's now dieing on serializing the outer comp unit | 19:43 | |
| [Coke] | progress? | 19:53 | |
|
20:12
synopsebot6 joined
|
|||
| nine | I like to think so :) | 20:14 | |
| [Coke] | \o/ | 20:43 | |
|
22:49
AlexDaniel joined
23:11
Woodi joined
23:55
Ben_Goldberg joined
|
|||