Topcluster listing
Erich Strohmaier
Yes, I set up the prototype in February and announced it on beowulf and
tfcc. I have also filled the DB mainly with information I gathered myself
from (potentially outdated) web-pages. We have 59 entries right now.
Submissions from the web-interface are sent to me. I edit them and update
the DB. I hope I have catched up now:-)
I hesitate allowing direct update as there is a far amount of 'trash'
coming in (such as kids typing in their 'macs')
This is a prototype and things are changing rapidly at times. This is why
Markus and the other people in the TOP500 project do not have access for
updates right now. This will change once the DB structure is stabilized.
What we need right now is more active submissions ( I had less then 10
sites submitting their info themselve!) as well as feedback to the
usefullness of the collected information.
Thank you
Erich
> Erich has set up the database and I guess he also has all the tools
> and servers to do this.
> >From what I understand is that a submission is sent to him via
> email.
> I just wanted to get the submission going.
>
> Markus
>
> > > I'm not sure how much good this will do. I submitted two of our clusters
> > > well over a month ago, and they've never been added to the list. So, I'm
> > > wondering if anyone is actually maintaining the list.
> >
> > Hi Roger,
> >
> > Markus Fischer is one of the members doing work on TOP500 project and I hope he will
> > maintaining our TopClusters database/list in the future.
> >
> > Regards
> > Raj
>
> --
> ---------------------------------------------------------------
> Dipl. Inf. Markus Fischer Tel.: +49 621 181-2718
> University of Mannheim Fax: +49 621 181-2713
> B6, 26 email:mar...@markus-fischer.de
> 68159 Mannheim
>
>
===========================================================================
Erich Strohmaier email: er...@top500.org
Department of Computer Science phone: ++ 1 (865) 974 0293
1122 Volunteer Blvd, Suite 203 fax : ++ 1 (865) 974 8296
Knoxville TN, 37996-3450 - USA http://www.cs.utk.edu/~erich/
_______________________________________________
Beowulf mailing list
Beo...@beowulf.org
http://www.beowulf.org/mailman/listinfo/beowulf
Dan Yocum
> What we need right now is more active submissions ( I had less then 10
> sites submitting their info themselve!) as well as feedback to the
> usefullness of the collected information.
I suspect that the institutions that have the biggies are too busy with
"real work" to run a benchmark on the cluster - wasted time, and all
that. OK, so it would have been nice to run a benchmark on the new
farms at Fermilab instead of Seti@home to burn them in for Run II but...
it was just easier than futzing around installing MPI/PVM/etc. Oh,
well....
Cheers,
Dan
--
Dan Yocum, Sr. Linux Consultant
Linuxcare, Inc.
630.697.8066 tel
yo...@linuxcare.com, http://www.linuxcare.com
Linuxcare. Support for the revolution.
Greg Lindahl
> "real work" to run a benchmark on the cluster -
Actually, you'll find that "the biggies" in HPC are quite eager to get on
the Top 500 list. It's the industry biggies (google, Incyte) that definitely
don't care.
-- g
Steven Timm
> Greg Lindahl wrote:
> >
> > > I suspect that the institutions that have the biggies are too busy with
> > > "real work" to run a benchmark on the cluster -
> >
> > Actually, you'll find that "the biggies" in HPC are quite eager to get on
> > the Top 500 list. It's the industry biggies (google, Incyte) that definitely
> > don't care.
>
> I tried to get management to run linpack on our "clusters" (OK, so
> they're really farms, but...) at Fermi. We couldn't take the time. We
> had to get the work done. Reality often gets in the way of desire.
>
> Dan
>
As Dan mentioned in a previous post, Fermilab does run seti@home
by way of burn-in, but nowadays we also use application-specific
benchmarks, measuring the performance of our machines on the
actual code that they have to run. Given the nature of experimental
high-energy physics, each node is decoupled from the others.
The nature of the Fermilab problem is well described in Pfister's
book "In Search of Clusters" although at the time he wrote it
we were still an SGI/IBM RS 6000 shop and have since shifted
to Intel/Linux for our compute power.
A new effort at Fermilab is to use Linux-based machines to do
theoretical lattice QCD calculations. This is a program that
is coupled across many machines.
------------------------------------------------------------------
Steven C. Timm (630) 840-8525 ti...@fnal.gov http://home.fnal.gov/~timm/
Fermilab Computing Division/Operating Systems Support
Scientific Computing Support Group--Computing Farms Operations
Erich Strohmaier
> Greg Lindahl wrote:
> >
> > > I suspect that the institutions that have the biggies are too busy with
> > > "real work" to run a benchmark on the cluster -
> >
> > Actually, you'll find that "the biggies" in HPC are quite eager to get on
> > the Top 500 list. It's the industry biggies (google, Incyte) that definitely
> > don't care.
>
> I tried to get management to run linpack on our "clusters" (OK, so
> they're really farms, but...) at Fermi. We couldn't take the time. We
> had to get the work done. Reality often gets in the way of desire.
That's a known issue which hits the cluster community particular hard.
Usually Linpack numbers are provided by manufacturers which run them
"in house" on a reference system (once and forever).
As each cluster tends to be so unique, every site would need to run
Linpack themselves multiplying the effort.
That is the reason why we started to collect data for a seperate
"top cluster list" WITHOUT any benchmark data.
See http://www.topclusters.org
Even without benchamrk data, such a DB could be of interest and use for
the community. The benchmark data will be filled in as we go.
Thanks
Erich
>
> Dan
>
> --
> Dan Yocum, Sr. Linux Consultant
> Linuxcare, Inc.
> 630.697.8066 tel
> yo...@linuxcare.com, http://www.linuxcare.com
>
> Linuxcare. Support for the revolution.
>
> _______________________________________________
> Beowulf mailing list
> Beo...@beowulf.org
> http://www.beowulf.org/mailman/listinfo/beowulf
>
===========================================================================
Erich Strohmaier email: er...@top500.org
Department of Computer Science phone: ++ 1 (865) 974 0293
1122 Volunteer Blvd, Suite 203 fax : ++ 1 (865) 974 8296
Knoxville TN, 37996-3450 - USA http://www.cs.utk.edu/~erich/
_______________________________________________
Dan Yocum
>
> > I suspect that the institutions that have the biggies are too busy with
> > "real work" to run a benchmark on the cluster -
>
> Actually, you'll find that "the biggies" in HPC are quite eager to get on
> the Top 500 list. It's the industry biggies (google, Incyte) that definitely
> don't care.
I tried to get management to run linpack on our "clusters" (OK, so
they're really farms, but...) at Fermi. We couldn't take the time. We
had to get the work done. Reality often gets in the way of desire.
Dan
Eugene Leitl
> In practice however it seems to me to be much harder to utilizes the SIMD
> units on current micro-processors than to use the "normal" FPU.
This is true, but still for people who can talk assembly very
substantial speedups are possible:
http://www.mime.up8.edu/~whygee/memoire/
especially
http://www.mime.up8.edu/~whygee/memoire/corps.html
(I'm not sure whether it's in there, but Yann Guidon did use MMX
acceleration for his lattice gas CFD).
> On traditional vector systems (Cray and such) you have full support of the
> vector units by vectorizing compilers. I am not aware of anything
> close to this on micros. Quoting SIMD flops on a wide basis would raise a
There seems to be SWARC Scc by Hank Dietz
http://dynamo.ecn.purdue.edu/~hankd/SWAR/Scc.html
which attemts to wrap the hardware in C extension abstraction but it
doesn't seem to be developed further. Too bad, I could use it.
> lot of expectations and cause a lot of disappointments. Rather than
> inflating "Macho-flops" I would rather be more realistic in my
> presentations.
>
> Even besides this argument, I will have to swith to a CONSISTENT way of
> representation regardless what it is. Quoting one system with SIMD and the
> next one without does not make sense.
>
> Erich