hi
On 05/02/2011, at 11:33, Glyn Kennington <[email protected]> wrote:
> pancake wrote:
> [...]
>> Another modification you should do in r_io_shift() is to work in blocks
>> before mallocing huge chunks in the heap. This is:
>> - use local ut8 buf[4096]; or malloc to 64k (if you can do some
>> benchmarks,
>> we will see which block size is more optimal (4KB, 64KB, etc..)
>
> I tried powers of 2 from 4KB to 512KB. On three test machines (2.2GHz
> P4, 512MB RAM; 2GHz Core2, 1GB; 1GHz ARMv7, ~450MB), 64k gave the best
> results. 32k was slightly better on an older box (Pentium 133MHz,
> 80MB), but that could also have been down to the disk. So I've gone
> with 64k.
wow.looks like you did some benchmarks before sending the patch :) thanks
> 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?
>> 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?
>> Can you resend the patch with those modifications?
>
> Attached.
>
> Also attached is a fix for a Makefile where parallel building was
> breaking.
>
thanks!
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?
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
