Survey -- Who would like to see Rebel8/Mchess ported to win95/win3
Lonnie Cook
To all,
I am curious as to everyone's opinion on whether you'd like to see these two programs ported
to the windows environment. I would like to see them ported because I mostly work
through windows. They would not lose any strength as indicated by Mr. Lang porting his
cg program to win. I'm sure to that many features could be incorporated that are
indicative of the windows environment as well.
Lonnie J. Cook
<lonni...@riconnect.com>
"Lonnie" on A-FICS,E-FICS,& MMEICS
"DoctorWho" on ICC
Moritz Berger
Lonnie Cook <lonni...@riconnect.com> wrote:
> To all,
> I am curious as to everyone's opinion on whether you'd like to see these
two programs ported
> to the windows environment. I would like to see them ported because I
mostly work
> through windows. They would not lose any strength as indicated by Mr.
Lang porting his
> cg program to win. I'm sure to that many features could be incorporated
that are
> indicative of the windows environment as well.
Count me in!
Moritz
Komputer Korner
Lonnie Cook wrote:
>
> To all,
> I am curious as to everyone's opinion on whether you'd like to see these two programs ported
> to the windows environment. I would like to see them ported because I mostly work
> through windows. They would not lose any strength as indicated by Mr. Lang porting his
> cg program to win. I'm sure to that many features could be incorporated that are
> indicative of the windows environment as well.
Assuming that one disables the Windows swap file, there should only
be a 3% difference in performance. The question then becomes are the
trafeoffs worth this 3%? Moving windows around on the screen is nice.
Having icons is nice if you want instant menus. Integrating with
the internet is nice. Other multitasking and/or multithreading things
like searching a Db and analyzing at the same time would be nice.
I am sure that as soon as Windows makes it easy to disable the swap
file, that we will see all the DOS chess programs migrate to Windows.
--
Komputer Korner
The komputer that couldn't kompute the square root of
36^n.
Tord Kallqvist Romstad
Lonnie Cook (lonni...@riconnect.com) wrote:
: To all,
: I am curious as to everyone's opinion on whether you'd like to see these two programs ported
: to the windows environment. I would like to see them ported because I mostly work
: through windows. They would not lose any strength as indicated by Mr. Lang porting his
: cg program to win. I'm sure to that many features could be incorporated that are
: indicative of the windows environment as well.
: Lonnie J. Cook
: <lonni...@riconnect.com>
: "Lonnie" on A-FICS,E-FICS,& MMEICS
: "DoctorWho" on ICC
Genius 5 will be sold on a CD-ROM including the DOS version as well as the
Windows version of the program. I like this idea, and hope to see dual
versions of the other top programs as well.
However, I would much rather have Linux versions of these programs (am I
the only one?). I run Linux most of the time, and don't like to reboot the
computer to play chess.
Tord
Chris Whittington
lonni...@riconnect.com (Lonnie Cook) wrote:
>
> To all,
> I am curious as to everyone's opinion on whether you'd like to see these two programs ported
> to the windows environment. I would like to see them ported because I mostly work
> through windows. They would not lose any strength as indicated by Mr. Lang porting his
> cg program to win. I'm sure to that many features could be incorporated that are
> indicative of the windows environment as well.
But what we want to know is: has Nimzo been ported to the Lonnie
environment yet ?
Chris Whittington
Bill Newton
In article <3279db27...@news.riconnect.com>, Lonnie Cook
<lonni...@riconnect.com> writes
>I am curious as to everyone's opinion on whether you'd like to see these two
>programs ported
>to the windows environment. I would like to see them ported because I mostly
>work
>through windows. They would not lose any strength as indicated by Mr. Lang
>porting his
>cg program to win. I'm sure to that many features could be incorporated that are
>indicative of the windows environment as well.
I dont think things are as clear cut as you would appear to believe on
this subject.
Maybe I'm wrong but MY understanding is that any current chess Programme
playing within the WINDOWS environment, even as a SINGLE TASK, would be
slightly weaker than it would be playing in a DOS environment.
Were any current Programme to be played within WINDOWS as a Multi
Task.......... well I believe its published rating would fall fairly
significantly.
I believe it to be a case of 'DOS RULES OK.' :-)
Regards.
--
Bill Newton
Moritz Berger
James Garner <da...@laraby.tiac.net> wrote:
> Moritz Berger (ber...@zeus.informatik.uni-bonn.de) wrote:
>
> : > Want to do that? Let's see how confident you are about the lack of
> : > difference in strength.
> : >
> : My proposal: Let's take a 512 MB RAM (let's have 256 MB hash tables)
> : Pentium PRO 200 (maybe dual processor ...) running Windows NT 4.0 and
match
> : it against a similar system running DOS. Oh, your DOS program can only
use
> : 64 MB of RAM? It doesn't utilize the 2nd processor? What a pity. I
think
> : that the wave of the future is to have chess programs playing under
Windows
> : NT, because of the playing strength!
>
> First, I will send you a calendar. You seem to think that this is
> 1998. Sorry. The current year is 1996. Most rational people prefer to
> discuss what is currently possible.
In two months we can agree that the year is 1997. Having a 512 MB RAM, 2 x
PP200 system with NT 4.0 is reality right now. There are programs that use
both processors, there are also chess programs that are multi-processor
capable (although I don't think that they have already been ported to a NT
4 PP SMP system). I think Virtual chess searches in parallel, Bob has
announced that Crafty will also be doing this in the future (maybe before
1998 ;-)). Apart from the issue of multi-threading within chess programs
(the multi processing is handled by the OS itself), NT should balance the
workload of the processors, meaning that the chess program will be able to
use one processor while the other one takes care of OS overhead, mouse and
keyboard handling and other multitasking issues.
> A clue of what is: We were talking about current Windows vs.
> current Dos. As in (hint, hint) either Win3.1 or Win95.
>
> Reality check #1: Current windows chess programs do not utilize the 2nd
> processor.
We're now just seeing the 1st wave of Windows programs. I was talking about
the future potential, you were talking about the past. I was building the
bridge to the 21st century (sounds familiar ;-) - you were looking back on
technological crap of the early 1980s which wasn't good technology even
back then.
> : Aside from playing strength, I don't see how a DOS program can give me
the
> : following "goodies" that I need:
>
> Serious chess players care about strength. Chess program groupies
> fixate on it. Weak players that would be crushed by a Radio Shack 2150
> computer don't care at all about it. You seem to be in the third group. I
> recommend any shareware windows program for you. Have fun.
>
> : 1) I want to run a program seemlessly in a Window under Windows because
> : that's where I work.
>
> "Seemlessly"? Oh, ok.
Seemingly ;-) I made a typo. I'm very sorry that I haven't been able to
enjoy the benefits of an American elementary school. Yadda Yadda Yadda - as
we say here in Germany ;-)
Why makes my interest in using a dual or quad processor PP 200 system to
enhance playing strength make you think that my interest in a Radio Shack
2150 would be very big? I indeed also use a Novag Sapphire portable device
and am quite happy with it, but I enjoy nevertheless playing against Rebel
8, Fritz 4 and the like on my PC. I like it if a program shows me
meaningful primary variants to help me finding alternative plans if I lose
a game or if it can produce a meaningful overnight analysis.
Also, I wouldn't be happy with a Radio Shack 2150 because I really want all
those features and bells and whistles I expect from Windows programs.
Shifting from antique DOS programs to prehistoric dedicated standalone
chess playing machines to convince a Windows adept seems illogical to me.
But maybe you just wanted to insult me? You might consider your attempt a
failure. We have not been discussing my chess playing strength nor your
girlfriend's pink toenails here.
>
> : 2) I want a program to be compatible with my graphics card, memory
> : management system and mouse driver without configuration troubles.
>
> Do you use all graphics cards at the same time, or just one?
> Which one? Rebel 8 seems to work quite well in DOS. Here is someone who
> has not sold out to the Windows crowd.
Oh well, it cost me just some hours of work to get it running (with the
help of Ed Schröder), because I am unfortunately using a Matrox card. I
wasn't just posing hypothetical questions, I was talking out of experience.
Once bitten, twice shy.
Oh, in fact I have been bitten twice since Rebel 8 runs under DOS 7.0 on my
machine (P5/166 PCI, 64 MB RAM) only if I bypass all memory managers and
device initializations via the F8 bootmenu, then I have to press Shift-F5
and load a German keyboard driver and mouse driver via a separarte batch
file.
Twice bitten, always shy?
Before I forget to mention it: On another of my machines (486/133 EISA, 32
MB RAM), Rebel 8 only runs with himem.sys in the config.sys but doesn't run
if I use the F8-Shift-F5 approach.
A friend of mine has to load a special VESA driver or invoke Rebel with the
V switch to be able to use it on his machine. Well, this doesn't matter to
you.
On my Toshiba Tecra 720 CDT notebook with 1024x768 internal resolution,
Rebel runs only in a small window in the middle of the 12.1" screen. This
sucks! I have now found a way to enable the video stretching for DOS
programs for the 640x480 resolution, but the magnification by a non-integer
factor doesn't make the big pixels look any better.
I consider myself a happy Rebel 8 user. But I would still like to have a 32
bit Windows version ...
>
> : 3) I want a user friendly, standardized help function via the F1 key.
>
> Run out of write memory in the old carbon-based hard drive? Can't
> remember a different key?
Most chess program don't have a help function at all.
>
> : 4) I want a Win 95/ Win NT uninstall routine.
>
> Yea. Most current windows chess programs have uninstall routines.
> Both for Windows 95 and Windows NT. Right.
>
> P.S. Notice how well Microsoft wrote Windows NT. Seems that it's
> having more trouble getting some Windows 95 and Windows 3.11 programs to
> run under it than IBM has running such programs in OS/2.
IBM running Win95 programs under OS/2? My typo vs. your grammatical
ambiguity ;-)
> : 7) I don't like that every DOS programmer reinvents his own GUI. I want
the
> : programmers to adhere to the Windows conventions, not just because it's
> : pretty or I'm lazy but because it's a good standard to begin with and I
> : don't have to re-learn the File/Open function in every program.
>
> Some do a good job of it. Have you seen Rebel?
Oh yes. The GUI explodes with tons of features, it would surely benefit
from a higher screen resolution and maybe present the user something else
than 3-letter menu abbreviations or 1-letter non-graphical buttons. The
limitations of the modal dialogs in the database part will show you what
I'm talking about:
Try to delete 3 games from a database in Rebel 8:
1. Select DAT/Delete game (maybe you will have to leave the database view
if you haven't just started Rebel for the sole purpose of deleting some
games).
2. Scroll database list
3. Select game
4. confirm delete
(Rebel will leave the database view so that you can again select
DAT/Delete game)
5. Repeat this 3 times (= 12 steps)
The Windows way:
If you're working in a database view,
1. Ctrl+Click on 3 Games
2. press Delete
3. Confirm delete (= 3 steps)
(The methodology and key combinations are standard in _all_ Windows
programs, nothing special about it).
This whole discussion will soon be over, because AFAIK Genius 5 will come
both as a DOS and Windows version on the same CD. You can measure your
speed difference (maybe 1-2% if you have enough memory to use big hash
tables also under Windows), I can show you what I'm talking about GUI-wise.
If you have 8 MB or 16 MB RAM - stay with DOS and be happy. If you have 32
MB or 64 MB RAM or more - go Windows, you won't regret it. The current RAM
prices for 32 MB EDO SIMMS, 60ns are about 200-250$$ right now. Chess
programs cost about 150$$. I think that the extra RAM is worth the money
(not only for chess programs ;-)).
BTW: The whole Windows debate could also be extended to Unix (e.g. Linux).
This is also a multitasking environment which will eat resources for this
purpose. As will OS/2 or any other non-primitive, non-CLI based, non 640 KB
limited, non single task OS that not only gives you basic disk access and
keyboard processing functionality (not even talking about the A20 gate
..).
Last question: Why did you snip my other arguments? You didn't even
indicate that you removed them from your post. Maybe you could use the
<snip> comment next time ... Or will this only be possible in 1998, but not
in 1996? ;-) Sorry, couldn't resist ...
--
-------------
Moritz Berger
ber...@zeus.informatik.uni-bonn.de
Lonnie Cook
On Sat, 02 Nov 1996 17:55:36 GMT, Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
>But what we want to know is: has Nimzo been ported to the Lonnie
>environment yet ?
>
>Chris Whittington
>
Good one Chris :?), I got a good laugh out of that one. Unfortunately Nimzo3 hasn't been
ported to the Lonnie environment yet. Maybe when the environment is more stable then
it'll be a smoother transition (sigh)
Komputer Korner
James Garner wrote:
>
> Komputer Korner (kor...@netcom.ca) wrote:
>
> : 2 or 3% at the most. Is this a big deal? The Swedish testers have
> : tested the difference. Others like Hyatt and Lang say 0%. The Windows
> : GUI overhead to refresh the screen can't be much more than the DOS
> : refresh. Internal calculations are not affected. Bill, give this
> : subject a rest.
>
> Dear "Komputer"
>
> Did you actually read Hyatt's posts? He has admitted several times
> that at least the hash tables would be much smaller under Windows than the
> maximum one could have under DOS.
>
> Is it the official position of Komputer Korner that hash tables
> are unimportant? Then tell you what. I'll run the same copy of a program
> under DOS, and you run it under Windows (any windows, pick your view) and
> each machine will be exactly the same, with 64 meg RAM, same speed, etc,
> and I'll lay down $1000 on the machine running DOS.
>
> Want to do that? Let's see how confident you are about the lack of
> difference in strength.
The problem with the limited hash tables in Windows is due to the
automation of the swap file to disk. As soon as Windows detects
a program's need for data files greater than 4Mb in RAM, it initiates
a swap file of that data to the hard disk. If you turn off automated
swapping, then it will not do this, but you had better have enough
RAM or your program will not function. So the bottom line is that
for chess programs, there really is no need to stay in DOS. Read the
following about what Moritz Berger said about Fritz 4's solution to this.
"The most important issue if you use Fritz 4.01 is the size of the hash
tables.
In order to maximize the available RAM for hash tables you should restart
Windows before loading Fritz 4.01 and terminate all other programs if
possible.
The following settings (in the LEVELS/Engines/Load Engine dialog) have
worked for me:
32 MB RAM - 16 MB hash
48 MB RAM - 32 MB hash
etc.
Now the problem: If you choose e.g. 32 MB hash and have 48 MB RAM, you
will notice that Windows 95 starts to swap to the hard disk. This might
take a while. The important thing is that Windows just clears enough RAM
for the hash tables but stops swapping after that.
I recommend the following procedure:
1. Set hash table size
2. Choose the WATCH button
3. Wait until swapping ends
4. Click on the PLAY button
5. Wait until swapping ends.
You will now be able to play without any swapping activities at all (if
you didn't choose your hash table size too big)."
Bernhard Sadlowski
In article <55fbbj$3...@beyla.ifi.uio.no>,
Tord Kallqvist Romstad <tor...@ifi.uio.no> wrote:
>Genius 5 will be sold on a CD-ROM including the DOS version as well as the
>Windows version of the program. I like this idea, and hope to see dual
>versions of the other top programs as well.
>
>However, I would much rather have Linux versions of these programs (am I
>the only one?). I run Linux most of the time, and don't like to reboot the
>computer to play chess.
The DOS versions of Genius and Fritz run just fine in the Linux Dosemulator.
Last time I checked Rebel Decade and Rebel 6 Demo refused to run ("DPMI
operating system error"), so I suspect that Rebel 8 can't do this as well.
Of course I would like to see native Linux versions of such programs like
Rebel, Genius etc. as well. Crafty with XBoard/XBkit-patch is currently the
only Linux solution, which also allows you a (somewhat) restricted and slow
analysis of games in a graphical environment.
Bernhard
--
Bernhard Sadlowski
<sadl...@mathematik.uni-bielefeld.de>
Pitters
Im Artikel <327CA5...@mcs.com>, James Reames <ches...@mcs.com>
schreibt:
>>Genius 5 will be sold on a CD-ROM including the DOS version as well as
the
>>Windows version of the program. I like this idea, and hope to see dual
>>versions of the other top programs as well.
>
>Do you know what type of copy protection Genius 5 will have??
It `s on a CD - ROM including two DOS - Versions, one Genius 5 + Genius 3.
A few days ago, I received The Beta.
Copy protection : It`s a refill - procedure ;-) The programm is asking
for the CD - ROM from time to time !
Have fun
-Peter
Tord Kallqvist Romstad
Bernhard Sadlowski (sadl...@mathematik.uni-bielefeld.de) wrote:
: In article <55fbbj$3...@beyla.ifi.uio.no>,: >Genius 5 will be sold on a CD-ROM including the DOS version as well as the
: >Windows version of the program. I like this idea, and hope to see dual
: >versions of the other top programs as well.
: >However, I would much rather have Linux versions of these programs (am I
: >the only one?). I run Linux most of the time, and don't like to reboot the
: >computer to play chess.
: The DOS versions of Genius and Fritz run just fine in the Linux Dosemulator.
When I try to run Genius in Dosemu, I get an "unauthorized copy" error.
The same thing happend with the old copy-protected version of Fritz 3. I
recently got the new non-copy-protected Fritz 3, which works, but only with
small hash tables.
How do you run copy-protected programs in Dosemu? Do these programs work
with big hash tables?
: Last time I checked Rebel Decade and Rebel 6 Demo refused to run ("DPMI
: operating system error"), so I suspect that Rebel 8 can't do this as well.
I get this error message, too.
: Of course I would like to see native Linux versions of such programs like
: Rebel, Genius etc. as well. Crafty with XBoard/XBkit-patch is currently the
: only Linux solution, which also allows you a (somewhat) restricted and slow
: analysis of games in a graphical environment.
Of some reason, Crafty is very weak on my computer. I guess my 486/66
is simply too slow.
Tord
: Bernhard
: --
: Bernhard Sadlowski
: <sadl...@mathematik.uni-bielefeld.de>
Peter L. McKone
In article <3279db27...@news.riconnect.com>, lonni...@riconnect.com (Lonnie Cook) writes:
|> To all,
|> I am curious as to everyone's opinion on whether you'd like to see these two programs ported
|> to the windows environment. I would like to see them ported because I mostly work
|> through windows. They would not lose any strength as indicated by Mr. Lang porting his
|> cg program to win. I'm sure to that many features could be incorporated that are
|> indicative of the windows environment as well.
|> <lonni...@riconnect.com>
|> "Lonnie" on A-FICS,E-FICS,& MMEICS
|> "DoctorWho" on ICC
I've been a computer programmer for more than twenty years, and I work on
on the operating system for a fairly large commercial vendor.
There is a LARGE amount learning that one must do before he can port even
a simple program to run in the Microsoft Windows environment. Unix X-windows
isn't any easier. Windows programming has as much similarity to regular
programming as water skiing does to snow skiing. I prefer Windows programs too,
but it's hard to blame Ed Schroeder or Marty Hirsch for being reluctant to
switch to what is virtually a different profession.
Peter McKone
john quill taylor
lonni...@riconnect.com (Lonnie Cook) wrote:
>To all,
>I am curious as to everyone's opinion on whether you'd like to
>see [chess] programs ported to the windows environment.
>...
I'd much rather see chess programs "ported" to an http-like protocol,
one that is machine AND operating system independent. Imagine if you
will several chess engines running on super computers and the ability
to access their power with the ease at which you can currently get a
stock quote.
__
john quill taylor / /\
writer at large / / \
Hewlett-Packard, Storage Systems Division __ /_/ /\ \
Boise, Idaho U.S.A. /_/\ __\ \ \_\ \
e-mail: jqta...@hpdmd48.boi.hp.com \ \ \/ /\\ \ \/ /
Telephone: (208) 396-2328 (MST = GMT - 7) \ \ \/ \\ \ /
Snail Mail: Hewlett-Packard \ \ /\ \\ \ \
11413 Chinden Blvd \ \ \ \ \\ \ \
Boise, Idaho 83714 \ \ \_\/ \ \ \
Mailstop 852 \ \ \ \_\/
\_\/
"When in doubt, do as doubters do." - jqt -
haiti, rwanda, cuba, bosnia, ... we have a list,
where is our schindler?
Tim Mirabile
jqta...@hpdmd48.boi.hp.com (john quill taylor) wrote:
>lonni...@riconnect.com (Lonnie Cook) wrote:
>
>>To all,
>>I am curious as to everyone's opinion on whether you'd like to
>>see [chess] programs ported to the windows environment.
>>...
>
>I'd much rather see chess programs "ported" to an http-like protocol,
>one that is machine AND operating system independent. Imagine if you
>will several chess engines running on super computers and the ability
>to access their power with the ease at which you can currently get a
>stock quote.
How about making chess programs follow the FICS/ICC protocol. This way, you use
your favorite interface to play against it, or the program could play on the
servers directly. This would also give an easy way to autoplay programs
regardless of what operating system they are on.
+----------------------------------------------------------------------+
| Tim Mirabile <t...@mail.htp.com> http://www.webcom.com/timm/ |
| TimM on FICS - telnet://fics.onenet.net:5000/ PGP Key ID: B7CE30D1 |
+----------------------------------------------------------------------+
Patrick McDonald
Lonnie Cook wrote:
> I am curious as to everyone's opinion on whether you'd like to see these two programs ported
> to the windows environment.
I'd certainly prefer REBEL v8 to be a WINDOWS program. I found GENIUS v4
an improvement over the v3 for this reason alone.
--
--=======| Patrick McDonald | Internet:
pat...@mpx.com.au |=======--
--=======| PO Box 357 | Fidonet:
3:713/605 |=======--
--=======| Round Corner, NSW 2158 | Fax:
+61-2-9651-3778 |=======--
--=======| AUSTRALIA | `I rejoice that there are
owls.' |=======--
brucemo
Moritz Berger wrote:
>
> James Garner <da...@laraby.tiac.net> wrote:
> > Komputer Korner (kor...@netcom.ca) wrote:
> >
> > : 2 or 3% at the most. Is this a big deal? The Swedish testers have
> > : tested the difference. Others like Hyatt and Lang say 0%. The Windows
> > : GUI overhead to refresh the screen can't be much more than the DOS
> > : refresh. Internal calculations are not affected. Bill, give this
> > : subject a rest.
> >
> > Dear "Komputer"
> >
> > Did you actually read Hyatt's posts? He has admitted several times
> > that at least the hash tables would be much smaller under Windows than
> the
> > maximum one could have under DOS.
> >
> > Is it the official position of Komputer Korner that hash tables
> > are unimportant? Then tell you what. I'll run the same copy of a program
> > under DOS, and you run it under Windows (any windows, pick your view) and
> > each machine will be exactly the same, with 64 meg RAM, same speed, etc,
> > and I'll lay down $1000 on the machine running DOS.
> >
> > Want to do that? Let's see how confident you are about the lack of
> > difference in strength.
> >
> Pentium PRO 200 (maybe dual processor ...) running Windows NT 4.0 and match
> it against a similar system running DOS. Oh, your DOS program can only use
> 64 MB of RAM? It doesn't utilize the 2nd processor? What a pity. I think
> that the wave of the future is to have chess programs playing under Windows
> NT, because of the playing strength!
>
> following "goodies" that I need:
>
> that's where I work.
>
> management system and mouse driver without configuration troubles.
>
>
>
> comments in the best quality I can get on every printer I own. Even on
> network printers, fax modems etc.
>
> 6) I want to have multiple windows with multiple games open at the same
> time.
>
> 7) I don't like that every DOS programmer reinvents his own GUI. I want the
> programmers to adhere to the Windows conventions, not just because it's
> pretty or I'm lazy but because it's a good standard to begin with and I
> don't have to re-learn the File/Open function in every program.
>
> 80 Hz) and don't want to use DOS programs in a 640x480 res. on my 21"
> monitor where every pixels looks like the protagonist in a game of Boulder
> Dash. Not everybody can afford a TASC chessboard for non-business reasons,
> so I want at least the very best on screen display that I can get. Fritz 4
> comes pretty close in this respect, only that the 2D board size cannot be
> further enlarged if you run more than 1024x768 res.
>
> 9) I want to have as much information on my screen at a time as I desire. I
> need a high display res. for this purpose.
>
> 10) One very simple thing: The BEEP signal of DOS programs is sometimes not
> loud enough. I want the program to use my soundcard, maybe even allowing me
> to customize the BEEP. Simple, but annoying if you wait for the computer to
> move and don't want to keep your eyes permanently on the screen.
>
> 11) I want to multitask e.g. my chess database program and my chess playing
> program. I don't want one of them to disappear when I Alt+Tab to the other,
> maybe I let the chess engine analyze an unclear position and browse my
> database for similar positions. Or I want to download a huge file from the
> internet via modem dialup while I get notified about incoming mail and
> still be able to play a decent game of chess ...
>
> I know that my reasons might be not as important to others. To me, they are
> important and the next chess playing program I buy will be Chess Genius 5
> for Windows.
I included all of Berger's post because it is so good.
Chess programs are funny because you can derive a function that relates strength to
processor speed and memory.
More speed will make a program objectively stronger, although if the speed increase is
very slight, the odds that the strength increase will affect the outcome of any single
game are very slight.
The effect of memory is a little less clear. A given chess program will use a certain
amount of memory for its executable, and for its data overhead, and will grab a lot of
the remaining memory for hash tables. It's been my experience that hash tables are
allocated in fixed units, you can allocate X megabytes for a table, or 2X megabytes, or
4X megabytes, but probably not 3.21X megabytes. What this means is that if you have
3.05X megabytes of free memory, as opposed to 3.78X megabytes of free memory, the
decrease in memory available won't cost you any strength. As an example, my machine has
128 megabytes of RAM, and in my program my hash table options are 49 megabytes, 98
megabytes, or 196 megabytes, and since I want to run some extra crud in the background I
choose 49 megabytes, since if I chose 98 megabytes I'm worried that the machine might
thrash, so basically there's like 50 or so megabytes of RAM on my machine that isn't
used.
In general though, you can say that more speed and more memory is a good thing if you are
maximizing for strength.
What I like about Berger's post is that he isn't a strength-mad lunatic, like most of the
other posters I have seen. The obsession with getting every last ELO point out of a
hardware configuration is possibly a little unhealthy. To think that Windows is such a
great handicap against a program that you'd happily bet $1000 on it is truly nutty,
unless you are the type who habitually bets sums like this on the flip of a coin.
As much as I would like to be able to (I'm a Microsoft shareholder and ex-employee), I
will not argue here that Windows '95 and Windows NT have no effect upon the speed of the
underlying computer system, and I will not argue that they have less memory footprint
than DOS. There are some cases where DOS might be faster. There are some cases where
Linux might be faster. It might even be true that in some cases Windows '95 and Windows
NT are faster, but I haven't researched it. The only configuration that I have
personally chosen to avoid is the combination of 32-bit code and Windows '95 on a P6, I'd
much rather run Windows NT under these circumstances.
But none of this is a huge big deal, in my opinion. The reasons Berger gives for using
Windows are quite satisfactory, basically he says that he wants to use a more modern
operating system than DOS, because the fractional ELO points he gives up by doing this
are more than offset by the extra FEATURES he gets from his chess program. He gets all
of the underlying services a more modern operating system has to offer, and he gives up
basically nothing.
This is the sane side of this argument.
I think that for the average person, it makes much more sense to pick the chess software
that you enjoy using most -- the one that has the best features, the one that runs on the
operating system you like (choose DOS if you want to), the one that is easiest to use,
the one that is most reliable, etc. Obsession with a few (possibly ficticious) ELO
points of engine strength does you no good.
bruce
Komputer Korner
James Garner wrote:
>
> brucemo (bru...@nwlink.com) wrote:
> : > > Is it the official position of Komputer Korner that hash tables
> : > > are unimportant? Then tell you what. I'll run the same copy of a program
> : > > under DOS, and you run it under Windows (any windows, pick your view) and
> : > > each machine will be exactly the same, with 64 meg RAM, same speed, etc,
> : > > and I'll lay down $1000 on the machine running DOS.
>
> : point out of a hardware configuration is possibly a little unhealthy. To
> : think that Windows is such a great handicap against a program that you'd
> : happily bet $1000 on it is truly nutty, unless you are the type who
> : habitually bets sums like this on the flip of a coin.
>
> if I can get even odds. And I don't think it's just a point or two.
For all the DOS defenders out there including James Garner, Ed Schroder,
and Marty Hirsch, are you willing to give up the advantages of Windows
for a measly 3% in performance? The hash table argument is a non starter
if you disable swapping. Okay the memory footprint of windows is slightly
larger than DOS, 3K , but this pales in comparison to the fixed block of
HASH table RAM problem that Bruce was talking about. In other words, on
machines that have lots of RAM and that is sure the tendency these days,
there is no reason why you can't allocate the same size of hash tables
under Windows as you can with DOS. And what about systems with more than
64Mb of RAM? No DOS program I know can access more than that. Come to
think of it I don't know why. Would someone explain this and does
anybody know the limit in WIN 95 for RAM?
I have discussed this with Bob Hyatt and the only reason that he can
come up with why all the chess programmers don't switch to Windows is
that it is a lot of work learning to program in Windows.
--
Komputer Korner
The komputer that couldn't keep a password safe from prying eyes and
Komputer Korner
Komputer Korner wrote:
snipped>
I found the answer to maximum memory size in WIN 95 for the system
resource heaps to be 2Gb. Does this have any relation to the
maximum allowable RAM and if not what is the maximum allowable RAM
in WIN 95? I know that since it is a 32 bit OS, theoretical maximum
would be 4Gb, but probably at least 1Gb is reserved.
James Reames
brucemo wrote:
>More speed will make a program objectively stronger, although if the speed increase is
>very slight, the odds that the strength increase will affect the outcome of any single
>game are very slight.
>my machine has 128 megabytes of RAM, and in my program my hash table options are 49 >megabytes, 98 megabytes, or 196 megabytes, and since I want to run some extra crud in >the background I choose 49 megabytes, since if I chose 98 megabytes I'm worried that >the machine might thrash, so basically there's like 50 or so megabytes of RAM on my >machine that isn't used.
I am a chess player not a chess programmer, that said... I thought the
idea behind hash tables was so that a chess program could record
positions that have already been looked at, then if the chess program
needs to look at that position again, it can simply look it up in the
hash table. The advantage of a hash table is that the chess program can
look up a position in a hash table faster than it would take to search
through that position from scratch.
Now my question: If you make a hash table too large, won't it take
longer to look up a position in the hash table than it would take to
search that position from scratch??
Second question: If it is true that at some point a hash table can
become too large to be useful, at what point is that? 16mb, 32mb?
128mb??
Regards,
James Reames
ches...@mcs.com
http://www.mcs.net/~chessman
James Reames
brucemo wrote:
>More speed will make a program objectively stronger, although if the speed increase is
>very slight, the odds that the strength increase will affect the outcome of any single
>game are very slight.
>my machine has 128 megabytes of RAM, and in my program my hash table options are 49 >megabytes, 98 megabytes, or 196 megabytes, and since I want to run some extra crud in >the background I choose 49 megabytes, since if I chose 98 megabytes I'm worried that >the machine might thrash, so basically there's like 50 or so megabytes of RAM on my >machine that isn't used.
I am a chess player not a chess programmer, that said... I thought the
Tord Kallqvist Romstad
James Reames (ches...@mcs.com) wrote:
: brucemo wrote:
:
: >More speed will make a program objectively stronger, although if the speed increase is
: >very slight, the odds that the strength increase will affect the outcome of any single
: >game are very slight.
: >my machine has 128 megabytes of RAM, and in my program my hash table options are 49 >megabytes, 98 megabytes, or 196 megabytes, and since I want to run some extra crud in >the background I choose 49 megabytes, since if I chose 98 megabytes I'm worried that >the machine might thrash, so basically there's like 50 or so megabytes of RAM on my >machine that isn't used.
: I am a chess player not a chess programmer, that said... I thought the
: idea behind hash tables was so that a chess program could record
: positions that have already been looked at, then if the chess program
: needs to look at that position again, it can simply look it up in the
: hash table. The advantage of a hash table is that the chess program can
: look up a position in a hash table faster than it would take to search
: through that position from scratch.
: Now my question: If you make a hash table too large, won't it take
: longer to look up a position in the hash table than it would take to
: search that position from scratch??
No. The time used to look up the position does not depend on the size of
the table. You don't need to search all entries in the transposition
table for the current board position, you know exactly where to find it
in the table. I guess you are not interested in the technical details about
how this is done.
However, some programs (Rebel, M-Chess, Fritz and probably some others)
clear their hash tables before starting their calculations. This may take
some time (usually less than a second), so it might be wise to use a
smaller hash table when playing blitz.
: Second question: If it is true that at some point a hash table can
: become too large to be useful, at what point is that? 16mb, 32mb?
: 128mb??
It depends on the speed of your program. Fast programs need bigger hash
tables than slow ones. The maximum useful size is the number of positions
searched during the allowed thinking time. Of course, big hash tables
are less important in blitz play than at the tournament level.
Tord
: Regards,
Tord Kallqvist Romstad
James Garner (da...@laraby.tiac.net) wrote:
: It would be nice to get a table, showing the useful hash table
: size vs. the two variables of 1) Speed of CPU and 2) Average time per
: move allocated.
You also need to know how many POPS (positions per second --- someone
suggested this acronym on this ng about a year (?) ago. I like it
better than the usual "nps" (nodes per second). POPS is easier to
pronounce, and the acronym makes sense in many languages other than
English. Also, terms like "kilopops", "megapops", "gigapops" sound
(IMHO) much better than "kilonps" etc.) the program searches. The
maximum useful hash table size (MUHTS) is the maximum number of positions
the program will search when deciding on a move. An example:
Rebel 8, on my computer (a 486/66) searches about 8 kp (kilopops). At
tournament level, the program will probably rarely think for more than
10 minutes on a single move. This means that it searches about 4.8
million positions. I am not sure how many bytes Rebel use to store one
position, but I guess it is around 12 bytes. Therefore, the MUHTS for
Rebel 8 at the tournament level is about 12 x 4.8 = 57.6 MB, which is
close to the maximum possible size of the hash table.
For other programs (and other processors) the numbers will of course
be different. Fritz will certainly need a much bigger hash table than
Chess System Tal, when running on the same computer.
Tord
brucemo
James Reames wrote:
> I am a chess player not a chess programmer, that said... I thought the
> idea behind hash tables was so that a chess program could record
> positions that have already been looked at, then if the chess program
> needs to look at that position again, it can simply look it up in the
> hash table. The advantage of a hash table is that the chess program can
> look up a position in a hash table faster than it would take to search
> through that position from scratch.
>
> Now my question: If you make a hash table too large, won't it take
> longer to look up a position in the hash table than it would take to
> search that position from scratch??
>
> Second question: If it is true that at some point a hash table can
> become too large to be useful, at what point is that? 16mb, 32mb?
> 128mb??
The typical chess program approaches a given position using a process similar
to peeling an onion. It starts out searching to a shallow depth, then it
searches the whole thing again, a little deeper, then again, a little deeper,
etc. This process is called "iterative deepening".
During this process, if the program finds the same position that it found
before, chances are that it is supposed to search a ply deeper in this
position this time. It may have a hash entry from the previous iteration,
but the data in that entry are based upon a shallower search. So the program
can't just say, hey, I've searched this before, bag it.
But it can still do something with the hash entry that is extremely useful.
There's an element in the hash entry that represents the best move found from
this position. A program can speed itself up by searching this move first
during this iteration. There is a pretty good chance that this move may be
the best move available in this deeper iteration, too.
It is a characteristic of the alpha-beta algorithm that if you search the
best move first, you end up doing less work to get to where you are trying to
go, often dramatically less work. So you go faster, because of the improved
candidate move ordering.
During the middlegame phase, you don't find a huge number of hash entries
that allow you to completely avoid searching a position, but you do find a
lot of cases where you have the "best move" stored, and can use this to make
your search more efficient, so this is the most important feature of the hash
table during this phase.
As the game moves into the ending, there is more chance that the program will
be able to avoid searching positions, and in some endings this feature of the
hash table becomes crucial.
To address your first question, a hash table is an array of hash entries.
The size of the array determines the size of the hash table. The array is
indexed by a hash key, and the time it takes to access the array is not
dependent upon the size of the array.
To address your second question, the useful size of a hash table is at least
a little bit implementation dependent. Some programs clear out their tables
before each search, and since the array is large, it may take a little while
to do this. If you make the array huge, and are playing at very fast time
controls, you may spend most of your time doing this, and play weaker chess
as a result. If the program doesn't clear its tables before searching, it
won't have this problem.
I haven't done any research trying to figure out the maximum useful size of a
table, since my program doesn't clear its tables I can foresee no reason to
try to make the table some "optimum" size, for my program I think that bigger
is better, or is at least not any worse than smaller.
A question to anyone who might know better than I: If you search 50K nps
that's nine million nodes in a three minute search, which depending upon the
size of your hash key is like 60-150 megabytes of entries potentially.
Doesn't this imply that there is at least some benefit to be gained from a
hash table that exceeds this size to a modest degree?
bruce
Joe Stella
>James Reames (ches...@mcs.com) wrote:
>: Now my question: If you make a hash table too large, won't it take
>: longer to look up a position in the hash table than it would take to
>: search that position from scratch??
>: [snip]
No, the time to look up a position in the hash table does not depend
at all on the hash table size. To look up a position, you just
take the current hash code (which is incrementally created when
making a move), mask/shift it to get the right amount of bits,
then do an index into a table. The table indexing just compiles
into a simple addition in assembler code; when you make the hash
table larger, the only thing that changes is the size of the number
being added.
Joe Stella
Robert Hyatt
: >very slight, the odds that the strength increase will affect the outcome of any single
: >game are very slight.
: >my machine has 128 megabytes of RAM, and in my program my hash table options are 49 >megabytes, 98 megabytes, or 196 megabytes, and since I want to run some extra crud in >the background I choose 49 megabytes, since if I chose 98 megabytes I'm worried that >the machine might thrash, so basically there's like 50 or so megabytes of RAM on my >machine that isn't used.
:
: I am a chess player not a chess programmer, that said... I thought the
: idea behind hash tables was so that a chess program could record
: positions that have already been looked at, then if the chess program
: needs to look at that position again, it can simply look it up in the
: hash table. The advantage of a hash table is that the chess program can
: through that position from scratch.
:
: longer to look up a position in the hash table than it would take to
: search that position from scratch??
No. You use the low order N bits of the hash signature word to go
*directly* to a specific entry (or group of entries if you use the
"bucket" approach...). The size of the table therefore has nothing
to do with efficiency, because there is no sequential or indexed
search through the table. It's either at the first place you look or
it isn't... "instant" access or a search..
:
: Second question: If it is true that at some point a hash table can
: become too large to be useful, at what point is that? 16mb, 32mb?
: 128mb??
When it's capacity is such that you can store every position you search
in the table without replacing any. Increasing the table beyond this
point doesn't let you store more positions since you can't search fast
enough to reach them, hence it's no faster. Since there's no overhead
for accessing a larger table over a smaller one, there's no loss either.
This is why I suggest simply starting at N and running a set of problems
at the time limit you expect to use, then increase N and run them again.
Keep doing this until the time gets no faster. There you can stop as
more table space only uses memory and runs the risk of causing paging or
swapping, both of which are *bad news.*
On my P6, with 64 megs, I normally run with hash=24 (next step in Crafty
is hash=48) and hashp=4m. This leaves plenty of memory for me to do the
compiles and other stuff I use this machine for, without exciting the
paging software. In serious games (Next weekend for example) I'll use
hash=48M ahd hashp=8M with nothing else running. In Jakarta, on a 128M
machine, I used hash=96M and hashp=16M for example...
:
:
Robert Hyatt
brucemo (bru...@nwlink.com) wrote:
: James Reames wrote:
:
: > I am a chess player not a chess programmer, that said... I thought the
: > idea behind hash tables was so that a chess program could record
: > positions that have already been looked at, then if the chess program
: > needs to look at that position again, it can simply look it up in the
: > hash table. The advantage of a hash table is that the chess program can
: > look up a position in a hash table faster than it would take to search
: > through that position from scratch.
: >
: > Now my question: If you make a hash table too large, won't it take
: > longer to look up a position in the hash table than it would take to
: > search that position from scratch??
: > Second question: If it is true that at some point a hash table can
: > become too large to be useful, at what point is that? 16mb, 32mb?
: > 128mb??
: The typical chess program approaches a given position using a process similar
: before each search, and since the array is large, it may take a little while
: to do this. If you make the array huge, and are playing at very fast time
: controls, you may spend most of your time doing this, and play weaker chess
: as a result. If the program doesn't clear its tables before searching, it
: won't have this problem.
:
: I haven't done any research trying to figure out the maximum useful size of a
: table, since my program doesn't clear its tables I can foresee no reason to
: try to make the table some "optimum" size, for my program I think that bigger
: is better, or is at least not any worse than smaller.
:
: A question to anyone who might know better than I: If you search 50K nps
: that's nine million nodes in a three minute search, which depending upon the
: size of your hash key is like 60-150 megabytes of entries potentially.
: Doesn't this imply that there is at least some benefit to be gained from a
: hash table that exceeds this size to a modest degree?
:
: bruce
I think exceeding the "optimal size" is more than a little useful, because
there's absolutely no guarantee that your hash signatures are uniformly
distributed, so your hash indices are not guaranteed to be uniformly
distributed either. As a result, you'll likely find parts of a "perfect"
table that are empty, and parts that are overwritten at least one time.
The larger the table, the less likely this is to happen, although obviously
you'd need 2^64 entries to guarantee no problems. maybe by 2020 we will be
able to pull this off. :)
Komputer Korner
> : and Marty Hirsch, are you willing to give up the advantages of Windows
> : for a measly 3% in performance? The hash table argument is a non starter
> : if you disable swapping.
>
> swapping is a *result* of trying to get a large hash table, but not having
> the ability to implement it, as in Windows.
>
> One may as well argue that you can get away without needed a large
> hash table if you only use a slow enough computer, since then it will
> never be able to fill a large hash table within any reasonable amount of
> time.
Mr Garner, there is a way to disable swapping in windows. In Win 95,
Right click on My Computer.
Click Properties.
Click on the Performance tab
Click Virtual Memory
Check off the box labeled " Disable virtual memory"
Make sure that you have lots of RAM to spare or WIN 95 will crash. So
don't make your size of the hash table bigger than the difference
between the total RAM and the amount needed to run Windows and your
programs when you do this.
cma...@ix.netcom.com
I have just completed a number of experiments regarding hash size, and
Bob Hyatt posted some very useful info in reply. The bigger the
better holds true accross all other variables. Calculating the size
based on the total MUHTS does not make sense, as collisions will
always occur and the table will never be filled. As any collision
degrades performance, a full table means it is way too small. There
are good algorithms controlling when to overwrite the table with new
info, but this is only needed because the table is too small.
Chris Mayer
Robert Hyatt
James Garner (da...@laraby.tiac.net) wrote:
: Robert Hyatt (hy...@crafty.cis.uab.edu) wrote:
:
: : When it's capacity is such that you can store every position you search
: : in the table without replacing any. Increasing the table beyond this
: : point doesn't let you store more positions since you can't search fast
: : enough to reach them, hence it's no faster. Since there's no overhead
: : for accessing a larger table over a smaller one, there's no loss either.
: So how does a program store the information if it can't do so in
: hash, because hash is not big enough or not there? I don't imagine it
: writes all this to the hard drive.
It uses some sort of replacement policy to either store the current position
on top of what is already in the table, or else discard the current position
because what's in the table is apparently more valuable/useful...
pit...@aol.com
Im Artikel <32862C...@netcom.ca>, Komputer Korner <kor...@netcom.ca>
schreibt:
>Mr Garner, there is a way to disable swapping in windows. In Win 95,
>Right click on My Computer.
>Click Properties.
>Click on the Performance tab
>Click Virtual Memory
>Check off the box labeled " Disable virtual memory"
>Make sure that you have lots of RAM to spare or WIN 95 will crash. So
>don't make your size of the hash table bigger than the difference
>between the total RAM and the amount needed to run Windows and your
>programs when you do this.
One additional point :
what`s about the difference between the X-Mode ( Genius 3, Fritz3 or
MChess ) without HIMEM.SYS for great and fast Hashtables ?
Windows didn`t work WITHOUT Himem ! So in fact using chess programs under
Windows : the Hashtables were smaller and with Himem.Sys not so fast !!!!
You can test the difference with MChess Pro, which works with Himem and
the X-Mode ! X-Mode is faster and under Windows not possible !!
Be well
-Peter
Vincent Diepeveen
In <5669st$b...@sjx-ixn2.ix.netcom.com> cma...@ix.netcom.com writes:
Not true: even if hashtable is huge you need an overwrite controlling.
You save the same position with the same side to move of course
to the same tuple. So you don't want to overwrite a position with
depth n = 10 by the same position depth n = 0.
Vincent Diepeveen
vdie...@cs.ruu.nl
--
+--------------------------------------+
|| email : vdie...@cs.ruu.nl ||
|| Vincent Diepeveen ||
+======================================+
Vincent Diepeveen
The number of POPS is not only necessary, in everything i say
i NOT ONLY include transpositiontables, but all kind of tables:
mover ordering tables, evaluationtables etc.
Also: a bigger hashtable for CST could, although CST searches slower than
fritz give much better results than a bigger hashtable for Fritz.
How much bits you guess a 'slow' program like CST uses, and how much
cycles you guess Fritz does waste on storing bits? I guess that Fritz
uses very little bits. In fact a previous version of Diep also used too little
bits. I only used 32 + (log hashtablesize / log 2) for the transpositiontable.
This is of course not much. Definitely not enough.
I now changed it to 40 bits for storing + (log hashtablesize / log 2)
for the transtable.
Certain fast programs however wish not to store the best move
in transtable like i do. They store it in a separate table. Only using
20 bits... ...12 for the move + (log movetable / log 2) for the movetable.
They simply overwrite the best move, so they loose info when in long
thinking times they overwrite tuples with a move depth > new stored depth.
It is very fast however. I don't use this approach in my chessprogram
(but i do in my draughtsprogram), which makes a transpositiontable for
my program Diep more valuable than in other programs which don't store best
move in transtable.
On the other hand: i clean entire hashtable after a move is made, where
programs with a big move table only need to clean (if they don't want to
accept dubious results) the small transtable.
I estimate that this is different for every program.
Vincent Diepeveen
Ed Schröder
From: Komputer Korner <kor...@netcom.ca>
: For all the DOS defenders out there including James Garner, Ed Schroder,
: and Marty Hirsch, are you willing to give up the advantages of Windows
: for a measly 3% in performance? The hash table argument is a non starter
: if you disable swapping. Okay the memory footprint of windows is
slightly
: larger than DOS, 3K , but this pales in comparison to the fixed block
of
: HASH table RAM problem that Bruce was talking about. In other words, on
: machines that have lots of RAM and that is sure the tendency these days,
: there is no reason why you can't allocate the same size of hash tables
: under Windows as you can with DOS. And what about systems with more than
: 64Mb of RAM? No DOS program I know can access more than that. Come to
: think of it I don't know why. Would someone explain this and does
: anybody know the limit in WIN 95 for RAM?
We had the same discussion a few months ago.
If you have 64 MB Ram you can safely use 32 MB for hash tables on
Windows without any swap problems.
However if you just have 16 Mb, a hash table of 4-6 Mb Ram is more or
less the maximum. More than 6 Mb will result in swap file problems.
On DOS you can safely use a 13 Mb hash table without any problem.
: I have discussed this with Bob Hyatt and the only reason that he can
: come up with why all the chess programmers don't switch to Windows is
: that it is a lot of work learning to program in Windows.
And at least one year full time programming :)
- Ed Schroder -
The last defender of DOS :)
: Komputer Korner
Komputer Korner
pit...@aol.com wrote:> >programs when you do this.
>
> One additional point :
>
> what`s about the difference between the X-Mode ( Genius 3, Fritz3 or
> MChess ) without HIMEM.SYS for great and fast Hashtables ?
> Windows didn`t work WITHOUT Himem ! So in fact using chess programs under
> Windows : the Hashtables were smaller and with Himem.Sys not so fast !!!!
> You can test the difference with MChess Pro, which works with Himem and
> the X-Mode ! X-Mode is faster and under Windows not possible !!
>
> Be well
>
> -Peter
No one except the programmers has done tests on the X mode, but I
can't see any difference with WIN 95. X-Mode really is only DOS, and if you
disable swapping in Windows, there should be no other difference.
In Windows you can check the Fast ROM emulation box to allow programs
that write only text to the screen. This allows Windows to use faster
routines in RAM if the application normally uses standard ROM BIOS
calls to write text to the screen. I think that the 3-5% difference
that the Swedes found between DOS and Windows chess programs was because
they didn't check this box off or maybe they used WIN 3.1 and it was not
possible.The other difference of screen refreshing under Windows vs DOS
doesn't make any difference when we are not talking graphics. Since a chess
program is using only integer calculations in the CPU internal registers,
that is it. Both DOS and Windows have to do this. There is nothing more to
degrade a Windows program over DOS. Fast games are run in DOS because of the
graphics drivers directly accessing the video card instead of having to go
through the operating system. This consideration does not happen with chess
programs. So in the end, I can't see any advantages to DOS over Windows for
chess programs. And many posters have listed the advantages of Windows over
DOS.
Komputer Korner
Moritz Berger wrote:
>
> cma...@ix.netcom.com wrote:
>
> >I have just completed a number of experiments regarding hash size, and
> >Bob Hyatt posted some very useful info in reply. The bigger the
> >better holds true accross all other variables. Calculating the size
> >based on the total MUHTS does not make sense, as collisions will
> >always occur and the table will never be filled. As any collision
> >degrades performance, a full table means it is way too small. There
> >are good algorithms controlling when to overwrite the table with new
> >info, but this is only needed because the table is too small.
>
> Rebel shows you exactly the amount of hashtable use in the "war room"
> and "super war room" information views. This allows you also to find
> out how soon a smaller hash table is filled up (besides choosing the
> biggest hash tables, you're completely right on this).
> --
> -------------
> Moritz Berger
> ber...@zeus.informatik.uni-bonn.de
>
> This article may not be reprinted or quoted in the
> "Computer Schach und Spiele" magazine without my prior written consent.
Moritz is correct but don't look at the first 2 columns. They represent
cumulative hits for white and black. Useless info. The only column
that is useful is the 3rd one which represents the % of your hash table
that is filled.
Moritz Berger
Jochen Schoof
Ed Schröder (rebc...@xs4all.nl) wrote:
: From: Komputer Korner <kor...@netcom.ca>
:
: : I have discussed this with Bob Hyatt and the only reason that he can
: : that it is a lot of work learning to program in Windows.
:
: And at least one year full time programming :)
:
: - Ed Schroder -
:
: The last defender of DOS :)
BTW: Thanks for being that. One of the main reasons for me to purchase
Rebel8 was in fact, that it is still a DOS-program (the others were its
obvious playing strength and the customer friendly copy protection).
It is interesting to note, that SSDF lists DOS versions in higher places
than their respective Windows successors (Fritz, Genius). After all
there seems to be some truth in the rumours about loss of performance ;-)
I definetly prefer Fritz3 over Fritz4 (though I like Rebel best). Of
course their are fewer bells and whistles, but F3 does one thing better:
playing chess, and that's what counts. Finally I'd like to hear a little
more about the advantages of Windows-based programs compared to programs
with well designed interfaces like Fritz3 or the Rebel series. I don't
see any...
- Jochen, the last user of DOS..? ;-)
--
Jochen Schoof (http://www-info2.informatik.uni-wuerzburg.de/staff/joscho)
___________________________________________________________________________
\_Address __/ Informatik II, Uni Wuerzburg, Am Hubland, D-97074 Wuerzburg
\_Email ___/ mailto:sch...@informatik.uni-wuerzburg.de
Tord Kallqvist Romstad
Jochen Schoof (sch...@informatik.uni-wuerzburg.de) wrote:
: BTW: Thanks for being that. One of the main reasons for me to purchase
: Rebel8 was in fact, that it is still a DOS-program (the others were its
: obvious playing strength and the customer friendly copy protection).
: It is interesting to note, that SSDF lists DOS versions in higher places
: than their respective Windows successors (Fritz, Genius). After all
SSDF has never tested any Windows version of Genius.
I agree that the copy protection scheme in Rebel is nice.
Thanks, Ed! :-)
Tord
: there seems to be some truth in the rumours about loss of performance ;-)
Tim Mirabile
da...@laraby.tiac.net (James Garner) wrote:
>Ed Schröder (rebc...@xs4all.nl) wrote:
>
>: However if you just have 16 Mb, a hash table of 4-6 Mb Ram is more or
>: less the maximum. More than 6 Mb will result in swap file problems.
>: On DOS you can safely use a 13 Mb hash table without any problem.
>
> Following is a quote from Gateway 2000, which is finally (after a
>yuear and a half of shilling for Micro$oft, admitting the truth about
>Windows 95:
>
> "Windows 95 itself needs quite a bit of memory just to run, so if
>you have 16MB there's not a lot of available memory remaining for open
>applications...If you're running Windows 95, get at least 16MB or more."
>
> Funny how a year ago, shills for Microsoft were saying that 16MB
>was quite plenty enough for Windows 95.
On the other hand, maybe they are just trying to sell systems with more memory
now. I know several people running Windows 95 under 8MB ram with no problems.
I did it myself for a few months, and I'm famous for filling the taskbar with
apps. Of course, I'm much more happy now that I have 40MB. :)
Komputer Korner
Ed Schr=F6der wrote:
> =
> From: Komputer Korner <kor...@netcom.ca>
> =
> : For all the DOS defenders out there including James Garner, Ed Schroder=
,
> : and Marty Hirsch, are you willing to give up the advantages of Windows
> : for a measly 3% in performance? The hash table argument is a non starte=
r
> : if you disable swapping. Okay the memory footprint of windows is
> slightly
> : larger than DOS, 3K , but this pales in comparison to the fixed block
> of
> : HASH table RAM problem that Bruce was talking about. In other words, on=
> : machines that have lots of RAM and that is sure the tendency these days=
,
> : there is no reason why you can't allocate the same size of hash tables
> : under Windows as you can with DOS. And what about systems with more tha=
n
> : 64Mb of RAM? No DOS program I know can access more than that. Come to
> : think of it I don't know why. Would someone explain this and does
> : anybody know the limit in WIN 95 for RAM?
> =
> We had the same discussion a few months ago.
> =
> If you have 64 MB Ram you can safely use 32 MB for hash tables on
> Windows without any swap problems.
> =
> However if you just have 16 Mb, a hash table of 4-6 Mb Ram is more or
> less the maximum. More than 6 Mb will result in swap file problems.
> On DOS you can safely use a 13 Mb hash table without any problem.
> =
> : I have discussed this with Bob Hyatt and the only reason that he can
> : come up with why all the chess programmers don't switch to Windows is
> : that it is a lot of work learning to program in Windows.
> =
> And at least one year full time programming :)
> =
> - Ed Schroder -
> =
> The last defender of DOS :)
> =
> : Komputer Korner
Yeah but if you are careful, you can disable the swapping and obtain
more than 4Mb of hash tables. Besides, more and more people are =
getting lots of RAM these days. Sorry Ed, I just don't see the =
advantages of DOS anymore especially when you consider the potential =
of Power Chess with it's multi media coach. You have to see it to =
believe it. =
-- =
Ed Schröder
From: Komputer Korner <kor...@netcom.ca>
>For all the DOS defenders out there including James Garner, Ed Schroder,
>and Marty Hirsch, are you willing to give up the advantages of Windows
>for a measly 3% in performance?
: We had the same discussion a few months ago.
: If you have 64 MB Ram you can safely use 32 MB for hash tables on
: Windows without any swap problems.
: However if you just have 16 Mb, a hash table of 4-6 Mb Ram is more or
: less the maximum. More than 6 Mb will result in swap file problems.
: On DOS you can safely use a 13 Mb hash table without any problem.
>Yeah but if you are careful, you can disable the swapping and obtain
>more than 4Mb of hash tables. Besides, more and more people are
>getting lots of RAM these days. Sorry Ed, I just don't see the
>advantages of DOS anymore especially when you consider the potential
>of Power Chess with it's multi media coach. You have to see it to
>believe it.
If you disable the Windows swap file you rip out the heart of Windows.
And lose performance...
As I said a PC with 32 or 64 Mb fixes the hash table problem on
Windows. But on a PC with 16 Mb or less DOS is still superior
concerning playing strength.
The ELO loss depends per chess program and playing level of course.
On 40 in 2:00 I estimate the average ELO loss on 15-30 ELO points.
This depends of course per program. The *general* rule is: The more
nodes pro second, the more hash table size you need for optimal
performance.
But I also know that I am on losing ground because of todays low
RAM prices :)
So I resign...
But...
- Ed Schroder -
>Komputer Korner
Andrew Platt
Komputer Korner <kor...@netcom.ca> wrote in article
<328578...@netcom.ca>...
> Komputer Korner wrote:
> snipped>
>
> I found the answer to maximum memory size in WIN 95 for the system
> resource heaps to be 2Gb. Does this have any relation to the
> maximum allowable RAM and if not what is the maximum allowable RAM
> in WIN 95? I know that since it is a 32 bit OS, theoretical maximum
> would be 4Gb, but probably at least 1Gb is reserved.
Windows 95 reserves the 2GB - 4GB region for its own use (and for shared
memory
areas); Windows NT doesn't have this "restriction" although in practice I
can't see a
program wanting 2GB for a couple of years. Well, not until Windows 97 at
least!
Andy.
brucemo
James Garner wrote:
>
> James Reames (ches...@mcs.com) wrote:
>
> : Now my question: If you make a hash table too large, won't it take
> : longer to look up a position in the hash table than it would take to
> : search that position from scratch??
>
> it. However, from the other side of the coin, it is clear that if you
> specify a really huge hash table for Mchess Pro 6, it thinks for a second
> or two to clear it before starting the analysis, Which may be relevant for
> quick speed, but not for longer think times.
Answer: no.
bruce
Anders Thulin
In article <564udj$n...@news-central.tiac.net>,
James Garner <da...@laraby.tiac.net> wrote:
>James Reames (ches...@mcs.com) wrote:
>
>: Now my question: If you make a hash table too large, won't it take
>: longer to look up a position in the hash table than it would take to
>: search that position from scratch??
>
> I have seen this question posed before. No one has really answered
>it.
I tried to - but perhaps that posting hasn't been distributed yet.
The answer is: it depends. It depends mainly on the structure of
the hash table, how hash collisions are resolved, and how full it is
at the time of the search -- especially with regards to collisions. If
the system provides virtual memory, it will also depend on the size of
the hash table vs. the maximum working set allowed for a process.
The question suggests that it isn't really about pure hash tables --
there seem to be an assumption the hash table is used as some kind of
cache. If that is so, it could easily be that the hash table component
is unimportant, if, say, cache entries are flushed on collisions, and
so the cache table design could be more important than the hash table.
The question is too general, really. The best answer to such
questions is usually a reference to available literature. Try Knuth:
Sorting and Searching. Coplien's books are probably also useful. A
book on operating system design and virtual memory managers might also
be useful, although I can't think of any title just now.
--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
brucemo
James Garner wrote:
>
> Andrew Platt (an...@platty.demon.co.uk) wrote:
>
> : Windows 95 reserves the 2GB - 4GB region for its own use (and for shared
> : memory
> : areas); Windows NT doesn't have this "restriction" although in practice I
> : can't see a
> : program wanting 2GB for a couple of years. Well, not until Windows 97 at
> : least!
>
> the operating system? I don't think even Microsoft programs that badly
> (though after seeing Windows 95, I won't place any bets).
I have a friend who was on the Windows '95 team. He is a lead-programmer, but he
is by no means top banana in that group or even close to it. He is an extremely
good software engineer, works harder than anyone you will ever meet, and is the
only person I would give an absolutely unconditional "hire" recommendation for.
I have another friend who was on that team. This is the fellow who wrote many of
the little applications that ship with the Windows SDK, and he did these not
because anyone asked him to, but because they were needed and he wanted to write
them. If you ask this person for help, he won't just give you the minimum amount
of info necessary to get you out of his office, he will get up, lead you out of
his office and back to your office, then he will sit there with you, looking at
your problem, until it is fixed.
These are just two of the people I know who worked on that project. You won't
find better elsewhere, and you'll find lots more people like these scattered
about Microsoft.
bruce
Komputer Korner
brucemo wrote:
> snipped
Maybe the key word is scattered. The documentation especially on
dll files is certainly scattered somewhere in Bill Gates' brain,
because it isn't readily available. I spent a $50 call to Microsoft
to find that out.
--
Robert Hyatt
Komputer Korner (kor...@netcom.ca) wrote:
: pit...@aol.com wrote:> >programs when you do this.
I'd think that this has little effect, because most machines today use the
so-called "shadow ram" technique to hide the ROM and its associated slow
access time. I checked every machine I have (P5's and a P6) and they all
do it. Only problem is it can't be turned off to save RAM when you don't
use BIOS calls at all, as in Linux...
Jouni Uski
In my 486 PC MCP6 is 8 % faster in X-mode than in normal mode, but
there is probably bug, because in some endgame situations
it plays different moves than in normal mode...
So I fear to use x-mode!
Jouni Uski
Harald Faber
Hello rebchess # xs4all.nl,
I think I have an interesting aspect to tell you:
ESd> If you disable the Windows swap file you rip out the heart of Windows.
ESd> And lose performance...
Not if you have enough RAM... ;-)
ESd> As I said a PC with 32 or 64 Mb fixes the hash table problem on
ESd> Windows. But on a PC with 16 Mb or less DOS is still superior
ESd> concerning playing strength.
ESd> This depends of course per program. The *general* rule is: The more
ESd> nodes pro second, the more hash table size you need for optimal
ESd> performance.
ESd> But I also know that I am on losing ground because of todays low
ESd> RAM prices :)
Hehe, that's why I have 48MB RAM... :-)
Could you tell me if it is senseful to use 28MB HT for Rebel (on AMD486/
133MHz) instead of 13MB HT?
ESd> So I resign...
Why?
Ciao and see ya
Harald
--
Jouni Uski
This position is causing problems:
8/7p/p7/1p1k4/8/3K4/1P4PP/8 w - - id "8";
With 5 MB hash correct move b4! is found in 4 minutes, but
in x-mode it takes over 10 min even if positions/s is about
1000 faster!
Jouni Uski
Robert Hyatt
Jouni Uski (Jouni...@semitechturku.com) wrote:
: This position is causing problems:
That's perfectly normal. The size of the hash table can be critical in
some endgame positions. Due to the inherent randomness caused by using
random numbers to form a hash signature, and then using a number of bits
from the signature to produce a table probe address, changing anything
at all might cause a valuable entry to get overwritten, or not, in what
seems to be a random order.
Visualize two positions that are both encountered in this search, one is
*critical* to solving the position and is searched first, the second is not
and is searched after the first. If these two positions produce a hash
signature that are identical in the bits used to generate the probe address,
the second will overwrite the first and the solution is missed. Since you
are changing the number of bits used to access the table, each hash size
changes what gets overwritten and what doesn't. In some endgames, like the
position Fine #70, this can be critical... and perfectly normal...
Komputer Korner
Ed Schroder has said that disabling swapping in Windows isn't a good
idea, but if the user has enough RAM, over 128 Mb, then a Windows
program will be able to create larger hash tables than DOS programs.
So it looks like for now, there is a DOS advantage until the RAM
availability gets up past 128Mb on most machines. I see that
happening within 5 years, so DOS has a limited life here, unless
this X Mode somehow is faster than being in Windows. What exactly is
X-Mode anyway and can others verify if Jouni's 8% faster figure can be
repeated? Also can anybody tell me why the DOS limit is 64 Mb for hash
tables?
--
Komputer Korner
The komputer that couldn't keep a password safe from prying eyes,
couldn't kompute the square root of 36^n, and missed the real motive
of Chessbase.
Komputer Korner
Yes, That much RAM is still not large enough to handle the largest hash table
you will need, unless all you are doing is playing speed games.
--
Komputer Korner
The komputer that couldn't keep a password safe from prying eyes,
couldn't kompute the square root of 36^n, and missed the real motive
of ChessBase.
Harald Faber
Hello Komputer korner,
I think I have an interesting aspect to tell you:
KK> > Hehe, that's why I have 48MB RAM... :-)
KK> > Could you tell me if it is senseful to use 28MB HT for Rebel (on AMD486/
KK> > 133MHz) instead of 13MB HT?
KK>
KK> Yes, That much RAM is still not large enough to handle the largest hash
KK> table you will need, unless all you are doing is playing speed games.
So for 3min/move I guess it makes no sense using 28MB instead of 13MB, am
I right?
Komputer Korner
No, the larger the better.
--
Komputer Korner
The komputer that kouldn't keep a password safe from
prying eyes, kouldn't kompute the square root of 36^n,
and kouldn't find the real motive in chessbase.