1. Re: Encrypting (and bit-shifting)
John Kinne writes:
> I am fascinated by this discussion. Does it make a difference whether
> Euphoria actually shifts bits, integer divides or float divides? I would
> have estimated that there would be more overhead in analyzing the operands
> than just going ahead and doing the divide. Especially if the divisor is
> not a constant.
I tried: z = floor(x/y) where z and x are declared as integer.
I found that there *is* a big difference in speed
between
(a) - dividing by 2 (or by a constant variable declared and set to 2)
(b) - dividing by some other integer than 2, or dividing by
an integer variable that was set to 2 on an earlier statement
(a) was almost 5x faster than (b) on my Pentium because a right-shift is used,
rather than an integer divide, and because a couple of other
minor short-cuts are taken.
As Ralf correctly guessed, a different intermediate language opcode
is selected when the constant 2 is present. The opcode
known as FLOOR_DIV2 is emitted, rather than the more general
opcode FLOOR_DIV. In any case the floor and / operations are
merged into a single operation so that an integer divide can be used.
Division by a floating-point number will be about 7x slower
than the general integer case. The floor and / operations will
have to be performed separately. Also, Euphoria has extra storage
allocation overhead when it deals with floating-point numbers.
In a more typical interpreted language, you'd expect low-level issues
like these to be trivial compared to the large "interpretive overhead".
In Euphoria, the interpretive overhead has been cut to the bare minimum, so
these machine-level issues are often significant.
Regards,
Rob Craig
Rapid Deployment Software
