[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Some ideas
- From: Mike Pall <mikelu-0605@...>
- Date: Fri, 12 May 2006 14:49:35 +0200
Hi,
Sokolov Yura wrote:
> No, I didn't. But I use gcc4.0.2 and --with-cpu=pentium4 - that could be an
> answer ;-(
Seems to be a buggy version. Changing the alignment rules for
structure elements would completely break the x86 ABI.
I've checked GCC 3.3.x and GCC 4.1. No matter which flags I try,
I always get the correct result of sizeof(Table) = 32.
> What about #1 in original message.
Umm, I guess the Lua authors would be more qualified to answer.
Anyway ... have a look at Python (CPython to be exact). Their
extension API lets you freely store pointers to internal objects.
Sounds great? Well ...
Some consequences: they are pretty much tied to their reference
counting garbage collector forever. And they can never switch to
a tagged value concept either. So every tiny little integer
number object has to be allocated and reference counted (yes,
they preallocate -5..100, but this helps only a bit). And don't
let me get started about the required heap allocation of an
argument tuple for every C function call ...
And worst of all: the reference counting logic is spread out over
large parts of the source and in every extension. I recently had
the dubious pleasure to find and fix tons of memory leaks (mostly
refcount bugs for uncommon cases) in a Python extension. No fun.
> Drawbacks:
> - opening implementation details to programmer
That about sums it up. I doubt the Lua authors would go for it.
The environment table for userdata objects can be used as a
simple linear array of TValues. You can easily build any data
structure on top of it (using ints as indexes into the array).
IMHO rawgeti and rawseti are pretty fast.
The best way to decide this issue is of course to create a
benchmark. Use a userdata object implementing a complex data
structure. Compare the implementations of it using either the
standard API or a direct access API (fake it by just using the
internal headers directly).
You could use my queue object (search the list archive) or maybe
a simple binary tree. I think the results should be interesting.
Maybe some other optimizations come out of it (e.g. index2adr is
too large to be inlined). Keep us posted if you find anything!
> Yes, my thoughts could be (and are) dilettantish, so I would
> like to learn about your opinion.
Nobody said so. Your thoughts are welcome. Do not interpret
silence as ignorance. The Lua authors are just very hesitant to
answer to this kind of postings.
My take on it: if you suggest several things and you don't get a
reply for one of them, this doesn't mean anything. It usually
means a more detailed response is needed, weighing in on the
advantages and disadvantages. I guess the Lua authors just don't
have the time to do this.
Consider it a brazilian oracle -- some of your ideas may end up
in the next version. Or maybe not. You'll never know until the
next release. Just keep on throwing ideas into the oracle. ;-)
[Yes, this 'no ack, no nack' policy is ummm ... unusual, but you
gotta learn to live with it.]
Bye,
Mike