On Tue, 26 May 2009, Mindaugas Kavaliauskas wrote:
Hi,
> Sometimes I return in my mind to more general solutions, like changing
> compiler to generate expression tree instead of code, typed variables, etc.
> The last nice source of ideas I found is Lua virtual machine. In Lua 5.0,
> VM was rewritten from stack based machine to register-based machine. This
> increased performance about 20%. Instead of:
> PUSHLOCAL 1
> PUSHLOCAL 2
> ADD
> POPLOCAL 3
> they use:
> ADD 3 1 2
yes but if you look carefully then you will find that number of registers
in such implementation is reduced to 256 what also reduce maximal number
of local variables which have to be less or equal (depending on code) to
the number of registers. To keep compatibility with clipper we will have
to use different opcode set which will not be such optimal. The tables with
constant values are quite interesting method of RT speed optimization with
some additional cost of startup initialization but here I also see some
serious limitation for the maximal number of items.
I do not want to say that moving from stack to register based language
is bad idea. I only want to say that some improvements reached in LUA
cannot be adopted to Harbour without introducing some limitations to the
language.
> Here is some old table with one more Lua column:
> No Test code Harbour PHP Python Ruby Java Java+JIT Lua
> -----------------------------+------+------+------+------+-------+------+
> 10'000'000 times:
> 11 nJ+=nI*2+17 4.61 3.41 6.54 25.53 1.36 0.08 0.63
> 12 nJ+=17+1+...+1+nI*2 4.61 6.10 6.62 45.86 1.36 0.08 1.63
> 13 nJ+=nI*2+17+1+...+1 4.62 5.95 12.96 45.78 1.92 0.17 1.56
> 200'000 times:
> 21 cI:=cI+"a" 0.08 6.70 0.11 25.80 1641.766 1650.437 23.50
> 22 cI+="a" 0.08 0.07 0.12 25.83 1649.344 1654.735 -
> 31 AADD(aI,{nI}) 0.18 0.29 0.32 0.20 0.76 0.40 0.16
> 32 AADD(aI,{aI[nI-1... 0.25 0.34 0.38 0.39 0.92 0.40 0.18
> -------------------------------------------------------------------------
> 11 Mem Usage (KB) 2680 4296 162400 3244 6684 6892 1464
> Instruction count 180 150 143 105 202 35
>
> Lua is very fast on numeric operations. A few differences to Harbour here
> are: all numeric are double (no integers); no widths and decimals are
> stored for numeric value. This saves some time for overflow check, integer
> <-> double conversion, result format. Lua has only 35 instructions! In Lua
Using only double for numeric holder is interesting solution, f.e. CLIP
also uses only double values. Anyhow it introduce problems for 64bit
integer support. IEEE758 double value gives effectively only 53 bit
precision so it cannot be used as holder for 64bit values without some
precision lost.
This example forces double usage so it will prefer languages which uses
only double values.
Anyhow here we have also good example of speed improvement which can be
reached with register based VM by reducing number of OPCODEs.
But such partial reduction is also done for -gc3 output (of course is
not comparable to register based VM) and if make some speed comparison
for -gc3 and -gc2 then you should find that in such examples the difference
is also quite huge - noticeable bigger then average speed difference between
-gc2 and -gc3 code.
> all arrays are assocciative arrays and they have a good performance for it
> also.
Internally they can use two different representations: hash and indexed
arrays. I do not remember your exact test code but I guess LUA detects
it's indexed array and do not use hash array for internal representation.
> http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf
> http://www.inf.puc-rio.br/~roberto/talks/lua-ll3.pdf
Nice. Thank you for above links.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
