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