Author: Vincent Diepeveen
Date: 05:07:09 09/18/03
Go up one level in this thread
On September 17, 2003 at 16:03:09, Robert Hyatt wrote: >On September 17, 2003 at 14:54:41, Vincent Diepeveen wrote: > >>On September 17, 2003 at 14:47:49, Robert Hyatt wrote: >> >>lower clocked opterons are like $300, so i am pretty sure there is a big demand >>already. > >No there isn't, because for single and dual machines, the NUMA issue can >pretty well be ignored. There are not many 16-way boxes available at the >present, which means the NUMA issue is a ways off from becoming a real >issue. > >But it will eventually. > >There are a few dual opteron machines around, for sure. But I'm not seeing >much beyond that yet... I hope you realize i have extensively tested diep at a quad opteron with linux-NUMA kernel. There are *many* issues. Even despite that it's 2 times faster than a dual Xeon. Yet most of those issues diep didn't feel because it can withstand poor kernel scheduling with as a result bad latency. It's simply written to work well at origin3800-512 processors, so what could i possibly comment to the latencies there other than they are around 6-7 us at a 512 proc partition, when we look at it from a positive viewpoint. But other software runs crap at it. I bet that won't get posted. The real conclusion i have made is that the opteron is the best show what an overwhelming monopoly microsoft has. Linux numa scheduling works crappy, but despite that still is a factor 2 faster. If it would run windows like that, then everyone would want it badly. Because the quad opteron had already public available processors 1.8Ghz i can show 1 result to you regarding it. I compiled also some latency tests at it and those showed that the RNG was way faster at the opteron than at any other hardware, which shows how fast this processor will be for the academic world (apart from that it has no competition soon in the academic world because it is x times cheaper than a 1.5Ghz itanium2): The speed from it at the opteron 1.8Ghz is: So 1 RNG call takes 3.348389 nanoseconds The speed from it at the itanium2 1.3Ghz is: So 1 RNG call takes 9.279785 nanoseconds The speed from it at the K7 2.127Ghz is: So 1 RNG call takes 13.237305 nanoseconds The speed from it at the AMD64 2.2Ghz fx51 is: <censored till 23 september> The speed from it at the P4 Xeon 3.06Ghz 1MB L3: <censored> Best regards, Vincent > >> >> >> >>>On September 17, 2003 at 12:11:59, Vincent Diepeveen wrote: >>> >>>>On September 17, 2003 at 11:22:58, Robert Hyatt wrote: >>>> >>>>>On September 16, 2003 at 22:30:47, Vincent Diepeveen wrote: >>>>> >>>>>>On September 15, 2003 at 14:16:38, Robert Hyatt wrote: >>>>>> >>>>>>>On September 15, 2003 at 13:18:28, Gian-Carlo Pascutto wrote: >>>>>>> >>>>>>>>On September 14, 2003 at 12:52:54, Sietel Monic wrote: >>>>>>>> >>>>>>>>>My friend runs dual proccessors using hyperthreading so gets 4 threads, I know >>>>>>>>>this is bad for chess. Just dont know why >>>>>>>> >>>>>>>>This is ok. Running with 2 threads on a dual processor with hyperthreading >>>>>>>>enabled is _not_, unless you're running Linux 2.4.x or Windows Server 2003. >>>>>> >>>>>>You sure of this bob? >>>>> >>>>>I am certain. I have duals all over the place, running 2.4.20 and 2.4.21 (I >>>> >>>>Does that say 2.4.20-NUMA >>> >>>I don't compile with NUMA kernel option because I don't have any NUMA >>>boxes. However, the -NUMA doesn't mean anything. You can compile a NUMA >>>kernel and not have the -NUMA extension, and vice-versa... >>> >>> >>>> >>>>or does it only say 2.4.20 x86 ? >>>> >>>>But in general i agree. i find the linux OS as a whole a joke at NUMA machines. >>>>And kernel 2.6 won't be much better either i bet. >>> >>>As I said before, there is presently very little demand for NUMA linux >>>support. As the demand grows, the O/S sophistication will grow with it, >>>just as SMP did. Original Linux had no SMP support either. Until the demand >>>was formed as cheap duals and sorta-cheap quads came along later. >>> >>>Once the opteron is readily availble in cheaper configurations, NUMA support >>>will take off... >>> >>> >>>> >>>>>did say I had not tested 2.4.22 yet). Also, your question is in the wrong >>>>>place. I didn't write the above. GCP did. I responded to it (the response >>>>>appears below).. >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>>QUADopteron:/diep/latency # uname -a >>>>>>Linux QUADopteron 2.4.19-NUMA #3 SMP Wed Jul 2 18:34:37 CDT 2003 x86_64 unknown >>>>>> >>>>>>Perhaps all you need is a special extension to the kernel. >>>> >>>>>We are talking about hyper-threading. 4 logical processors with two real >>>>>processors. What are you talking about? The opteron is not hyper-threaded. >>>>>The issue is that the O/S has to recognize that with only two runnable processes >>>>>on a dual-cpu hyper-threaded machine, it needs to run each process on a >>>>>different physical processor for max performance, rather than running both on >>>>>two logical processors that are on the same physical processor, which would >>>>>run much slower. >>>>> >>>>> >>>>>> >>>>>>>Linux 2.4.x won't cut it either. I use 2.4.21 and it is _not_ SMT-aware. IE >>>>>>>it will certainly recognize 4 processors, but it doesn't realize that if there >>>>>>>are just two computational tasks to run, they should be run on two physical >>>>>>>processors. 2.4 just runs them on any two logical processors. When the two >>>>>>>logical processors are on one physical processor, this performs poorly. Ingo >>>>>>>Molnar did a scheduler that addresses this (or maybe Rick did it). And it works >>>>>>>well (it has two run queues, one for each physical procesor, rather than four, >>>>>>>one for each logical processor.) But that isn't in mainstream 2.4 yet (I have >>>>>>>not looked at 2.4.22 closely so it _could_ be there). >>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>GCP
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.