I guess I was not worried about major improvements from kernel changes as
much as I was disappointed in the XP 2100+ delivering a nice speed up in
general.  As suggested by you and others, the kernel should NOT have make
that much difference.  I am just disappointed in overall CPU performance.

Comments to other replies ...

There is a lot of memory management.  The run takes around 450-500 MB of
RAM, and it is an iterative solution, which means things have to be operated
on a lot ... moving to and from the CPU.

Can I send out a binary?  No ... it is a commercial code that requires a
license key (based NIC card IP) in order for it to run.  So ... there is no
way to run it on other hardware, unless that hardware already has a license
key.  Thanks for the offers though.

Randy


----- Original Message -----
From: "Phil Mendelsohn" <phil at rephil.org>
To: <tclug-list at mn-linux.org>
Sent: Wednesday, October 30, 2002 10:07 PM
Subject: Re: [TCLUG] Computational Speed - Kernels / CPU


> tclug-list-request at mn-linux.org writes:
>
> > Ok ... I have finally finished the simple comparison on different =
> > kernels and computational speed.
> >
> > I ran a commercial code that required memory (lots of matrix solutions)
=
> > and large amounts of CPU times.  Recall that I previously posted the =
> > times, stating I was disappointed in the speedup from a PIII 700 MHz.  =
> > The results are listed below.  The AMD machine was dedicated to this =
> > problem - nothing else was running at the time.
> >
> > PIII 700 MHz (dual CPU - only 1 used for solution)        96,370 secs
> >    -  Win2000
> >
> > AMD XP 2100+ (single CPU)  686 kernel (?)                65,039 secs
> > AMD XP 2100+ (single CPU) Athlon kernel                   63,411 secs
> >   -  Linux RH7.2
> >
> > No real improvement in performance.  I must say I am disappointed in the
=
> > speedup.
>
> Um, if you're crunching numbers, the kernel shouldn't be interacting very
> much.  Where kernel comes in  is if you're losing speed to time-sharing,
> process swap overhead, paging, or maybe I/O.  Seems to me you wouldn't be
> hitting any of those things, so I guess I'm surprised you're seeing as
> *much* as you did.  (Without knowing what your algorithm or data set is...
> nothing better than being unencumbered by facts!)
>
>  --
> "To misattribute a quote is unforgivable." -- Anonymous
> _______________________________________________
> Twin Cities Linux Users Group Mailing List - Minneapolis/St. Paul,
Minnesota
> http://www.mn-linux.org tclug-list at mn-linux.org
> https://mailman.mn-linux.org/mailman/listinfo/tclug-list