yo
On 05/02/2011, at 18:38, Glyn Kennington <[email protected]> wrote:
> 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
>
strange. the lower the better? is this in time?
usually kthe compiler generates stack aligned variables in the stack frame. for
heap. this depends on libc. glib and gstreamer have some helpers to do this and
speed up memory copies.
> 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?
>
nevermind. its ok in this way
>> 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.
>
ok. btw we are planning a hackaton for the next tuesday. but i will be coding
this saturday... so if you wanna join the party. we can meet in the irc
> Glyn
> _______________________________________________
> radare mailing list
> [email protected]
> http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
>
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
