Author: Robert Hyatt
Date: 17:19:10 09/03/02
Go up one level in this thread
On September 03, 2002 at 18:38:08, Ron Langeveld wrote: >On September 03, 2002 at 16:12:13, Robert Hyatt wrote: > >>On September 03, 2002 at 15:41:05, Gian-Carlo Pascutto wrote: >> >>>On September 03, 2002 at 15:30:51, Matthew Hull wrote: >>> >>>>There's nothing wrong with the numbers to start with. The efficiency drop off >>>>up to 16 processors looks reasonable. As for the "too perfect" numbers, it >>>>depends on the display software used to create the table. Especially if one >>>>uses FORTRAN or some other software that though you are rounding off, it still >>>>wants to pad the display with zeros. >>> >>>Please look at the actual data. I will post the link in a minute. >>> >>>-- >>>GCP >> >> >>Here it is: >> >> >>First, times in seconds: >> >>pos 1 2 4 8 16 >>1 2,830 1,415 832 435 311 >>2 2,849 1,424 791 438 274 >>3 3,274 1,637 884 467 239 >>4 2,308 1,154 591 349 208 >>5 1,584 792 440 243 178 >>6 4,294 2,147 1,160 670 452 >>7 1,888 993 524 273 187 >>8 7,275 3,637 1,966 1,039 680 >>9 3,940 1,970 1,094 635 398 >>10 2,431 1,215 639 333 187 >>11 3,062 1,531 827 425 247 >>12 2,518 1,325 662 364 219 >>13 2,131 1,121 560 313 192 >>14 1,871 935 534 296 191 >>15 2,648 1,324 715 378 243 >>16 2,347 1,235 601 321 182 >>17 4,884 2,872 1,878 1,085 814 >>18 646 358 222 124 84 >>19 2,983 1,491 785 426 226 >>20 7,473 3,736 1,916 1,083 530 >>21 3,626 1,813 906 489 237 >>22 2,560 1,347 691 412 264 >>23 2,039 1,019 536 323 206 >>24 2,563 1,281 657 337 178 >> >> >>Next, nodes: >> >>pos 1 2 4 8 16 >>1 87,735,974 89,052,012 105,025,123 109,467,495 >>155,514,410 >>2 88,954,757 90,289,077 100,568,301 110,988,161 >>137,965,406 >>3 101,302,792 102,822,332 111,433,074 117,366,515 >>119,271,093 >>4 71,726,853 72,802,754 74,853,409 88,137,085 >>104,230,094 >>5 49,386,616 50,127,414 55,834,316 61,619,298 >>89,506,306 >>6 133,238,718 135,237,296 146,562,594 168,838,428 >>226,225,307 >>7 58,593,747 62,602,792 66,243,490 68,868,878 >>93,575,946 >>8 225,906,282 229,294,872 248,496,917 261,728,552 >>340,548,431 >>9 122,264,617 124,098,584 138,226,951 159,930,005 >>199,204,874 >>10 75,301,353 76,430,872 80,651,716 83,656,702 >>93,431,597 >>11 95,321,494 96,751,315 104,853,646 107,369,070 >>123,994,812 >>12 79,975,416 85,447,418 85,657,884 94,000,085 >>112,174,209 >>13 66,100,160 70,622,802 70,796,754 78,834,155 >>96,053,649 >>14 58,099,574 58,971,066 67,561,507 74,791,668 >>95,627,150 >>15 84,143,340 85,405,488 92,557,676 97,486,065 >>124,516,703 >>16 75,738,094 80,920,173 79,039,499 84,141,904 >>94,701,972 >>17 154,901,225 184,970,278 242,480,013 279,166,418 >>416,426,105 >>18 20,266,629 22,856,254 28,443,165 31,608,146 >>42,454,639 >>19 93,858,903 95,266,785 100,527,830 108,742,238 >>114,692,731 >>20 231,206,390 234,674,482 241,284,621 271,751,263 >>264,493,531 >>21 112,457,464 114,144,324 114,425,474 123,247,294 >>118,558,091 >>22 81,302,340 86,865,131 89,432,576 106,348,704 >>135,196,568 >>23 63,598,940 64,552,923 68,117,815 81,871,010 >>103,621,303 >>24 80,413,971 81,620,179 83,919,196 85,810,169 >>90,074,814 >> >> >>And finally speedups: >> >>1 1 2.0 3.4 6.5 9.1 >>2 1 2.0 3.6 6.5 10.4 >>3 1 2.0 3.7 7.0 13.7 >>4 1 2.0 3.9 6.6 11.1 >>5 1 2.0 3.6 6.5 8.9 >>6 1 2.0 3.7 6.4 9.5 >>7 1 1.9 3.6 6.9 10.1 >>8 1 2.0 3.7 7.0 10.7 >>9 1 2.0 3.6 6.2 9.9 >>10 1 2.0 3.8 7.3 13.0 >>11 1 2.0 3.7 7.2 12.4 >>12 1 1.9 3.8 6.9 11.5 >>13 1 1.9 3.8 6.8 11.1 >>14 1 2.0 3.5 6.3 9.8 >>15 1 2.0 3.7 7.0 10.9 >>16 1 1.9 3.9 7.3 12.9 >>17 1 1.7 2.6 4.5 6.0 >>18 1 1.8 2.9 5.2 7.7 >>19 1 2.0 3.8 7.0 13.2 >>20 1 2.0 3.9 6.9 14.1 >>21 1 2.0 4.0 7.4 15.3 >>22 1 1.9 3.7 6.2 9.7 >>23 1 2.0 3.8 6.3 9.9 >>24 1 2.0 3.9 7.6 14.4 >>avg 1 2.0 3.7 6.6 11.1 >> >> >>All of the data was produced by a program similar to that which I use to >>produce results from things like WAC and so forth. The program eats the >>log files, gathers the nodes, times, scores, etc, and then produces whatever >>table I asked it for... > >If I take these integer numbers and aply them to an Excell spreadsheet i can >easily calculate the speed up from 1 to 2 , 2 to 4, 4 to 8, etc. Similar to the >"log-grab" program only without rounding 1,9 or 1,95 to 2. > >The results are really close. Too close for any coincidence i.m.h.o. >Anybody can do this exercise. One can even do a min and max function on the >numbers and find the spread. It looks rather narrow. Almost within 1% on first >look. Is this typical for any collection of 24 testpositions ? > > 1 to 2 cpu 2 to 4 cpu 4 to 8 cpu 8 to 16 cpu >1 2,029999963 2,005776673 1,993545033 1,9870753 >2 2,03071275 2,005207894 1,993048721 1,987087976 >3 2,029999963 2,006887723 1,993726046 1,985683237 >4 2,02999995 2,007622728 1,993926534 1,984250684 >5 2,02999995 2,004926263 1,998305801 1,98300203 >6 2,029999958 2,005860469 1,994487613 1,986123519 >7 2,031398711 2,0052451 1,995484885 1,983637268 >8 2,030279039 2,004871076 1,992957619 1,988082562 >9 2,029999963 2,005740789 1,993337417 1,987287325 >10 2,030835357 2,006412466 1,990415531 1,988820829 >11 2,02999997 2,006302162 1,992563793 1,987084336 >12 2,030403174 2,006440506 1,995802261 1,983453568 >13 2,031048391 2,00671634 1,992254243 1,98628956 >14 2,031085506 2,00599896 1,99711667 1,98146469 >15 2,02999995 2,006820858 1,992252319 1,986875243 >16 2,030432531 2,007150148 1,993139041 1,985090595 >17 2,030665155 2,004762107 1,99275119 1,988291729 >18 2,035040364 2,006794579 1,9895387 1,982752603 >19 2,030680718 2,004254122 1,993297016 1,988102572 >20 2,030271648 2,004818848 1,99254885 1,988822709 >21 2,029999965 2,006032691 1,995602371 1,98478888 >22 2,030555214 2,00696505 1,994423087 1,983931872 >23 2,03099604 2,006107451 1,994489281 1,984514164 >24 2,030792311 2,00469142 1,993484722 1,987350714 > >Regards, >Ron Are you talking about nodes searched? Yes. Cray Blitz simply _always_ searched something on all processors. As a result, if you look at the total nodes searched, the NPS is actually pretty constant when you go from 4 cpus to 8. it goes up by almost exactly 2x. Of course, in most cases, some of those nodes are not needed, but the NPS is almost perfectly linear, as it is in Crafty for 1,2,4 processors on my quad... Nothing unusual there at all. It was explained in the DTS paper. One early decision was to _never_ have a processor idle waiting on some place to split. When a processor became idle, it would find a place _right now_ and go to work, which occasionally caused extra nodes. Crafty uses a modified YBW and so does have a little idle time here and there, although even in Crafty it is generally 1-2% of one cpu only...
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.