On May 6, 3:41 pm, Dan Drake <[EMAIL PROTECTED]> wrote: > On Tue, 06 May 2008 at 03:07AM -0700, mabshoff wrote: > > IIRC you also saw quiet odd things happening with ptest.
Hi Dan, > That was on a different machine. I still have an account at the > University of Minnesota and am ssh'ed into a computer there. (It happens > to be the computer in my old office. :) > > > But even if pbuild is only running one thread at a time it should > > still compile roughly as fast as setup.py since it is more or less > > doing the exact same amount of work. So I am puzzled. > > Yeah, taking over an hour longer seems like something is really wrong > somewhere. +1 > > What seems odd to me is that cpuinfo reports different CPUs: > > > > model name : AMD Athlon(tm) MP 2600+ > > > model name : AMD Athlon(tm) Processor > > > Since that is generally not a good idea therein may lay your trouble. > > I am sure that mixing and matching CPUs [i.e. MP with non-MP] is not > > supported by AMD and it seems a sheer coincidence that your setup even > > boots. Should they both be "AMD Athlon(tm) MP 2600+" CPUs then > > something else hardware wise is probably broken. So in conclusion I > > expect your hardware/software setup to be at fault here until proven > > innocent :) > > I noticed that too, but it's the same model and stepping and all that. Ok. > These computers were set up by the U of M math department IT staff, who > really do know what they're doing. Well, that doesn't really mean a whole lot ;). When I did admin work it as always putting out the biggest fires and since that box "works" it probably isn't on anyones radar. I remember some discussion about running mixed mode Athlons [or Intel CPUs for that matter] on lkml years ago and the consensus was: Don't do it. Bad and unexplainable things happen. Since all the other specs from cpuinfo match it might be a BIOS problem - who knows without poking around and playing with the hardware. I have never seen a box where the above happened with identical CPUs and as you can imagine I have had accounts on a lot of hardware. >Those machines were bought as > dual-processor machines, and I've run two large jobs on them > simultaneously. If you "just" run two large jobs in parallel this might be less of an issue. pbuild starts *a lot* of small processes, so that might make the difference. I wouldn't be surprised if the scheduler acted up for example. > I did try this: I started Sage (it's another copy on that machine) and > factored some big number -- it took 11.95 seconds CPU time. Then in > another shell, I started a big bzip2 job. Back in Sage, I factored the > number again, and it took 13.2 seconds. That's a bigger penalty that I'd > like to see, but both processors are clearly working. That might have to do with the front side bus since it is shared between Athlon MPs. Only the Opteron introduced a memory controller on chip, so I am not surprised here. > BTW, I ran 'make test' in the 3.0.1 tree and all tests passed (from the > traditional build). Ok. It is more about performance than correctness. If the box was truly broken someone else would have noticed. I would highly recommend that the people running that box check out what is going on and try newer kernels to see what is going on. Misdetections like this can cause all kind of odd problems and since no one reports similar problems with pbuild I tend to blame your hw setup ;) > Dan Cheers, Michael > -- > --- Dan Drake <[EMAIL PROTECTED]> > ----- KAIST Department of Mathematical Sciences > ------- http://math.kaist.ac.kr/~drake > > signature.asc > 1KDownload --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
