RE: poke - peek Speed?
::CODE SNIP::
> I will use it to write to a file values less than 32768 in byte format.
> That
> is why I use integer and not atom arguments.
> Why does the poke - peek version take more time than the other, that
> uses
> division? Using allocate_low instead of allocate, it even takes more
> time!
> TIA.
Is your algorithm for to2bytes correct? Looking into machine.e I see
the fuction int_to_bytes is declared as:
global function int_to_bytes(atom x)
-- returns value of x as a sequence of 4 bytes
-- that you can poke into memory
-- {bits 0-7, (least significant)
-- bits 8-15,
-- bits 16-23,
-- bits 24-31} (most significant)
-- This is the order of bytes in memory on 386+ machines.
integer a,b,c,d
a = remainder(x, #100)
x = floor(x / #100)
b = remainder(x, #100)
x = floor(x / #100)
c = remainder(x, #100)
x = floor(x / #100)
d = remainder(x, #100)
return {a,b,c,d}
end function
You will notice it returns >>> {a,b,c,d} so the first two bytes would be
a = remainder(x, #100)
x = floor(x / #100)
b = remainder(x, #100)
However your version written as:
function to2bytes(integer u)
return and_bits(u, #FF) & floor(u / 256)
end function
Only does the a and x calculation... what happened to b?
If I am correct and your algorithm is slightly off, that will explain
the speed difference.
Don
|
Not Categorized, Please Help
|
|