|
Parrot 6.6.0 "Parrothead" | parrot.org/ | Log: irclog.perlgeek.de/parrot | #parrotsketch meeting Tuesday 19:30 UTC Set by moderator on 23 July 2014. |
|||
|
00:04
rurban1 joined
01:36
FROGGS_ joined
02:11
kid51_ joined
05:13
bighugedog joined
05:53
zby_home joined
07:30
basiliscos joined
10:52
kid51 joined
11:53
bighugedog joined
14:01
Chirag joined
14:28
rurban1 joined
16:41
Chirag joined,
basiliscos joined
|
|||
| Chirag | rurban: my test shows pcc-gh1083 (parrot's repo) to be 0.5% slower than current master | 16:48 | |
| gist.github.com/ZYROz/685f80d5df46468b2ba0 | 16:49 | ||
| rurban | that's bad. 64bit linux, right? | 16:59 | |
| Chirag | yes | 17:00 | |
| rurban | cache misses probably, as the .text segment is now a bit bigger | ||
| so you probably got a smaller cpu cache | |||
| Chirag | yes | ||
| rurban | this needs to be tested with cachegrind | 17:01 | |
| Chirag | on my machine itself? | ||
| rurban | yes | 17:02 | |
| Chirag | i will do it | ||
| rurban | let's see if the cache misses relate to the slowness, or if it's something else | 17:03 | |
| Chirag | hmm.. I am now looking at how to use cachegrind | 17:04 | |
| do I give bench.sh to cachegrind (valgrind tool) ? | 17:09 | ||
| rurban: gist.github.com/ZYROz/21f5a6734dd26d86ef74 | 17:26 | ||
| rurban | very interesting. I see no differences at all. which is good. | 17:29 | |
| Chirag | so its the cache misses? | 17:30 | |
| rurban | no, it's not | 17:31 | |
| Chirag | then, what do you figure? | ||
| rurban | i have no idea yet, what else it could be. but that it;s not the cache sounds good. Which means we can merge it | ||
| Chirag | hmm.. do you have a machine with linux-64bit? | 17:32 | |
| rurban | yes, yours is 32bit? | ||
| I see, sorry | |||
| Chirag | no its 64 bit ubuntu but 3gb ram | ||
| rurban | I will try to find a real 32bit machine | 17:33 | |
| Chirag | 32 bit helps to judge better, is it? | 17:34 | |
| rurban | yes, I'll try my old ppc machine | 17:35 | |
| I'm not worried about a single 0.,5% slowdown if the general speed up is > 1% | |||
| I was only worried about too much cache misses with a bigger .text segment | 17:36 | ||
| Chirag | hmm.. and also do you think it would help to check if all methods in args.c actually require direct calling? is it possible that a VTABLE redirection gives better speed for some? | ||
| rurban | There's no realistic chance that VTABLE redirection can be faster than direct calls | 17:37 | |
| Chirag | oh.. alright | 17:38 | |
| rurban | Only if the call_object is really hot, but we replaced all call_object calls, and call_object is still hot as it is the 2nd arg | ||
| Chirag | ok.. | 17:39 | |
| rurban | Now there's no need to keep the call_object vtable in the cache as it's never used | 17:40 | |
| Chirag | maybe I should test my previous tasks now | 17:53 | |
|
18:30
rurban1 joined
19:28
davidfetter joined
21:27
kid51 joined
21:59
cooper joined
|
|||