bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnubg] Re: Gnubg exes. - Seems Good


From: Christian Anthon
Subject: [Bug-gnubg] Re: Gnubg exes. - Seems Good
Date: Fri, 21 Aug 2009 23:27:45 +0200

SSE2 gives an improvement in speed and accuracy of the sigmoid function.

Christian

On Fri, Aug 21, 2009 at 12:00 PM, Michael Petch<address@hidden> wrote:
>
>
>
> On 21/08/09 3:47 AM, "Massimiliano Maini" <address@hidden> wrote:
>
>> Michael Petch <address@hidden> wrote on 20/08/2009 19:57:40:
>>
>>>
>>> Okay, this release compares to other outputs, and does seem to fix
>>> some fringe plays (Like KeeneĀ¹s). It also was stable, I had no
>>> crashes doing some long analysis and a few rollout.
>>
>> I did some testing on my side too, to check results across the
>> different compiling options.
>>
>> For each of the 24 no-gui exes I have (wmt/gmt/nomt X allsse2/allsse/
>> sse2/sse/nosse X -O2/-O3 = 30, but the allsse2/allsse -O3 combos crash,
>> even in CLI, hence I have ony 24 working exes) I run a 2/2ply analysis
>> of a 7pt match and diff the resulting sgf files.
>>
>> The only "significative" numerical differences are between sse2/allsse2
>> and the others, but this is probably due to the new sigmoid code (faster
>> but a bit less accurate/different, if I'm not wrong).
>> In terms of meaningful output (total, error rate etc), the differences
>> I've seen are of 0.002% MWC (in total error) between nosse and sse,
>> a bit larger in case of sse2 (due to the sigmoid probably), 0.2% MWC.
>>
>> I have the output in case anyone is interested in having a look.
>>
>
> I have seen in the past the tiny discrepancies between NoSSE and SSE, so in
> all likelyhood the SSE2 code would probably be a bit different. Jon would be
> able to confirm/deny this finding.
>
> I would not rely on using allSSE2 and allSSE for release builds based on the
> fact they appear to give unusual problems (crashes etc).
>
>>> The question would be, should we wait for Christian to fix the bug
>>> you discovered with bad end of game cube/passes(and clear analysis)
>>> and then rebuild a new release?
>>
>> I would say no, anyway it takes me a few clicks to build a release.
>>
>
> I agree, the highlight bug appears to be cosmetic in nature and doesn't
> affect error rates from what I observed. I say we live with it for now.
>
>> Point is, how do we distribute it, since issues gnubg.org are not
>> yet solved (I think)..
>>
>>
>
> Christian and I have access to webservers independent of gnubg.org. I was
> intending to put a copy at www2.capp-sysware.con/downloads where I put some
> OS/X builds in the past. This would only be temporary until Gnubg.org
> resumes normal operation.
>
> I have cleared out the ftp folder you sent files to. If you are confident
> you have the files right, can you upload all the files you believe we should
> make available, and then I will move them to my webserver and post links on
> the mailing list (And BGO).
>
> Thanks,
> Michael
>
>
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]