[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lua-l
Subject:    Re: Question about accessing Lua tables and arrays faster
From:       Steve Litt <slitt () troubleshooters ! com>
Date:       2013-07-28 19:40:27
Message-ID: 20130728154027.30385ddc () mydesk
[Download RAW message or body]

On Sun, 28 Jul 2013 15:06:49 -0300
Jorge <xxopxe@gmail.com> wrote:

> On 28/07/13 09:05, Leo Romanoff wrote:
> > Which means that LuaJIT jitted and interpreted versions take a
> > second and third place overall. Way ahead of the next competitor.
> > -Leo 
> 
> The conclusion I reached stems from this.
> 
> You have a very neat language. It lacks nothing and wastes nothing.
> And you get great performance, specially in relation to the
> hassle-freeness and portability of the deployment.
> 
> If you need more performance, because you happen to need some
> esoteric stuff (for a scripting language), you do not start spoiling
> the language, but try the JIT compiler. You get tons of performance
> at the cost of having to test for hardware support, checking compiler
> logs, and stuff like that.
> 
> And if even then it doesn't have the performance characteristics you 
> need, perhaps it was the wrong language to start with.

The other thing is, the speed difference between Lua array usage and
Python/Perl array usage appears to be 10% of less. It's almost never
worth using a tougher language to get a 10% runtime speed improvement.
As far as C, yeah, when I made my random number generator capable
of quickly calculating billions of primes
(http://www.troubleshooters.com/codecorn/primenumbers/primenumbers.htm),
of course I used C. My mama didn't raise no fool.

Thanks,

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

[prev in list] [next in list] [prev in thread] [next in thread]