Traversing a binary

[Per Gustafsson]

oops, the test is not really fair I realized that I had folded out the
second version more than the other three so the results for
 Sub-binaries, little-endian, should be:

BEAM: 10.9 s
HiPE: 1.00 s


On Tue, 5 Oct 2004, Per Gustafsson wrote:


> I've tested the opposite of this, something that avoids
bignums and folds
> the sum whenever it gets close to being a bignum.
>
>
> The program exists in four different versions, the diffrence between the
> programs are wheter or not they create subbinaries and wheter or not they
> take out the 16-bit integer in a little-endian way.
>
> I compare the results with a handcoded version of Tony's program using 992
> as the parameter.
>
> When I compute the checksum of a binary of about 64k 3000 times on a 2.4
> GHz pentium 4 I get the following results:
>
> No sub-binaries, little-endian:
> BEAM: 9.72 s
> HiPE: 0.98 s
>
> Sub-binaries, little-endian:
> BEAM: 9.46 s
> HiPE: 0.86 s
>
> No sub-binaries, big-endian:
> BEAM: 3.37 s
> HiPE: 1.25 s
>
> Sub-binaries, big-endian:
> BEAM: 4.51 s
> HiPE: 1.14 s
>
> Tony's Bignum version n=992:
> BEAM: 2.96 s
> HiPE: 3.72 s
>
> Obviously the little-endian version is only better on a little-endian
> machine, but it seems that the bignum approach is competitive as long as
> one does not native compile.
>
>
>
> The testruns are displayed below:
>
> 39> c(csum).
> {ok,csum}
> 40> hipe:c(csum).
> {ok,csum}
> 41> csum:test().
> {66264,39354,39354,39354,39354,39354,970,870,1220,1130,3890}
> 42> c(csum).
> {ok,csum}
> 43> hipe:c(csum).
> {ok,csum}
> 44> csum:test().
> {66048,17289,980,860,1250,1140,3720}
> 45> c(csum).
> {ok,csum}
> 46> csum:test().
> {66048,17289,9720,9460,3370,4510,2960}
> 47>
>
>
>
>