Author: Vincent Diepeveen
Date: 16:43:30 09/18/03
Go up one level in this thread
On September 18, 2003 at 19:06:54, Eugene Nalimov wrote: >On September 18, 2003 at 18:32:23, Gian-Carlo Pascutto wrote: > >>On September 18, 2003 at 11:06:13, Robert Hyatt wrote: >> >>>On September 18, 2003 at 03:50:11, Gian-Carlo Pascutto wrote: >>> >>>>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 >>>> >>>>Ignored? You _will_ get a performance handicap if you do so. >>>> >>>>-- >>>>GCP >>> >>>Yes, but on a dual it is a _minimal_ handicap. >> >>Last week, this 'minimal' handicap was enough to require a special >>version of Crafty. Now it's not needed for the Linux kernel? Uhh... > >I believe you never participated in a *huge* software project. While you can >relatively easy do something for a small (~100k lines) program, especially if >nobody expects 24/7 reliability from that program, it's very hard to incorporate >new features into huge product when (a) currently those features are not needed >for 99.9% of customers, and for 95% of the remaining ones speedup will be in the >single-digit range, (b) you need API changes, (c) there is already long pipelne >of changes that are much more urgent, (d) changes are necessary not on GUI side >(or some external tools, or some localized components), but spread over the >product's core. And so on, and so on... > >Thanks, >Eugene I don't want to sound rude here towards the linux community as it isn't meant like that, but already years ago i felt this problem when i wanted something changed in the kernel. My questions were simple and both linus and cox said they weren't responsible and no one was, which is weird... But you need someone who can actually modify that very difficult SMP code in the kernel to NUMA code in the linux kernel. All i know, without taking viewpoint on who owns it my viewpoint is that is NOT sco, you need someone who actually has WRITTEN that code to modify it and in the whole linux community there isn't a dude who is CAPABLE of modifying that code. The biggest progress there so far was commercial cut'n paste progress by IBM & SGI, and i feel they were in their right to do so! Yes it is a lot of code to modify, basically because in the past it was set up wrong simply. Doesn't take away that where for a dual opteron and quad opteron it will probably work great in the far future, for bigger NUMA machines like SGI altix it will never work great because they do not program hardware specific. In fact i suspect SGI has some cool changes in the kernel which they are not releasing currently. The kernel at the 64 processor altix3000 was doing very poor compared to how irix works at origin3800 (and on paper altix3000 has 2x higher bandwidth each 'brick'), but even that was way way better than how linux numa kernels works at a quad opteron at the moment. At quad opteron at the moment it schedules allocation of ram at different 'processor', it even is doing this wrong when there is 1 process just eating 25% system time and you run only a single cpu test at 1 processor. A long way to go. >>-- >>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.