lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hmm. The "int patch" discussed on the list a few times actually allows you to use int64 and doubles, as well.

This means, you'd get full int64 range for any integer numbers, and doubles for the rest. The benefits? Remaining in 8 bytes per number value, and perhaps some performance benefit too (long doubles are hardly hw accelerated, are they?)

1. with the "int32/64 patch" approach, numbers would still be doubles, only accuracy would be enhanced. so extensions would not mind.

2. I've used the exact life.lua :) for such measurements, gathered for x86, ARM (no FPU) and PowerPC platforms. Would like to join you, and your platform in.

3. agreed, but a separate issue.

4. with the patch approach, you'd spare a lot of double/int rounding, since things like loop indices only live as integers all their life.

Interested? :)


Sam Roberts kirjoitti 21.7.2006 kello 20.18:

Our system uses a lot randomly generated uint64s that can't be
truncated, and while we have a UINT64 class, using it is a pain, they
are too big to be numeric literals, complicates the C bindings, etc.

It occurs to me that long double is big enough to represent a UINT32
without truncation.

I'm working through the changes right now, I think the conversion on
input is working, but some locations in the code are down-casting
lua_Number before printing it. I'm ferreting them out, and I'll post the
diffs when I get it working, but I could use some advice:

- is this a bad idea that I should forget about? will it make it more
  difficult down the road to integrate 3rd party lua extensions, for

- can anybody suggest some simple benchmarks to get a feel for what, if
  any, impact this has on general (non-numeric intensive) lua
  performance? I was thinking of using life.lua, and stubbing out the

- Would extending the numeric literal syntax to include hex
  initialializers be a bad idea? I'd really like 0xffff to be a valid
number in lua, decimal isn't so readable for the kind of stuff we do a
  lot of.

- Does that fast rounding trick have an equivalent asm for long double?