Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
s > > On Sparcs, my experience is that by compiling non-parallelized (non-threaded) > programs without SMP flags - they run a lot faster. As Solaris (or HP-UX) > lends less ability to look "under the hood", I cannot explain why this is the > case. Yes this is what we saw. Maybe you can answer another question as I am new to multi-CPU machines. Even with the non-SMP option compile a single GEMPAK script will run slower on the E6500 than it will on an ordinary Ultra 10 (440Mhz vs. 400Mhz). If you look at top while the script is running on the E6500 you will see it "hopping" between CPUs..which of course slows it down. Is there a way to prevent this? Thanks. > > > Stonie > On Sat, 25 August 2001, Robert Mullenax wrote: > > > > > "Neil R. Smith" wrote: > > > > Neil, > > > > I don't know about the Portland compilers but we built GEMPAK on our Sun > > E6500 > > (12 CPUs) with the Sun FORTE -xparallel option and it ran slower than a > > version > > compiled with standard optimization. Which leads to be believe GEMPAK > > is not > > parallelized. Can someone confirm or deny this? Has anyone benefitted > > on GEMPAK with multi-CPUs? > > Stonie R. Cooper > Science Officer > Planetary Data, Incorporated > 3495 Liberty Road > Villa Rica, Georgia 30180 > ph. (770) 456-0700
ldm-users archives: