Fortran - On megaflops

Author

On megaflops

sergio_r@mail.com

2006-01-27, 7:01 pm

Hello all,

Attached at the very end of this note there is a fortran
code I am using to count how many megaflops the systems
I have available could do.

If my computations are right, an Intel(R) Xeon(TM) CPU 3.06GHz (DUAL)
based system perform about 3 Mflops, while an AMD Opteron(tm)
Processor 248 (DUAL) is performing about 1000 Mflops. The details
are also included.

I would like to here your comments on the reliability of those numbers.
Please try to run the code on your on system.

I also performed linpack_1000d.f of Jack Dongarra
(http://parallel.ru/ftp/benchmarks/l...linpack_1000d.f)
the numbers are
Xeon based system 1.102E+02 Mflops; AMD system 2.873E+02 Mflops
Something I do not understand from this test is that these number
change
every time one runs it.

Sergio

System Intel(R) Xeon(TM) CPU 3.06GHz (DUAL)
cache size : 512 KB
====================================
rm a.out ; ifort -O -p -g Megaflop_d.f90
rm gmon.out; /usr/bin/time -p ./a.out
real 2799.91
user 2797.93
sys 0.64
gprof ./a.out ./gmon.out
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls Ks/call Ks/call name
100.00 2798.56 2798.56 1 2.80 2.80 gflops_
0.00 2798.56 0.00 1 0.00 2.80 MAIN__
---------------------------------------------------------------
comptime = 2798
MFlops = 1000000000*8./(comptime)/1000000 = 2.859
========================================
=========
************
/usr/bin/time -p ./a.out
Jack J. Dongarra 1000d.f test
norm. resid resid machep x(1) x(n)
1.05174252E+01 1.16766853E-12 2.22044605E-16 1.00000000E+00
1.00000000E+00
times are reported for matrices of order 1000
factor solve total mflops unit ratio
times for array with leading dimension of1001
6.050E+00 2.000E-02 6.070E+00 1.102E+02 1.816E-02 1.084E+02
end of tests -- this version dated 10/12/92
real 7.07
user 7.06
sys 0.01

System AMD Opteron(tm) Processor 248 (DUAL)
====================================
rm a.out ; ifort -O -p -g Megaflop_d.f90
rm gmon.out; /usr/bin/time -p ./a.out
real 14.58
user 7.66
sys 0.00
gprof ./a.out ./gmon.out
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
100.00 76.69 76.69 1 76.69 76.69 gflops_
0.00 76.69 0.00 1 0.00 76.69 MAIN__
---------------------------------------------------------------
comptime = 8
MFlops = 1000000000*8./(comptime)/1000000 = 1000
========================================
=========
For some reason the "gprof" aoutput is 10 times larger than
the "/usr/bin/time" output. Assuming the later,
comptime = 77
MFlops = 1000000000*8./(comptime)/1000000 = 104
************
/usr/bin/time -p ./a.out
Jack J. Dongarra 1000d.f test
norm. resid resid machep x(1) x(n)
6.49150133E+00 7.20701276E-13 2.22044605E-16 1.00000000E+00
1.00000000E+00
times are reported for matrices of order 1000
factor solve total mflops unit ratio
times for array with leading dimension of1001
2.324E+00 3.999E-03 2.328E+00 2.873E+02 6.962E-03 4.157E+01
real 4.16
user 2.47
sys 0.00

The program:
=============
!----------------------------------------------------------
double precision function gflops()
implicit none
real*8 :: a1, a2, b1, b2, c1, c2, d1, d2, e1, e2, f1, f2, g1, g2, h1,
h2
integer :: x

a1 = 1.1; a2 = 1.2
b1 = 1.4; b2 = 1.5
c1 = 1.6; c2 = 1.7
d1 = 1.8; d2 = 1.9
e1 = 2.0; e2 = 2.1
f1 = 2.1; f2 = 2.2
g1 = 2.2; g2 = 2.3
h1 = 2.3; h2 = 2.4

do x=0,1000000000
a1 = a1 * a2
b1 = b1 * b2
c1 = c1 * c2
d1 = d1 * d2
e1 = e1 * e2
f1 = f1 * f2
g1 = g1 * g2
h1 = h1 * h2
end do
gflops = a1 + b1 + c1 + d1 + e1 + f1 + g1+ h1
return
end

program gflop
ver=gflops()
end program
!----------------------------------------------------------

Richard Maine

2006-01-27, 9:57 pm

<sergio_r@mail.com> wrote:

> I would like to here your comments on the reliability of those numbers.

Very low. My main comment is that doing a good job of benchmarking is a
very difficult job. The complications are far too many and subtle to
explain in a simple posting. If you don't understand them, you can get
numbers that make no sense at all, and are off by orders of magnitude.
People spend quite a long time learning about the subject.

It just isn't worth the time to try to even explain the issues here.

You are better off to run real applications of interest to you instead
of small artificial benchmarks. Your real applications are something
that other people won't be doing for you (unless you happen to know
other people who use the same applications).

