engine and books on usb stick?

[bob]

You are right.
To my knowlege SATA gives up to 90 MB/sec.
But even if you get a factor of 4 for SCSI and raid0 this is still *slow* compared with memory access.
By the way, what happens if several threads try to access the same tb?
Does this leads to an even more significant slow down?
Here is a test position:

Study by Awerbach
FEN: 2k2K2/8/pp6/2p5/2P5/PP6/8/8 w - - 0 1

kind regards
Bernhard

I can get way more than a factor of 4. I can get a factor of 4 with good SCSI drives, and with raid0 a factor of 8 if you have 8 drives. I usually do a demo for students on my office box copying an 8 gb file, that takes a few seconds, as opposed to a _long_ time on my SATA2 laptop even though my laptop is a far faster machine, processor/memory wise...

The problem seems to be that it is not easy to get multiple SATA drives busy at once, where with scsi it is quite natural and easy to accomplish.

But with EGTBs we have to read in fairly large chunks before decompressing them, making the bandwidth just as important as the latency. I have a 1gb flash drive I can test with, but the last time I did, I was not impressed with its read/write speeds at all, particularly its write speed...

[krazyken]

I suppose you can take it a step farther and set up a raid0 across several flash drives.

[bob]

I suppose you can take it a step farther and set up a raid0 across several flash drives.

except that you still have whatever limit is imposed by the SATA interface. The parallel scsi interface is inherently much faster...

[ChessAddict]

So your saying that SCSI drives are faster than SATA drives? I currently have a SATA drive. How hard is it to install a SCSI drive? Thanks.

[krazyken]

I suppose you can take it a step farther and set up a raid0 across several flash drives.

except that you still have whatever limit is imposed by the SATA interface. The parallel scsi interface is inherently much faster...

Well I think this would be more based on the limit of the USB interface. But that is pretty darn slow!

a comparison of bus speeds

[krazyken]

yes high end SCSI is faster than SATA, but the costs are much greater as well.

Installing SCSI drives requires you buy a SCSI controller, then it is pretty much like installing any other kind of drive.

[BBauer]

Would you be so kind and show some output of crafty for this position?
kind regards
Bernhard

[bob]

So your saying that SCSI drives are faster than SATA drives? I currently have a SATA drive. How hard is it to install a SCSI drive? Thanks.

You need a scsi controller, and a scsi cable to connect to the drive(s). SCSI drives are "daisy-chained" meaning that if you have 4 drives, you will have a cable with 6 heads on it, one for the controller, one for each of the 4 drives, and the final head for a SCSI terminator.

[bob]

Would you be so kind and show some output of crafty for this position?
kind regards
Bernhard

30 seconds, first without egtbs, then with:

Code: Select all

               29     9.96   3.61   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    Ke6 Kc6 5. a5 bxa5 6. Ke5 Kb6 7. Kd6
                                    Kb7 8. Kxc5 Kc7 9. Kd5 Kb6 10. Kd6
                                    Kb7 11. c5 <HT>
               29->  11.09   3.61   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    Ke6 Kc6 5. a5 bxa5 6. Ke5 Kb6 7. Kd6
                                    Kb7 8. Kxc5 Kc7 9. Kd5 Kb6 10. Kd6
                                    Kb7 11. c5 <HT>
               30    15.18   3.61   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    Ke6 Kc6 5. a5 bxa5 6. Ke5 Kb6 7. Kd6
                                    Kb7 8. Kxc5 Kc7 9. Kd5 Kb6 10. Kd6
                                    Kb7 11. c5 Kc8 12. c6 Kd8 13. c7+ Kc8
                                    <HT>
               30->  17.96   3.61   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    Ke6 Kc6 5. a5 bxa5 6. Ke5 Kb6 7. Kd6
                                    Kb7 8. Kxc5 Kc7 9. Kd5 Kb6 10. Kd6
                                    Kb7 11. c5 Kc8 12. c6 Kd8 13. c7+ Kc8
                                    <HT> (s=2)
               31    24.76     -1   1. Ke8

              time=30.18  mat=0  n=75667880  fh=95%  nps=2.5M
              ext-> check=7.8M 1rep=136K mate=2K pp=0 reduce=49.1M/17.1M
              predicted=0  evals=37.8M  50move=0  EGTBprobes=0  hits=0
              SMP->  splits=5050  aborts=274  data=7/128  elap=30.18

               29->  11.64   0.47   1. Ke8 Kc7 2. a4 b5 3. Ke7 Kb6 4. Kd6
                                    b4 5. Ke7 Ka5 6. Kd8 Kb6 7. Kd7 Ka5
                                    8. Ke7 Kb6 9. Kd6 Ka5 10. Ke5 Kb6 11.
                                    Kf6 Ka5 12. Kf7 Kb6 13. Ke6 Ka5 14.
                                    Kd7 <HT> (s=2)
               30    14.97   0.51   1. Ke8 Kc7 2. a4 b5 3. Ke7 Kb6 4. Kd6
                                    b4 5. Ke7 Ka5 6. Kd8 Kb6 7. Kd7 Ka5
                                    8. Ke7 Kb6 9. Kd6 Ka5 10. Ke5 Kb6 11.
                                    Kf6 Ka5 12. Kf7 Kb6 13. Ke6 Ka5 14.
                                    Kd5 Kb6 15. a5+ Kxa5 16. Kxc5
               30    25.79     +1   1. a4!!
              time=30.40  mat=0  n=49312253  fh=93%  nps=1.6M
              ext-> check=5.4M 1rep=127K mate=1K pp=0 reduce=29.5M/8.9M
              predicted=0  evals=23.6M  50move=0  EGTBprobes=263K  hits=263K
              SMP->  splits=4550  aborts=330  data=8/128  elap=30.40

