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 > > > >