pancake wrote:
> > I also tried moving one smaller chunk before the main loop to ensure
> > that all the remaining reads were block-aligned, but that had negligible
> > effect, so I've left that complication out.
>
> afaik, unaligned memory accesses in x86 are not performing much worst than
> aligned ones. but this is just an x86-specific thing. arm, mips and sparc are
> much more affected by unaligned mem accesses.
>
> but thats not really a big issue. imho.
>
> cool you did some benchmarks :) can you tell me which performance increments
> you got by tuning block sizes?
Do you mean from testing the aligned-read adjustment, or from the size
of the buffer ("chunksize")? Because I've realised that the way I did
the realignment testing was probably broken; for the different
chunksizes, the system times for repeated resizes were as follows:
(sizes of files and number of repeats varied from box to box according
to the available disk)
insert (r+1)
Core2 P4 Arm P1
0x80000 20.057 19.9061 0.85 10.5859
0x40000 17.762 16.5460 0.6488 9.5203
0x20000 16.783 12.9803 0.6063 9.0292
0x10000 17.001 12.3071 0.5876 8.6795
0x8000 17.512 12.6925 0.5893 8.3565
0x4000 18.402 13.6256 0.6090 8.5908
0x2000 19.773 15.524 0.6582 9.2976
0x1000 23.098 19.0384 0.7778 10.2119
remove (r-1)
0x80000 18.4167 19.1980 0.8702 10.3107
0x40000 16.4820 15.3867 0.6585 9.5403
0x20000 15.2139 10.9970 0.6057 9.0481
0x10000 15.4071 10.2310 0.5880 8.5163
0x8000 15.9167 10.5117 0.5947 8.3223
0x4000 16.4987 11.2030 0.6106 8.4515
0x2000 17.0803 12.9444 0.6514 9.3637
0x1000 20.0386 15.4931 0.7679 9.8752
...so it looks like I misread the Core2 results first time, too.
> >> core->file->size should be updated after resize(), inside the r_io
> >> api (not in the specific plugins)
> >
> > I can't access core->file from inside r_io... there's another function
> > in core/file.c (r_core_file_resize) that's not used anywhere (and
> > treats 0 as a special case), but using a core wrapper like this would
> > add another layer of calls and save 0 LOC.
> >
>
> uhm.. i see the problematic here, but i would suggest you to call riosize
> from rcore after rioresize in order to update the core->file->size. rio is
> independent from rcore. there are not enought reverse dependencies to justify
> callbacks or rcore access by rio.
>
> can you make the patch to update filesize in rcorefile after calling
> rioresize?
I don't think I follow... what use is calling r_io_size() after
r_io_resize() here?
> i've reviewed and applied both patches. you are now in the authors file :)
> it's ok to put your realname here? or do you prefer to put a nickname or
> alias?
My realname's OK for this.
Glyn
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
