Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Fri, May 07, 2004 at 06:57:24PM +0200, Leopold Toetsch wrote:
> I tried building with -DDISABLE_GC_DEBUG=1 and the build fails: > ./parrot parrot-config.imc VERSION DEVEL > parrot: src/platform.c:665: Parrot_memcpy_aligned_sse_debug: Assertion `((unsigned > long) d & 7) == 0' failed. Strange. Try Configure.pl --optimize > $ uname -a > Linux switch.work.fotango.com 2.6.4 #2 SMP ... which works here with linux 2.2 and 2.4. > It's the main Fotango development box, and has 4G of RAM. Should be enough :) >> > 0.07 1266.73 0.86 9459863 0.00 0.13 get_free_object_df >> ^^^^^^^ >> >> How big is the live data set during that test? Seems to be rather big. > How do I best measure this? Indirectly:) see the <interpinfo> opcode and function or debugging output of parrot -d > ... The line from top (without GC debug) is: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 31469 nick 25 0 236m 57m 173m R 99.9 1.4 0:16.64 perl > ^^^^ That'ts huge. How much mem does the test console with perl5? >> I don't see any reference to add_free_object, so I presume the test is >> shuffling 9.5 M PMCs around. How much RAM has your machine? > The PMC only used the PMC_data member to store a pointer on to a perl5 > SV body. That's suboptimal :) Please have a look at the timings I posted a minute ago. Stuff the pointer into PMC_struct_val(pmc) and get rid of the C<need_ext> field in the pmc file. This will speed up things considerable (~6 times) but, the question still remains - where are all these live PMCs coming from. Does Ponie anchor everything so that nothing gets collected? Are there any significant trails of add_free_object in the profile? > 342 That isn't much. Something is wrong. > Nicholas Clark leo
