Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crafty profits little from Itanium and Opteron versus Commercials

Author: Matthew Hull

Date: 08:30:43 08/08/03

Go up one level in this thread


On August 07, 2003 at 23:21:56, Vincent Diepeveen wrote:

>On August 07, 2003 at 08:58:21, Gian-Carlo Pascutto wrote:
>
>It is a waste of time to actively PROGRAM in assembly for PC applications like
>this one. I won't say it's a waste for the NT kernel for example. Each new
>generation of cpu's requires an entire rewrite of the program. But well written
>C code keeps portable.
>
>If Frans each new version first has to rewrite in order to get it to work better
>at the new processor then some who read this for the first time now know what
>his daily work is.
>
>Working hard to get the current program ported.
>
>That he manages to make some modifications as well to it is really amazing.
>
>That some people like Sune and i know many other programmers who didn't post
>here but have loads of inline assembly too written. Half of them regrets it now.


With Crafty, you don't need the assembly for a compile.  Only x86 and SPARC
targets have that, and even there it is optional.

So your criticisms of Crafty for having assembly is quite bogus, for it is not
dependent upon assembly at all.  I even compiled Crafty for OS390 (IMB s390
mainframe) under Unix System Services with very little tweaking, and of course
NO ASSEMBLY code.  Runs fine.

I doubt your program could do the same.

MH


>
>Of course taking a look to how assembly works and what is faster for a processor
>is a different thing. Study is never bad. Wasting time on getting routine X to
>work in your own written assembly just to get your program 0.001% faster is
>really a waste of time where you write at the same time that buying an opteron
>is not interesting yet as it is too expensive.
>
>Just buy that bit faster hardware and don't make it in assembly :)
>
>Saves time. Saves money.
>
>Just throw some hardware at it!
>
>Of course i won't say it is smart for everyone to throw 500 cpu's at it.
>
>I'll do that for them with DIEP :)
>
>Oh by the way in case i didn't mention it. I can compile diep at that machine
>because i use NO assembly at it.
>
>I find it very funny to read that most bitboarders first slow down their program
>in case of Sune to get 30% faster using inline assembly :)
>
>Same for Isenberg's Kogge Stone project. Move generation just in those
>registers? Hehehehehehehehehe. Waste of your time Gerd!
>
>First lookup how many clocks that is going to cost in advance then compare
>it with how many clocks i lose in nonbitboards generating at 73MLN nps a second
>at K7-2.127Ghz.
>
>I could get that faster even if i would write out black and white and each piece
>(see how crafty has written out all code there).
>
>But how many cycles do i actually lose a move?
>
>Now how many cycles is that going to be a move using the ambitious kogge stone?
>
>No need for assembly. All i need is a small calculator and an AMD manual to know
>in advance who is going to be faster generating at that opteron :)
>
>>On August 07, 2003 at 08:50:14, Vincent Diepeveen wrote:
>>
>>>But then ones program must be either incredible simple or you must be fulltime
>>>working at your chessprogram!
>>
>>Meh. Assembly languange programming is an art that's learned through
>>practise. I do not do it a lot, so I'm not very good at it. I think
>>it's hard, but I can beat the compiler, which is what matters. You
>>don't do it at all probably, so I guess for you it's even harder.
>>
>>Then there's people like Gerd Isenberg and Frans Morsch, and apparently
>>Sune that eat assembly for breakfast. I guess for them it's easy.
>>
>>I found an old snippet from Gerd Isenberg once that did the same as
>>a chunk of code I had written does. Gerd's version was ""a tad""
>>smaller and faster. I'm not posting details because they're way too
>>embarassing.
>>
>>--
>>GCP



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.