On Jan 13, 2014, at 8:25 PM, Alex <initrd.gz@xxxxxxxxx> wrote: > Thanks for the info Mike; I just wanted to be sure that it wasn't completely > hopeless before I begin considering and putting effort into the idea. It is not so hopeless, you can use crlibm and replace math functions by ffi calls. http://lipforge.ens-lyon.fr/www/crlibm/ best, laurent > > > On Mon, Jan 13, 2014 at 1:13 PM, Mike Pall <mike-1401@xxxxxxxxxx> wrote: > Alex wrote: > > The article states "you can’t use SSE or SSE2 for floating point, because > > it’s too under-specified to be deterministic", though I find that somewhat > > suspect, and LuaJIT seems to compile with SSE2 enabled by default. > > Yes, that statement is uninformed. SSE *is* the way to get > deterministic IEEE-conformant behavior on x86. > > In other words: if you use LuaJIT 2.0 on a 32 bit x86 platform, > you need to explicitly enable SSE in the Makefile. It's on by > default for x64 (and in general for LuaJIT 2.1). > > > My main concern is whether the trace optimizations or trace recording will > > affect the order of operations or other things that may affect the output. > > That shouldn't affect the outcome, except if you invoke undefined > or unspecified behavior. E.g. converting an out-of-range double to > an integer may yield different results. > > > I think I've also read somewhere that trig functions and square root > > implementations vary as well. > > Yup, that's pretty hopeless. You'll get to enjoy the differences > between hardware implementations, different math libraries etc. > Basically forget the whole idea, if it needs to be cross-platform > and you intend to use anything other than + - * /. > > Oh, and stay away from denormals and infinities, too. Although > there are standard rules for that, many mobile and embedded > platforms take a shortcut and give you 'interesting' results. No > way to tell without trying on each hardware/software combination. > > --Mike > > > > > -- > Sincerely, > Alex Parrill