03-19-2011, 12:48 PM
boriel Wrote:A Question: Are you using float or fixed? Or both?
BM7 is Integer only.
BM8 uses the sine and ln functions, so is Float.
fSin moves the sin function to Fixed. Still uses ln (float) though.
Compiler Speed Trials
|
03-19-2011, 12:48 PM
boriel Wrote:A Question: Are you using float or fixed? Or both? BM7 is Integer only. BM8 uses the sine and ln functions, so is Float. fSin moves the sin function to Fixed. Still uses ln (float) though.
03-19-2011, 01:55 PM
Added in some Draw Benchmarks:
I also very slightly changed the code to make it easier to use the three benchmarks. I think this added a fixed 0.02 second (1 frame) overhead into the benchmark from another goto. I decided this was near enough to not worry about too much. Clearly the draw code improved at 1.27; though the curved line code is still hampered by the ROM code. It might not be fair to test that part, since it's so rarely used! Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW
03-19-2011, 07:52 PM
britlion Wrote:New benchmarks with 1.2.8.s644. 1.26-r1603 is still the speed king for ZX Basic. Hisoft fastest overall. Most version are "hidden" at <!-- m --><a class="postlink" href="http://www.boriel.com/files/zxb/archive">http://www.boriel.com/files/zxb/archive</a><!-- m -->, and all code history is now stored at <!-- m --><a class="postlink" href="https://code.boriel.net/hg/zxbasic/">https://code.boriel.net/hg/zxbasic/</a><!-- m --> (the mercurial repo), just in case. :oops:
03-25-2011, 08:08 PM
Hi, I've rerun your BM7 and BM8 tests against 1.2.8-s682 with -O3 and BM7 gives 1.05 segs, whilst BM8 outputs 19.05 (the best ever).
These are the code benchmarks I used: Code: ''' BM7 Benchmark by britlion. Code: REM BM8
03-27-2011, 01:37 PM
The complete code I was using is:
Code: #include "fSin.bas" I simple change which start label is active before compiling. Let me run yours for comparison and come back. Incidentally, boriel - my loop counter (i) is an integer. Yours is a byte. I think that's the difference.
03-27-2011, 01:56 PM
Here's the latest with s682:
(using my benchmark suite listed above) Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW It's clearly changed! I also note that the start frame has dramatically changed as well, implying the compiled code gets off the ground quite a bit faster. Wow!
05-28-2011, 03:41 PM
Here's the latest with s696:
(using my benchmark suite listed above) Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW Still holding together. It's hard to put in new features and not have it slow down on the way; this version looks likeit has a couple of frames worth of startup overhead; but that's just fine. Good work, Boriel.
05-28-2011, 05:13 PM
Forgot to mention that sometimes a bugfix means a little overhead: sometimes a previous version is faster because it's compiling a wrong (shorter) code! :roll:
10-13-2011, 12:11 AM
Here's the latest with 1.28 s758:
(using my benchmark suite listed above) Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW Still better than the very fast r1603, but very slightly behind the last version I tested (s682). And of course, still beating the crap out of Sinclair Basic for speed.
10-13-2011, 06:54 AM
Thanks, britlion, for this very valuable info. :!:
A peak value in any of the latest values would have been suspicious and worth investigating. :wink:
10-13-2011, 08:52 AM
Yes, certainly - that's one reason I run these from time to time.
I'm also aware that zip 1.5 compiler manages to create code that completes BM7 in well under 0.5 seconds. That's Still there as a challenge Perhaps static for loops will make a difference, there. It's going to be intriguing to see what difference that makes.
04-13-2012, 10:13 PM
Here's the latest with 1.29 s815:
(using my benchmark suite listed above) Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW hock: Wow. It's faster. Fastest ever, actually. I really hope there aren't any bugs causing this. Boriel - what did you do? THAT IS AWESOME! We still have zip2's 0.46s target and hisoft basic's 0.5s target on BM7 though! But yes - it seems the compiler's internals are running quite a lot faster, which has shaved a not insignificant amount off the benchmarks. I've noticed other programs running faster with this version, as well. Awesome work.
03-03-2013, 06:24 PM
Here's the latest with 1.3.0 s971:
(using my benchmark suite listed above) Code: BM1 BM2 BM3 BM4 BM5 BM6 BM7 BM8 BMDRAW We were chasing zip2's 0.46s target and hisoft basic's 0.5s target on BM7 - but we seem to have lost the speed gain from the last test. Technically the slowest iteration for a few cycles. Bugfixes are unfortunately making the code a little bit more convoluted, I think.
03-03-2013, 07:04 PM
britlion Wrote:Here's the latest with 1.3.0 s971: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).
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. 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. |
« Next Oldest | Next Newest »
|