OpenEuphoria

RE: poke - peek Speed?

• Posted by rforno at tutopia.com Nov 13, 2002
• 435 views

Yes, it is correct, because I will provide to it numbers in the range 0 -
32767. But you are right: I am performing less calculations than the poke4 -
peek version. However, the poke4 - peek version surely works by shifting
instead of dividing, or merely moving bytes around, so it should be faster.
Don't you think so?
----- Original Message -----
From: Don Phillips <EuNexus at yahoo.com>
Sent: Wednesday, November 13, 2002 3:25 PM
Subject: 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
>
>
>
>