> Please try to run the code on your on system.

No thanks. I don't think I want to contribute to spreading what I expect
to be dat aof questionable use. There are lots of people already in the
benchmarking business. I don't think this one will make a significant
positive contribution.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

dluego@yahoo.es

2006-01-28, 7:01 pm

Richard Maine wrote:
> <sergio_r@mail.com> wrote:
>
>
> Very low. My main comment is that doing a good job of benchmarking is a
> very difficult job. The complications are far too many and subtle to
> explain in a simple posting. If you don't understand them, you can get
> numbers that make no sense at all, and are off by orders of magnitude.
> People spend quite a long time learning about the subject.
>

Instead of a cumbersome test I always prefer a simple one,
though not always is possible to find one.

> It just isn't worth the time to try to even explain the issues here.
>
> You are better off to run real applications of interest to you instead
> of small artificial benchmarks. Your real applications are something
> that other people won't be doing for you (unless you happen to know
> other people who use the same applications).
>
>
> No thanks. I don't think I want to contribute to spreading what I expect
> to be dat aof questionable use.

Experience comes from practice and much of the advancement
of human kind thoughts comes from trial and error. And most
of us keep repeating things, even when thousands have done
the same experience over an over again, just to be sure
by our own means. A glance to any text book might convince
anyone.

Diego
Don't see the why of those numbers yet, but for sure something is
in there.

>There are lots of people already in the
> benchmarking business. I don't think this one will make a significant
> positive contribution.
>
> --
> Richard Maine | Good judgement comes from experience;
> email: last name at domain . net | experience comes from bad judgement.
> domain: summertriangle | -- Mark Twain

Alfredo Buttari

2006-01-30, 8:00 am

Ciao Sergio,
the linpack version that you used is not good because it deals with a
too small problem. If you read carefully the comments in its source you
find this:

c this program was updated on 10/12/92

Consider that in 1992 my actual laptop would have been in the top500.
The program that you wrote is even worse because it entirely fits in
cache and, thus, is not realistic; moreover, on the Opteron machine
there are a lot of registers and it may happen that all of your
variables fit in there. Finally this:

ifort -O -p -g Megaflop_d.f90

is not the right way to compile the code if you want to test
performance because "-g" adds extra info/istructions to your object
file. Try with at least "-O3" plus other architecture specific flags.

If you want a reliable measure you can try to install ATLAS
(http://www.netlib.org/atlas) and then time the matrix-vector product
on a big matrix.

Regards,
Alfredo Buttari

Richard E Maine

2006-01-30, 7:02 pm

<dluego@yahoo.es> wrote:

> Experience comes from practice and much of the advancement
> of human kind thoughts comes from trial and error. And most
> of us keep repeating things, even when thousands have done
> the same experience over an over again, just to be sure
> by our own means. A glance to any text book might convince
> anyone.

Yes. See my signature. And the purpose of that textbook is to give you
the benefit of other people's experience. If you had to do everything
over from scratch, you'd never make it up to, say, algebra. Doing
experiments yourself is indeed part of the learning process, but it does
not imply ignoring everything that everyone else has done. If you want
to ignore everything that everyone else has done, you need to throw away
those textbooks.

There *ARE* textbooks, or at least substantial monographs, on the
subject of benchmarking. You obviously haven't read them. That's not
meant to be insulting - most people haven't read them and have no need
to. But if you expect to come up with anything new and useful as a
benchmark, I'd advise reading them first. Otherwise, you *WILL* repeat
all the same mistakes that others made decades ago. It was 2 decades ago
that I heard an explanation of what were then well-known problems with
benchmarking. Your sample has some of those problems. That means you
have at least 2 decades of catching up to do, perhaps more. If you
expect to do that catchup without the help of reading what others have
done, you have a pretty big challenge.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links