03-04-2013, 12:21 AM
Hi Boriel,
It's not a bad thing. Had it changed a lot, it might show up some bug or faulty code that might be completing with the correct result (so passing your tests), but doing so in a more inefficient manner.
I'm still curious how zip2 and hisoft manage such fast results - twice as fast - for basic operations in BM7.
The whole Benchmark code is unchanged from where I posted it in this thread on Mar 27, 2011! BM8 uses floating poing LN and SIN - and as an alternative (the bit in brackets) uses my fSin routine, which uses a lookup table to get rough, but reasonable results accurate to about a degree.
It's not a bad thing. Had it changed a lot, it might show up some bug or faulty code that might be completing with the correct result (so passing your tests), but doing so in a more inefficient manner.
I'm still curious how zip2 and hisoft manage such fast results - twice as fast - for basic operations in BM7.
boriel Wrote:Could be. I've changed the FP scheme to consume less (much less) memory, but it's slowest. SHL is also a few T-states slower (the bugfix you pointed). It's my bet that it's related to FP routines. Did you use Float or Fixed? I'm still working in alternative Fast Floating Point (yes, based on your ideas, and a FP routine I'm programming).
The whole Benchmark code is unchanged from where I posted it in this thread on Mar 27, 2011! BM8 uses floating poing LN and SIN - and as an alternative (the bit in brackets) uses my fSin routine, which uses a lookup table to get rough, but reasonable results accurate to about a degree.