On Wed, 2006-01-25 at 12:24 -0700, Duncan wrote: > B Vance posted <[EMAIL PROTECTED]>, > excerpted below, on Wed, 25 Jan 2006 11:16:24 -0500: > > >> virtual cpus? > >> > >> intel has hyperthreading, if you mean that, not amd. > >> > >> the rule of thumb is cores+1 > >> > >> but it is totally personal taste, what you set for jX. > >> 1,2,3,4,5 just try it and choose the number where the result is most to > >> your > >> liking. > > > > Cool, thanks. Must of been thinking of something else that AMD had > > licenced from Intel for core CPU use. Could have sworn that AMD had a > > version of Hyperthreading. > > Maybe you are thinking about (the unrelated) HyperTransport? That's an > all-AMD thing, the reason they seem to have such good performance compared > to Intel, which is stuck with legacy front-side-bus architecture for the > moment, with it throwing a /serious/ wrench into their upgrade plans ATM. > > As for Hyperthreading, AMD hasn't used it and really doesn't need or want > to. Hyperthreading works its magic by working around the extremely deep > pipeline that Intel had used, in ordered to get their clock rates so high. > Such a deep pipeline forces a *HUGE* penalty when there's a branch > miss-prediction and the CPU has to throw away several cycles worth of work > and let the bottom end of the pipeline idle while it loads the correct > instructions from the top of the pipeline again. Hyperthreading is a > rather neat solution that avoids the severe penalty by having a second > task ready and waiting to execute while the first one gets loaded into the > pipeline once again. > > AMD has a somewhat shorter pipeline, and uses some other technologies to > improve the branch prediction and lessen the severity of mis-prediction > hits, both. It isn't /that/ much shorter a pipeline, the branch > prediction isn't /that/ much better, and the miss-prediction penalty not > /that/ much less, but put all three together, and add in the effect of the > front-side-bus vs hypertransport on memory latency, and the individual > single-digit improvements begin to add-up to something rather bigger. > Hyperthreading only yields an approximate 30% increase in performance, > best-case, anyway, compared to a theoretical 100% increase if it were a > real CPU. Thus, AMD doesn't have to cover as much ground with their > individual "minor" improvements as one might think, and because > hyperthreading has certain downsides (effectively halving the available > cache per thread, and certain thread-cache-access security issues where > the hyperthread has access to the memory of the other thread), they > believe they do better without hyperthreading. > > I believe AMD does better without hyperthreading as well, from a technical > viewpoint, altho Intel has the PR game won with hyperthreading, as it's > simply not possible to explain in two sentences why AMD doesn't need > hyperthreading, as opposed to the relatively simple concept Intel has to > get across, of pretending there are two CPUs so the second task can get > some work done when the first task is waiting for something. > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman in > http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html > > Thank you for explaining that Duncan. Guess it's time for me to start reading a bit more then I have lately.
B. Vance -- [email protected] mailing list
