[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Pattern Matcher
Doesn't your chess program use hash tables? Does having hash tables
make it a cache thrasher? If so, then your chess program could be
writen in java and you could call it a a "memory tester." Didn't you
notice that you can make the tables any size you want to?
As far as IDIV is concerned, I think you must have never profiled your
own chess program if you actually lose a lot of sleep over how fast
the hash table address calculation is. Even just my evaluation
function is orders of magnitude slower than two divisions. You say
you have the worlds most sophisticated evaluation function, I think
you will find two IDIV's per node doesn't even show up on your
profiler. You are making a huge issue out of something that means
nothing.
Mabye tomorrow I will see how many gratuitous IMOD instructions I must
insert into John's program to slow it down enough to measure.
What makes you say that "bad compilers" are not inlining the
functions? That's your fault if you are not running the test
correctly. There is no rule that says you have to run it with a "bad
compiler."
- Don
X-Sender: diep@xxxxxxxxxxxxxxxxx
Date: Tue, 09 Nov 2004 04:41:54 +0100
From: Vincent Diepeveen <diep@xxxxxxxxxxxxxxxxx>
Cc: computer-go@xxxxxxxxxxxxxxxxx
X-Virus-Scanned: by XS4ALL Virus Scanner
X-Scanned-By: MIMEDefang 2.42
No he proved nothing.
99% of the system time goes to cache trashing and the 2 idiotic
instructions like MODULO and IDIV and to bad compilers not inlining the
functions very well.
If you take away those 2 factors you are going to get sick how slow JAVA is.
Sure you can get the program run a factor 20 faster than this. Could solve
c4 already years ago at some major slow hardware with just alfabeta by just
searching millions of nodes a second.
Note that you can cound things incremental very fast with a few ANDs in c4.
At 22:35 8-11-2004 -0500, Don Dailey wrote:
>
>> And it compiles without optimizations.
>
>You are free to compile any way you choose. I used optimizations when
>I ran it.
>
>John Tromp didn't do hard core optimization like we do, for instance
>he was quite happy to use 64 bit values and division, high level
>things that will negate some of the advantages of low level
>programming. When I pointed that out to him he didn't really get the
>point.
>
>Nevertheless, he proved to me that java is easily within 2 to 1 for this
>kind of programming. I really have a hard time
>believing you could optimize the C code to be 3 times faster while
>keeping both programs functionally identical but you are free to prove
>to me.
>
>- Don
>
>
>
>
>
>
>
> From: Vincent Diepeveen <diep@xxxxxxxxxxxxxxxxx>
>
> the program is really programmed by someone who has had a BASIC course
only.
>
> It has 2 pointers which both get used as an array.
>
> He hasn't figured out what are expensive instructions on a processor and
> which are slow.
>
> Example the hashtable you can speedup eyes closed by setting the hashtable
> by a multiple of 2 and then using AND.
>
> Does JAVA have that instruction too?
>
> The program is using dead simplistic loops. No optimization has been tried
> anywhere.
>
> And it compiles without optimizations.
>
> I just will quote the makefile here :
>
> # current options include TRANSIZE PROBES REPORTPLY
> # suggested values for benching are
> # TRANSIZE: 1050011 or 6249979 (see c4.h for other possibilities)
> # PROBES: 8
> # REPORTPLY: 8
>
> DEFINES = -DUNIX -DTRANSIZE=1050011 -DPROBES=8 -DREPORTPLY=8
> FLAGS = -Ofast $(DEFINES)
> FILES = Makefile input \
> play.c c4.h c4.c trans.c time.c types.h
>
>
> CC = cc $(FLAGS)
>
> c4 : play.o c4.o trans.o time.o
> $(CC) -o c4 play.o c4.o trans.o time.o
>
> play.o : play.c c4.h types.h Makefile
> $(CC) -c play.c
>
> trans.o : trans.c c4.h c4.h types.h Makefile
> $(CC) -c trans.c
>
> c4.o : c4.c c4.h c4.h types.h Makefile
> $(CC) -c c4.c
>
> time.o : time.c types.h Makefile
> $(CC) -c time.c
>
> # use the following for optimization levels that preclude separate
compilation
> together : play.c c4.h c4.h c4.c trans.c time.c types.h Makefile
> $(CC) -o c4 play.c c4.c trans.c time.c
>
> MANIFEST : $(FILES)
> ls -l $(FILES) > MANIFEST
>
> shar : $(FILES) MANIFEST
> shar -o c4.shar MANIFEST $(FILES)
>
> tar : $(FILES) MANIFEST
> tar -cf c4.tar MANIFEST $(FILES)
> gzip c4.tar
>
> Is that how you compiled CILKCHESS too?
>
> Also note that gcc is very fucking dead slow.
>
> At 20:20 8-11-2004 -0500, Don Dailey wrote:
> >
> >> Can you give some example code Mark?
> >
> >Vincent,
> >
> >Go to John Tromps web site and download 2 program, one in C and the
> >other in Java. They do exactly the same thing, they are connect-4
> >solvers and do alpha/beta searching. You can time them both.
> >
> >Here is the web site:
> >
> > http://homepages.cwi.nl/~tromp/c4/fhour.html
> >
> >If you think something is wrong, the source code is there. Optimize
> >the C code if you want and see if you can beat it. It is well
> >written.
> >
> >I had this same argument a few weeks ago and I said Java was slow. I
> >didn't argue for long, I tried it for myself and had to retract my
> >opinion.
> >
> >
> >- Don
> >_______________________________________________
> >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/