So with the tables it solves it in 25 seconds, without it takes longer although I ran both tests for just 30 seconds. NPS dropped from 2.5M to 1.6M. I ran it with two threads to make it worst-case...


I just noticed that I ran both of these with tiny hash sizes. Increasing hash to 384M adds 4 plies to the search depth in this position... noEGTB still does not solve it however... Larger hash greatly reduces the number of EGTB probes. Reduced it to 37K in fact, although the NPS didn't change very much since that is a pretty small number of probes to do spread over 30 seconds...


Does that show anything you wanted to see???

[bob]

Here is corrected results with hash=384M rather than the tiny default hash size. Odd thing is that it doesn't solve the thing this time around with tables, but that is not surprising when hashing parameters are changed... but note the NPS for this position, which I suspect you thought would go _way_ down???

Code: Select all

               33    18.27   1.59   1. Ke8 Kc7 2. Ke7 b5 3. a4 Kb6 4. Kd6
                                    b4 5. Ke5 Ka5 6. Kf4 Kb6 7. Kf3 Ka5
                                    8. Kg4 Kb6 9. Kh5 Ka5 10. Kg6 Kb6 11.
                                    Kf7 Ka5 12. Ke7 Kb6 13. Kd7 Ka5 14.
                                    Ke6 <HT>
               33->  21.66   1.59   1. Ke8 Kc7 2. Ke7 b5 3. a4 Kb6 4. Kd6
                                    b4 5. Ke5 Ka5 6. Kf4 Kb6 7. Kf3 Ka5
                                    8. Kg4 Kb6 9. Kh5 Ka5 10. Kg6 Kb6 11.
                                    Kf7 Ka5 12. Ke7 Kb6 13. Kd7 Ka5 14.
                                    Ke6 <HT> (s=2)
               34    28.07   1.59   1. Ke8 Kc7 2. Ke7 b5 3. a4 Kb6 4. Kd6
                                    b4 5. Ke5 Ka5 6. Kf4 Kb6 7. Kf3 Ka5
                                    8. Kg4 Kb6 9. Kh5 Ka5 10. Kg6 Kb6 11.
                                    Kf7 Ka5 12. Ke7 Kb6 13. Kf8 Ka5 14.
                                    Kf7 Kb6 15. Kg6 Ka5 16. Kg5 <HT>
              time=29.59  mat=0  n=54917750  fh=97%  nps=1.9M
              ext-> check=7.2M 1rep=126K mate=8K pp=0 reduce=35.0M/13.8M
              predicted=0  evals=25.0M  50move=0  EGTBprobes=41K  hits=41K


vs without tables:

               32->  21.46   3.46   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    a5 bxa5 5. Ke6 Kb6 6. Kd6 Kb7 7. Kxc5
                                    Kc7 8. Kd5 Kd7 9. c5 Kc7 10. c6 Kb8
                                    11. Kd4 Kc8 12. Kc4 Kb8 13. Kd5 Kc7
                                    14. Kc5 <HT> (s=3)
               33    27.46   3.71   1. Ke8 Kc7 2. Ke7 Kc6 3. a4 Kc7 4.
                                    a5 bxa5 5. Ke6 Kb6 6. Kd6 Kb7 7. Kxc5
                                    Kc7 8. Kd5 Kd7 9. c5 Kc7 10. c6 Kb8
                                    11. Kd4 Kc8 12. Kc4 Kb8 13. Kd5 Kc8
                                    14. Kd6 Kd8 15. c7+ Kc8 16. Kc6 a4
                                    17. bxa4 a5 (s=2)
              time=28.98  mat=0  n=68490077  fh=97%  nps=2.4M
              ext-> check=7.6M 1rep=79K mate=1K pp=0 reduce=45.3M/19.9M
              predicted=0  evals=30.4M  50move=0  EGTBprobes=0  hits=0
              SMP->  splits=6034  aborts=144  data=8/128  elap=28.98


So 1.9M vs 2.4M, but with tables one ply deeper with a score that is closer to the truth than the version without tables...

Note that larger hash is important as it reduces repeated egtb probes, since probe results are hashed with infinite draft so that the probes are not done a second time for the same position, the hash table has the score much faster...