[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] Lua 5.3.0 (work1) now available
- From: Todd Coram <todd@...>
- Date: Tue, 09 Jul 2013 17:09:17 -0400
On Tue, Jul 9, 2013, at 04:53 PM, Justin Cormack wrote:
> On Tue, Jul 9, 2013 at 9:38 PM, Tim Hill <email@example.com> wrote:
> > [snip]
> > Just so I understand, what was the rationale for choosing 64 over 32 as the
> > integer size? 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).
> All OSs even 32 bit ones now make you deal with 64 bit quantities,
> such as filesizes, timestamps, packet counts, free space on disks and
> so on, and often other 64 bit interfaces. Some of these are hard to
> manage with only 56 bits, such as bitfields. You do not use them a lot
> necessarily, but when you do they are pretty essential.
A good point.
I work with (mostly embedded) 32-bit platforms and would heartily
welcome 64 bit ints as norm. I expect some performance (and size)
penalty from just using Lua (instead of C). Forward looking design
favors 64 bits. Currently, (default floating point) Lua on hardware
without FPUs are taking a performance (and size) hit. Going 64 bits
shouldn't cause any additional performance/size woes.