[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Lua number type and 64-bit machines
- From: Vaughan McAlley <ockegheim@...>
- Date: Sun, 8 Mar 2009 16:35:56 +1100
In World of Warcraft, GUIDs (globally unique identifiers) apply to
every player, NPC, etc and are 64-bit integers. They arrive in the Lua
engine as 18 byte strings like "0x000000000E3A67B2". This works quite
well as you usually only need check for equality or use them as keys
in a table. Many combat events per second arrive, each with source and
destination GUIDs, spell names etc. Lua handles the strings
efficiently, and (though it would be impossible to test) I don't
imagine performance would be much faster if Lua handled 64-bit ints.
Just my opinion though.
2009/3/7 Sam Roberts <firstname.lastname@example.org>:
> On Fri, Mar 6, 2009 at 8:01 AM, John Barham <email@example.com> wrote:
>> I do recall being bitten by a bug in a 3rd party Python module running
>> on 64-bit Linux that assumed that process ids could fit into 32-bit
> Strange, pid_t is 4 bytes wide on my AMD64 (linux 2.6.22-16 x86_64).
> Also, I was pretty sure Linux can't handle more than 32K of pids, but
> maybe its choosing pids that are scattered through a larger integer
> To the original poster:
> Lack of larger numbers can be annoying. I've had the problem with a
> codebase that used a lot of uint64s as identifiers. Here's my
> There are people who like lua so much, they would use it for
> everything. That's fine, but the way I look at is that it's not a
> general purpose language like python or ruby, pre-existing in a
> package ready to be used for many tasks.
> For example, you can't even get a pid into your lua program with the
> standard lua library. You have to build a C binding to fork(), or
> getpid(), or something.
> Lua exists as a set of flexible language mechanisms you can use to
> create an efficient, portable, application-specific programming
> language. I'm using it right now for implementing network protocol
> tests, for example.
> So, what needs to be done is to up the abstraction level from "64-bit
> integers that might be pids", to something that is a pid.
> After all, pid's aren't really numbers. You can't add two together, or
> add 1 to a pid and get anything meaningful.
> So, for your application of lua, if process manipulation is part of
> what you need to do, you should implement a pid type that supports
> whatever you need supported. Comparison operators, methods that look
> up the name of the process, :kill(), etc. Whatever it is your
> application needs to do to with pids.
> A quick-and-easy way to do this if you don't want anything other than
> a value you can pass to/from C code and identity comparisons between
> values, is to use lightuserdata. It should be 64-bit wide on a 64-bit
> system, and exists for this purpose.