Return to BSD News archive
Xref: sserve comp.lang.sather:613 comp.os.386bsd.apps:934 Newsgroups: comp.lang.sather,comp.os.386bsd.apps Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!paladin.american.edu!howland.reston.ans.net!agate!ames!pacbell.com!amdahl!amdahl.uts.amdahl.com!agc From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: Eiffelstone benchmark in Sather Message-ID: <1994Feb11.133155.13459@uts.amdahl.com> Organization: Amdahl Corporation, Sunnyvale CA References: <2j9cl3$e4g@network.ucsd.edu> <2jcbtf$op9@network.ucsd.edu> Date: Fri, 11 Feb 1994 13:31:55 GMT Lines: 71 In article <2jcbtf$op9@network.ucsd.edu> mbk%anl433.uucp@Germany.EU.net (Matt Kennel) writes: >[...] >Following the dictum that 'if something seems to good to be true, then it >probably is', I re-examined my code. Sure enough, a bug. (In bin_tree.sa, >it never built right nodes. Oops.) It seems that two lines got munched >while editing by accident. I re-ran the tests with the fixed Sather >version, and performance was much more like the C version, as expected. For >kicks I also include the result with run-time checking turned on. (The >small difference shows that memory management predominates) > >User CPU time in seconds is shown. > > C 6.2 13.5 29.1 80.6 > Sather 0.5 5.6 11.8 25.5 70.9 > Sather w/ check 6.2 12.8 27.4 74.9 > ----------------------------------------------- I tried this on some machines around here, firstly on the old code (where the right side isn't built properly - sorry, Matt, but it's interesting) 5k 10k 20k 50k NeXTstation, NeXTSTEP 3.1, 16MB RAM, 33MHz 68040 1.1 2.2 4.7 12.3 386 clone, NetBSD-current, 8MB RAM, 386DX/40 + 387 2.2 4.4 8.9 22.0 SPARCcentre 2000, Solaris 2.3, 128 MB RAM, 4*50MHz SPARC 0.3 0.7 1.3 3.4 i486, NetBSD-current, 16MB RAM, i486DX2/66 0.7 1.4 2.4 5.8 and now the new code: NeXTstation, NeXTSTEP 3.1, 16MB RAM, 33MHz 68040 3.1 7.3 15.2 38.2 386 clone, NetBSD-current, 8MB RAM, 386DX/40 + 387 -- machine unavailable -- SPARCcentre 2000, Solaris 2.3, 128 MB RAM, 4*50MHz SPARC 2.8 5.7 12.3 36.5 i486, NetBSD-current, 16MB RAM, i486DX2/66 2.3 4.7 11.4 33.4 (Figures are best user CPU secs from two runs.) Interesting things from these results: 1. The SPARCcentre blew everything away with the old code, but is only just there with the rest with the new. (gcc and SPARC leaf functions?) There was no multithreading, though, so it only would have used one of the CPUs - it's designed for throughput, not crunchability, right? 2. I was quite impressed by the speed of the 486, especially on the second (real) test - what we're really measuring here is CPU speed, right? 3. 486 performance gain over 386+387 combination is probably due to chip architecture issues. (It's the same machine and disc (IDE), I just changed the motherboard around). 4. Compared to Matt's figures for a SPARCstation 2, with standard Sun malloc, 486 (with NetBSD-current) seems to do quite well. 5. With 50000 objects, there's not much to pick and choose between any of the machines on which I put sather 0.5.3. (All with gcc, and standard malloc) 6. Why did the SPARC do so much better on the old code? Thanks for the Satherstone benchmark, Matt. I've cross-posted this to comp.os.386bsd.apps (and not to any Solaris newsgroups, on purpose). Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation]