|
Parrot 5.10.0 "Sun Conure" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 22 November 2013. |
|||
|
00:12
Psyche^ joined
00:16
kid51 joined
00:20
rurban1 joined
01:20
rurban1 joined
02:00
FROGGS joined
02:21
rurban1 joined
02:44
nnunley_ joined
03:17
kid51_ joined
03:22
rurban1 joined
04:06
preflex_ joined
04:23
rurban1 joined
04:53
rurban1 joined
05:06
benabik joined
05:35
jsut joined
05:36
jsut_ joined
06:52
nnunley joined
07:36
simcop2387 joined
08:14
particle joined
11:09
rurban1 joined
12:09
rurban1 joined
12:45
denisboyun joined
13:10
rurban1 joined
14:06
kid51 joined
14:11
rurban1 joined,
Hunger joined
14:16
MikeFair joined
15:12
rurban1 joined
15:56
denis_boyun joined
16:12
rurban1 joined
16:59
rurban1 joined
17:50
nnunley joined
18:21
benabik joined
19:11
Mike-PerlRecruiter_ joined
19:29
timotimo joined
|
|||
| timotimo | good day | 19:29 | |
| i've noticed updating the line pos cache from nqp's HLL::Compiler is very slow on utf8 strings. i implemented a simple cache to re-use iterators when possible and got it faster by a factor of 2 | 19:30 | ||
|
19:30
sa1 left
|
|||
| timotimo | the cache is in encoding_find_cclass (and i added it to encoding_find_notcclass for symmetry) | 19:30 | |
| FROGGS | timotimo: did you run parrot's test suite? | ||
| timotimo | i should! is it just "make test"? | ||
| FROGGS | think so | ||
| timotimo | will do | ||
| it resulted in a pass, some TODOs were passing as well, but that's probably not my fault :) | 19:34 | ||
| i patched an older version of parrot, though | |||
| 5_9_0 | |||
| i'll try to apply it to master now | |||
| FROGGS | that is not sooo old | ||
| but a pass is still nice, I think parrot's test suite covers pretty much :o) | |||
| timotimo | larry was suggesting to actually put a cache for offsets into strings, but that's a more hairy change that i'd want to either run by the parrot devs first or have someone more experienced implement | 19:36 | |
| i'm surprised i could only get it to be 2x faster, though. i expected the complexity to drop by one power | 19:37 | ||
| it's still like 10000x slower than if you have ucs4 | |||
| but i won't be picky. 2x as fast is good. | 19:38 | ||
| shaves off 7 seconds from the whole rakudo build | |||
| so is the official way to get this in a pull request? | 19:40 | ||
| FROGGS | just make one | ||
| timotimo | will do. | ||
| FROGGS | here is a travis build bot that will show success/failure | 19:41 | |
| benabik | It doesn't run PRs though. | ||
| timotimo | aaw | 19:42 | |
| github.com/parrot/parrot/pull/1027 | 19:43 | ||
| FROGGS | benabik: ohh, I might have mixed it up with #libuv | 20:00 | |
| benabik | Testing #1027 locally, will merge if successful. Looks food at first glance | 20:01 | |
| timotimo | glad to hear :) | ||
| i wasn't sure if other people would agree that my use of static variables to cache that stuff is elegant | |||
| i'm not a thoroughly experienced C programmer | 20:02 | ||
| benabik | That is kinda what static variables are for. | 20:03 | |
| Oh, wait... Are String_iters GC'd? | |||
| Because if they are, that's probably a GC bug waiting to happen. | |||
| timotimo | that's a good question. i wouldn't know how to find it out :( | 20:04 | |
| benabik | Well, the static variable isn't allocated from the GC. It's just a structure. That's fine then. :-) | 20:05 | |
| And if the string is GC'd, it shouldn't be passed in as an argument... | 20:06 | ||
| timotimo | the only bad thing that could happen is when two strings happen to get the same memory address | ||
| benabik | I suppose there's a non-zero chance that the original string gets GC'd and then a new string in the same location gets passed... | ||
| timotimo | hehe. | ||
| but then the find_cclass would have to be started at a kinda late offset | 20:07 | ||
| and it couldn't have had a longer-than-128-bytes string in between | |||
| i could add a comment "if you happen to stumble over a cache false-positive here, contact Timo Paulssen for a sixpack of good beer at this address: ..." | 20:08 | ||
| benabik | heh. | ||
| Hm. I dislike adding possible GC-related bugs. They're nasty to hunt down. | 20:09 | ||
| timotimo | yes. is there a field in the string that i could factor into the comparison? | 20:10 | |
| except for the whole string itself | |||
| string length perhaps? how often is that going to coincide? | 20:11 | ||
| benabik | Almost makes me wonder if we should cache an iterator on the string itself. | 20:13 | |
| arnsholt | I was about to suggest something like that | 20:14 | |
| timotimo | larry suggested something like that | ||
| it's only valuable for varying-width encodings ... | |||
| arnsholt | Or even something like struct longstring { struct string common; ... } so that only long strings incur the storage overhead of the caches | 20:15 | |
| benabik | Probably faster to do it unconditionally than try to figure out what strings it's useful for. | ||
| Hm. maybe. Strings are already kinda chubby. three pointers, four integers. | |||
| timotimo | we've got almost a month of time now :) | ||
| benabik | whoop, 5 integers. | 20:16 | |
| timotimo | unshift_string() not implemented in class 'Hash' - is this something that's changed on parrot's end? | ||
| benabik | Last commit with the string "unshift_string" is in 2011 | ||
| timotimo | huh. | 20:17 | |
| arnsholt | I don't think unshift is an operation that really makes sense on hashes | ||
| timotimo | that's right. but this is in our stage0. how did that happen? | ||
| arnsholt | Oh | 20:18 | |
| timotimo | er, huh. it seems like i'm doing something very wrong | ||
| yup, i was somehow using parts of the old parrot | 20:19 | ||
| yup, it was entirely my fault. never mind what i pasted. | |||
| benabik | My $0.02 added as a comment on the PR. Don't feel wholly comfortable committing it without someone else looking at/thinking about it. | 20:25 | |
|
20:25
MikeFair joined
|
|||
| timotimo | yup, that's fair | 20:28 | |
| i'll get some early sleep today i think | 20:29 | ||
|
21:58
kid51 joined
|
|||