 |
lua-l archive |
|
|
||
|
That worked. Performance is MUCH better now. Thanks.The real problem is how portable that code is.
Hashing a block of memory that contains an IEEE 64bit floats should always give the same result. Of course compiling lua with IEEE 32bit floats or integer number types will give a different hash for the same number.
Is this a problem? Where are these hash values stored? Only in memory in active tables as far as I know. So the only real danger is if you somehow manage to pass a live lua_table in memory between lua instances with different number types. If you do that, you're already in trouble since you just hosed the garbage collector and the string interring system.
Is there another case where it matters? Does compiled lua bytecode contain pre-calculated hash values? Isn't that case already broken if the number formats are assumed to change between compiling instance and loading instance of lua?
Russ