Author: Matt Taylor
Date: 21:21:15 12/31/02
Go up one level in this thread
On December 31, 2002 at 23:08:09, Vincent Diepeveen wrote: >On December 31, 2002 at 13:57:13, Matt Taylor wrote: > >>On December 31, 2002 at 11:49:31, Vincent Diepeveen wrote: >> >>>On December 30, 2002 at 22:32:52, Robert Hyatt wrote: >>> >>>>On December 30, 2002 at 20:29:11, Vincent Diepeveen wrote: >>>> >>>>>On December 30, 2002 at 19:39:23, Frank Koenig wrote: >>>>> >>>>>>Two questions. >>>>>> >>>>>>One) Will Intel's HT technology be able to help chess programs above and beyond >>>>>>just allowing one CPU to appear as two? >>>>>> >>>>>>Second) If you are running XP, will HT require XP Pro instead of XP Home to take >>>>>>advantage of it? >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Frank >>>>> >>>>>For dual machines you need even newer releases of OSes to still get >>>>>released. >>>>> >>>>>However you can profit from it in a very limited way. It's a speedup of >>>>>18% for DIEP at the latest P4 (3.06Ghz), at older P4s the profit is less >>>>>(like P4 Xeon 2.8Ghz) and even older P4s the profit is zero or negative. >>>> >>>>Any chance you will _ever_ "test before talking"? >>>> >>>>The 2.8 xeon has the _same_ SMT core as the PIV/3.06. The _same_ means >>>>"the same", not "something that is not as good as." >>> >>>http://www.realworldtech.com/index.cfm and ask intel designers themselves. >>> >>>>That is simply a crock statement that is nonsense. From _testing_ on >>>>my part... >>> >>>I see a clear difference in performance. Intel managed to slowly improve SMT >>>to what it is now. I do not find 18% impressive knowing the chip is already >>>that much slower than the K7 for me. >> >>Um, they don't "fix" things that quickly. The Hyperthreading in the Pentium 4 >>3.06 GHz is the same Hyperthreading in the Xeon 2.2, 2.4, 2.53, and 2.8 GHz >>chips. > >Look at my questions there posted and the answer from some major experts >there. Many work either for AMD or intel at processor design and they >mention that intel improved SMT slowly to what it is now. And it *does* >speed me up now. That's more than i had expected after they started >drumming with it a few years ago. Yes, but the HT in Xeons is the same HT in the P4 3.06 GHz. The intermediate steps were never released to the public. (Actually the chips probably had HT, but the BIOS vendors were not allowed to enable it.) >>You still seem to be hung up on ipc. The K7 had better ipc than the Pentium > >for me IPC = inter process communication. > >Which ipc do you refer to? As a programmer, IPC = interprocess communication. In the context of CPUs and hardware, IPC = instructions per cycle. >>Pro/2/3. The Pentium 4 is not designed to be efficient with work done per clock. > >Exactly and i find that very sad. However with exception of crafty in >specint, which is a good thing to be in specint, it seems that work done >each processor clock is no big issue. Just L2 cache speed and bandwidth >and some technical details i probably didn't guess so well yet. If you own a car with a 5-gallon tank that gets 50 mpg (miles per gallon) and a car with a 15-gallon tank that gets 25 mpg, which travels further? Efficiency is not necessarily an indicator for raw performance. >>It is designed to ramp to high clock speeds, something the K7 will not do. The >>K7 is nearing the end of its lifetime -- it's running more than 4 times faster >>than its introductory speed. > >I got impression the initial released core was a different one from the >tbird and the athlon MP 1.2 Ghz, later called XP and MP, to be a completely >new recalculated core again. > >probably a lot being the same, but to me it definitely was a different chip. > >Just like the new P4s seem completely different to me from the older P4s >too. Then you are mistaken. The cores have only been tweaked from their original designs. One example -- the Pentium 3 was a Pentium 2 with SSE and clocked to higher speeds. The new P4 is the original P4 with a bigger cache. The designs themselves are identical; a few timings differ, but nothing terribly significant. I have timed sequences of code within 0.1% execution speed between the original Athlon and the AthlonMP (Palomino) chips in my SMP box. When compared to the K6 iterations or the P6 core (Pentium 2/3), there is a big difference. >If something has a good name it would be dumb that an improvement to it >is released under a completely different name. They are both released under the name "AMD." If you hadn't noticed, AMD is starting to brand their processors like Intel does. The palomino chips became AthlonXP. Both steppings of Thoroughbred cores are also called AthlonXP. The Clawhammer (K8) is Athlon64. >Also unless they can produce that hammer real cheap, the higher clocked >0.13 K7s will definitely kick butt if they reach 3Ghz too, whereas the >P4 at 0.13 won't go above 3Ghz much. WHAT?! The Pentium 4 is destined for 5 GHz. Also, the last K7s will be released within a few months. (Check AMD's processor roadmap.) The Barton core puts the long-awaited 512 KB L2 cache on K7. Guess what? Barton will also be called AthlonXP. Clawhammer will be roughly the same price as an AthlonXP chip. This is mostly due to the fact that a K8 is really only a tweaked K7. The K6 and K7 have much less in common than the K7 and K8 (which have nearly identical pipelines). >>>>>So it's progressing but the P4 is a processor not really mature enough: >>>>>too little trace cache and too little datacache: just 1024 quadwords; >>>> >>>> >>>>So? 12K micro-ops. 8kb data. Core-speed L2 cache with 512KB unified >>>>cache. Seems to work quite well in all the testing I have done. >>> >>>If it is in theory simply 2 processors then 11% at older types and 18% at >>>new P4 3.06ghz is not much and because of the small L1. Also i didn't >>>figure out yet how big the branch prediction table (BTB) is in the P4 >>>but it probably isn't so impressive. >> >>The BTB size doesn't affect that much. It is comparable, but I never concerned >>myself with useless details. > >For many chessprograms the BTB up until like 2000 entries is very >important. Get the best compiler you can get for crafty and compare its >specint version (so no inline assembly getting used) at a P3 with 512 >BTB versus 2048 BPT from K7. > >You'll see a *huge* difference in speed. You'll also see a huge difference in speed if you run good code that avoids branching. I've stated a number of times here that there are many techniques to eliminate branches -- both in high-level code and at the assembly level. The BTB size really only yields gains in code that: (1) can't avoid branching (2) uses indirect/conditional branches fairly often (3) branches in a predictable manner >>The small L1 is not the reason why the Pentium 4 with Hyperthreading only gets >>11% or 18% when performance fairy decides to crank it up a notch. (Look for the >>performance fairy enable option in your BIOS.) The Pentium 4 has 512 KB of L2 >>cache -- more than any variant of the K7 has in total. L2 is not as fast as L1, >>but it doesn't make a huge difference because it's a lot faster than main >>memory. > >For nearly all specint programs which focus upon that cache of course it >matters a lot that 256 to 512. Ok, but since when do chess programs focus on the cache? >If you have a very weak spot in a processor and then have a bigger L2 cache >to catch up a bit of the problems, then that obviously works. > >>The real reason why the data changes from 11-18% across processors is because >>you aren't accurately benchmarking. You can't run one test and call it >>conclusive. > >You do not seem to understand a few things. > >Crafty splits at random and when a processor has to abort itself >it splits near the leafs more. Splitting can be very expensive and >entire root is kept locked while doing so. > >That creates a very unstable form of parallellism. > >DIEP is more stable in this sense: > - splitting more near the root > - hardly overhead for splitting and doing a minimum > of locking. > >A few tests which all were within a few tenths of percents definitely >mean *something* then. Yours weren't -- 11% to 18%. Also, I don't believe I mentioned Crafty or Diep at all. >I dare to mention that my tests are 100 times more objective than the >specint numbers you can see from several programs at the different >spec tests as those numbers are generated after the compiler teams >of the different manufacturers. > >You can stand on your head and claim anything but those numbers are >very representative which i measured and inline with other results done >by many testers! Which are conveniently documented nowhere, not run multiple times, and not reported with detailed configuration information. That really doesn't matter, though. I've gotten less variance polling political opinions. >The important thing with these tests is not whether i measure 18% or 11% >or 22% or 17%. > >The importance is that it's not near a 2 times speedup. The importance >for me is that it is *trivial* that even the cheap outdated K7 which >soon is clocked to 3Ghz too, that this is toasting the P4 alive for >DIEP. Even when i use the SMT. Who cares? HT isn't SMP or it wouldn't be evolutionary. HT costs pennies more to produce and sports a nice performance/price ratio. Also FYI the K7 will never hit 3 GHz. Even if it did, the P4 would be at 4 GHz by the time the K7 hit 3 GHz. Comparing clock-to-clock between P4 and Athlon is useless and rediculous. >We didn't talk about speedup yet. Let's be clear here. Bob didn't >start about it yet. > >But please keep in mind next. > >Bob reports something like 30% speedup? > >Even his own formula (which i disagree with because it is >impossible to have a 0.n speedup for each additional processor >it gets less and tests from GCP at 30 positions indicated 2.8 >speedup out of 4 processors whereas the constant formula gives >3.1) which gives speedup = 1 + 0.7(n-1) means the effective >speedup of crafty because of SMT is a lot less. > >Did you realize that? Actually overheads are approximately linear. Not entirely, but approximately. >To do the math for his dual Xeon running 2 threads how many processors do >we have netto? > 2 n ==> (1.7 / 2) * 2 = 1.7 speedup to 1 thread > >Now if he has 4 processors getting 30% more nodes a second in total >than 2 processors do that gives > 2 * 1.3 = 2.6 ==> (3.1 / 4 ) * 2.6 n = 2.015 speedup > >effective win by SMT in the Hyatt article from a few years ago: > 2.015 / 1.7 = 18.5% I see a lot of numbers, but I really don't follow that logic. >If we do the same math for GCP measured numbers at positional testsets >then it is at P3 xeon (and at faster processors it is even worse for >the 4 processors compared to 2 processors >of course as memory plays a bigger role there then): > 2 threads: 1.6 > 4 threads: 2.8/4 * 2.6 = 1.82 >effective win by SMT ==> 14% > >In current DIEP i get 1.9 speedup at 2 processors >and 3.6 speedup at 4 processors > >That's of course a way better speedup than crafty, but do the >same math for SMT like i did a few months ago which caused me to >get very unhappy about SMT. You were unhappy because you were expecting a massive performance boost. It's not about leaps and bounds. It's about cheap design changes that pull another 5% here and 10% there. >>>>>compare with the 64KB L1 data cache of a K7 which is i guess 16384 >>>>>doublewords. >>>> >>>> >>>>what is with all the quadword/doubleword nonsense? >>> >>>>I think _most_ here can figure out what 64 KB turns into in your favorite >>>>data size... >>> >>>64KB of K7 and just 1024 words of P4. >>> >>>The P4 is using 64 bits adressing for the L1 that means just 1024 words. >>>I prefer personally 16384 words of 32 bits. >>> >>>However the P4 doesn't deliver 2048 words of 32 bits. It delivers 1024 >>>words of 64 bits. > >>Um, what? Xeon has used 36 bits for L1 and L2 address tags since the days of the > >>Pentium Pro because of the PAE/PSE36 addressing extensions. The chips run on a >>36-bit address bus, not a 64-bit address bus. > >This info i had received by email long before the P4 was introduced and >before they released design documents about it. A lot of data i have >here is outdated >usually when the processor then gets introduced. That is sad such a big >disinformation caused by everyone who wants to publish about it. I would want >to look this up though. 36 bits looks very silly to get from P4 processors L1 >or L2 cache as i work with 32 bits variables and when talking about node >count it is 64 bits, but definitely never 36 bits. Read about PAE. Dr. Dobbs Journal has a nice article about it which has been up for a few years. It's been on every processor since the Pentium, but only Xeon supports it. The other mechanism Intel uses is PSE36. Applications still only get 4 GB of memory, but 36-bit addressing means you can have 64 programs in the system each eating 4 GB of memory. In the case of Windows, with tricks similar to old EMS memory you can see more than 4 GB of memory. -Matt
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.