[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] SlugGo approach: GNU vs.Goliath
Hello,
Weird this email reached me after i had unsubscribed from the go mailing
list for the bullshit i saw written there.
Diep3d happens to have both openGL support as well as i have an integer
engine.
First a simple misunderstanding. The reason why we can use floats for the
3d engine without problem is because the weak spot is the GPU card, not the
software. Logically that they could not measure difference, because 99% of
all system time gets eaten by the graphics card and not in software.
I bet they forgot to tell you that.
We would prefer showing highpoly graphics of around 80000
polygons/triangles, but the graphics cards just can't handle it. That's why
we limit it to more or less 10000 polygons/triangles (note that polygons
and trinagles are not a 1 to 1 match at all!)
Secondly for the chess engine, it is in integers because integers run 3
times faster and eats 100% cpu time when it can get it.
If you do not believe me how slow floating point is, please go to
www.intel.com and get the processor optimization manuals there are there.
You can easily look it up.
The P4 has 1 execution unit for MMX/SSE2, which therefore can execute 1
instruction a cycle.
It has 4 execution units for integers (2 in fact which are double clocked),
but can for other reasons just retire at most 3.
That means integer code runs potential 3 times faster as compared to
SSE/SSE2 code.
In future processors will not have a FPU unit at all. It is all SSE2+ from
then on.
At 08:00 6-1-2005 -0800, Jim O'Flaherty, Jr. wrote:
>Vincent,
>
>John Carmack of Id software, the creators of Quake and Doom III, has
spoken about this issue
>frequently. He is a person who is deeply respected in the PC gaming and
graphics world. In other
>words, he knows what he is talking about in this area regarding Intel
processors (and AMD). Look
>him up if you have any doubts.
>
>The original Doom and Quake engines use optimized integers (no floating
point) for all of the
>internal engine calculations. However, as he was redoing things for the
Quake II engine, he did
>an enormous number of tests and came to discover that moving from
optimized integers to floating
>point essentially did not have a negative impact on his engine's
performance. This is due to the
>massive optimizations that have been occurring for math co-processors.
Since then, he has moved
>all of his stuff to floating point and things doing the integer
optimizations are not worth the
>effort for many reasons. All the video card companies are doing that same.
>
>What confuses me is how you can make such statements so emphatically when
leaders in a field
>clearly contradict your "silly summations". You apparently have the
emotional association for
>"certainty" ineffectively tied to your internal emotional state
"confidence". It appears you say
>things with a deep and intense feeling of "confidence" somehow thinking
that generates certainty,
>which it does not.
>
>Anyway, I have moved to just lightly scanning your posts. I am finding it
difficult to ferret out
>the value in what you write. Don't get me wrong, you do occasionally say
something that causes me
>to re-check my premises and to think through some of my own understanding
and assumptions.
>However, the noise to data ratio for you is sufficiently high enough, I am
moving to mostly filter
>you out.
>
>I have a request for you: Please considering speaking with less fervor and
more questions. Will
>you accept the request? If you do accept this request, it will do wonders
to change the way I
>personally "listen" you.
>
>
>Jim
>
>
>--- Vincent Diepeveen <diep@xxxxxxxxxxxxxxxxx> wrote:
>
>> If you aren't too lazy to do another 5000 optimizations it's 3 times faster
>> than it is now.
>>
>> Vincent
>>
>> At 15:58 6-1-2005 +0100, you wrote:
>> >
>> >
>> >On Thu, 6 Jan 2005, Vincent Diepeveen wrote:
>> >
>> >> At 15:29 6-1-2005 +0100, Arend Bayer wrote:
>> >> >
>> >> >
>> >> >On Thu, 6 Jan 2005, Vincent Diepeveen wrote:
>> >> >
>> >> >> You guys are making jokes i hope about using floating point in
>> evaluation.
>> >> >>
>> >> >> Nothing as slow and non deterministic like floating point. Additional
>> >> >> certain compilers will use all kind of tricks with floating point
giving
>> >> >> massive roundoff errors.
>> >> >
>> >> >Surely you must be joking that these problem are relevant for the move
>> >> >valuation in GNU Go.
>> >>
>> >> It is relevant. It's 2 times slower at least.
>> >
>> >I am absolutely shocked by this news. This makes GNU Go about 0.01%
>> >slower.
>> >
>> >Thank you very much for your help, I am so indebted to you.
>> >Arend
>> >
>> >_______________________________________________
>> >computer-go mailing list
>> >computer-go@xxxxxxxxxxxxxxxxx
>> >http://www.computer-go.org/mailman/listinfo/computer-go/
>> >
>> >
>> _______________________________________________
>> computer-go mailing list
>> computer-go@xxxxxxxxxxxxxxxxx
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>
>_______________________________________________
>computer-go mailing list
>computer-go@xxxxxxxxxxxxxxxxx
>http://www.computer-go.org/mailman/listinfo/computer-go/
>
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/