Yes I wouldn't have been surprised by minimal measurable speed increase, but wasn't expecting a fairly large slowdown.
I was intrigued enough to dig a bit deeper on Lua 5.3. I forgot to mention I am running Windows 7 64 bit, but compiling Lua53 as a 32 bit App.
I measured a few numbers for the default Lua build of 64 bit integers and then recompiled for 32 bit Lua Integers. Results shown at end of mail
Yes. its great that Lua53 runs much faster on low end CPU's due to the new integer types, but its unfortunate there is a noticeable hit on a modern PC for simple things like for loops
This gives rise to nonsense Lua53 optimisations like this
for i=0, 10000 do
changing the above line to .........
for i=0.0, 10000 do
gives me an instant 20% code speedup for the loop
The results below show that a default 64 bit integer for loop variable is 20% or so slower than using a double, I wondered how much of that is due to the Lua53 implementation or is it inherent in the CPU silicon ?
A quick test to try and answer that was to write a few different for loops in raw C code
That gave me approx.
C code int32 loop variable too fast to measure sub 1 mS
C code int64 loop variable 9.9 Secs to execute
C code double loop variable 19.7 Secs to execute
C code float loop variable 53 Secs to execute
In raw C an int64 is less than half the execution time of a loop using a double. So this might indicate there is room for LHF and Roberto to optimise Lua53 some more so we don't see the performance hit on a fast PC caused by 64 bit integers ?
Another surprising number was how bad it is to use a float as the loop variable, I guess this must be because the CPU's floating point silicon is designed and optimised for double floating point numbers.
> Date: Sun, 13 Jul 2014 15:43:19 +0700
> From: email@example.com
> To: firstname.lastname@example.org
> Subject: Re: Puzzled by simple test with Lua 5.3
> On 13.07.2014 7:01, Geoff Smith wrote:
> > Instead of the anticipated slowdown I got a speed up ? What the heck
> > is going on here ?
> My first guess is that it might use 64-bit integers even on a 32-bit
> machine. No idea if it's true or not.
> Best regards,
> Sergey Rozhenko mailto:email@example.com