Re: Light userdata

["Dylan Cuthbert" <dylan@...>]

Hi there,

I don't need integer math on vectors (they are all floats).

The only thing I worry about is the overhead of turning what is basically an
integral type to most CPU's into a full fledged table with a metatable to
boot, that's quite a lot of interpreter overhead to simply access, say, the
"x" element. (and a huge amount to add two vectors together using solely lua
code)

The latest compilers (vis. c, Intel etc) for the pentium use a 16-byte
aligned stack so there are no problems passing 16-byte aligned data around
(they don't pass SSE registers between functions yet mind you).

Its not only the pentium though, almost all game consoles now have 128 bit
aligned vector data that can be copied about and operated on as freely (and
as cheaply) as regular 32 bit integers and floats.

How about an integral *table*? :-)

---------------------------------
Q-Games, Dylan Cuthbert.
http://www.q-games.com

<RLake@oxfam.org.pe> wrote in message
OFB92A3727.042874AC-ON05256D51.004B22A5@oxfam.org.uk">news:OFB92A3727.042874AC-ON05256D51.004B22A5@oxfam.org.uk...
> Hi, Dylan.
>
> I'm glad you like Lua, by the way.
>
> The issue with vector arithmetic is indeed an interesting one; I have been
> thinking about it off and on for a while.
>
> One possibility, if you are using a machine with vector data types, would
> be to make all Lua numbers into 128-bit quantities, which could be three
> 32-bit floats or one 64-bit float; one of the 32-bit slots could be used
> as a tag. This wouldn't work if you required four-element vectors, of
> course, and maybe you do; there would have to be some other indication, I
> guess.
>
> Basically, I don't think it is worth worrying about the integer/floating
> point distinction as long as you have some mechanism to store an integer
> of sufficient size. A 32-bit float is probably not adequate though. Doing
> all arithmetic in SSE registers, for example, is probably not going to
> have as much of a performance hit; interpretive overhead occupies a lot
> more cycles than the difference between integer and floating point
> arithmetic, and indeed on a Pentium it is often actually faster to do
> floating point than integer because of the parallelism possible.
>
> The change to Lua would not be huge; the main issue is that there are a
> number of places in the Lua code where it assumes that you can cast Lua
> numbers back and forth to integers without invoking a library routine; in
> particular, the API assumes that C will "deal with" conversions between
> Lua numbers and whatever you put in the argument, so it is quite common to
> find statements like "lua_pushnumber(L, 1);" or "int i = lua_tonumber(L,
> 3);" in C extensions, including the standard Lua libraries. Routing out
> all these instances would be a bit of a pain, but if you only needed to do
> it in the standard library I think I know all the places that need
> changes.
>
> The other thing is the Pentium ABI itself, which does not use SSE
> registers for argument passing, and which moreover does not allow internal
> alignment of argument lists (so that a 128-bit quantity would be pushed
> onto a randomly-aligned stack location, and then have to be realigned for
> use inside the function.) GCC (and other C compilers) generally have an
> option to optimise stack frame alignment but it can actually pessimise in
> the case of functions with mixed arguments; in particular, functions whose
> first argument is a state pointer. This has an unfortunate effect on
> lua_pushnumber(), for example, in a standard 32-bit pointer/64-bit number
> configuration.
>
> However, I think that *could* be gotten around by some creative use of
> macros.
>
> The question is, is the effort worthwhile in order to produce 3-element
> vectors? It does not seem to me like a very general solution.....
>
> Rici
>