Perl 6 - the future is here, just unevenly distributed

IRC log for #parrot, 2014-08-07

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:04 rurban1 joined #parrot
01:36 FROGGS_ joined #parrot
02:11 kid51_ joined #parrot
05:13 bighugedog joined #parrot
05:53 zby_home joined #parrot
07:30 basiliscos joined #parrot
10:52 kid51 joined #parrot
11:53 bighugedog joined #parrot
14:01 Chirag joined #parrot
14:28 rurban1 joined #parrot
16:41 Chirag joined #parrot
16:41 basiliscos joined #parrot
16:48 Chirag rurban: my test shows pcc-gh1083 (parrot's repo) to be 0.5% slower than current master
16:49 Chirag https://gist.github.com/ZYROz/685f80d5df46468b2ba0
16:59 rurban that's bad. 64bit linux, right?
17:00 Chirag yes
17:00 rurban cache misses probably, as the .text segment is now a bit bigger
17:00 rurban so you probably got a smaller cpu cache
17:00 Chirag yes
17:01 rurban this needs to be tested with cachegrind
17:01 Chirag on my machine itself?
17:02 rurban yes
17:02 Chirag i will do it
17:03 rurban let's see if the cache misses relate to the slowness, or if it's something else
17:04 Chirag hmm.. I am now looking at how to use cachegrind
17:09 Chirag do I give bench.sh to cachegrind (valgrind tool) ?
17:26 Chirag rurban: https://gist.github.com/ZYROz/21f5a6734dd26d86ef74
17:29 rurban very interesting. I see no differences at all. which is good.
17:30 Chirag so its the cache misses?
17:31 rurban no, it's not
17:31 Chirag then, what do you figure?
17:31 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
17:32 Chirag hmm.. do you have a machine with linux-64bit?
17:32 rurban yes, yours is 32bit?
17:32 rurban I see, sorry
17:32 Chirag no its 64 bit ubuntu but 3gb ram
17:33 rurban I will try to find a real 32bit machine
17:34 Chirag 32 bit helps to judge better, is it?
17:35 rurban yes, I'll try my old ppc machine
17:35 rurban I'm not worried about a single 0.,5% slowdown if the general speed up is > 1%
17:36 rurban 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?
17:37 rurban There's no realistic chance that VTABLE redirection can be faster than direct calls
17:38 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
17:39 Chirag ok..
17:40 rurban Now there's no need to keep the call_object vtable in the cache as it's never used
17:53 Chirag maybe I should test my previous tasks now
18:30 rurban1 joined #parrot
19:28 davidfetter joined #parrot
21:27 kid51 joined #parrot
21:59 cooper joined #parrot

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

Parrot | source cross referenced