Re: [ANN] Lua 5.3.0 (work1) now available

[Tim Hill <drtimhill@...>]

On Jul 9, 2013, at 2:10 PM, Eric Wing <ewmailing@gmail.com> wrote:

> I was a little surprised by that given that integers would
>> seem most useful on more restricted platforms where 64-bit integer is still
>> (moderately) expensive (and also even that many "64-bit" OSes are compiled
>> with 32-bit integers, such as OS X).
> 
> That's not quite an accurate representation of the need for 64-bit
> integers on 64-bit OS's. OS X is fully 64-bit now and 32-bit has been
> deprecated for awhile. (The current OS X requires a 64-bit system and
> the majority of Mac apps have already made the switch to 64-bit.)
> While I don't know what size/types they are using in the kernel, all
> the Cocoa related frameworks are using NSInteger/NSUInteger which on
> 64-bit Mac is a full blown 64-bit number (and has been so since at
> least 2007). This has been a huge pain in binding any OS X related
> APIs with Lua because the numbers get silently mutilated.
> 

Well let's be careful here. A "64-bit" OS like OS X uses LP64 (last time I looked), in which "int" is 32-bits and long/pointers are 64-bits, as do most Linux flavors. This gives the compiler the advantage of the 64-bit instruction set (and the extra GP registers, which is where the big pert boost comes from) but still keeps integers more compact for performance (think cache efficiency etc). NSInteger of course is different.

I was asking because I thought from way back that the move to add integers was driven by poor FP performance on non-x86 systems, but sounds like the primary motivator is widening the integer repertoire.

> It's distributions that people are worried about the defaults for
> interoperability and those will be predominately on traditional
> computers and the large majority of those will be 64-bit machines.

I guess that depends how Lua is positioned for tablets and smartphones?

--Tim