Commit d994be39 authored by Jeff Hammond's avatar Jeff Hammond
Browse files

downloaded by hand from http://www.cs.virginia.edu/stream/FTP/Code/ on Feb. 4, 2015

parents
-------------------------------------------------------------------------
Revisions as of Thu, Jan 17, 2013 3:50:01 PM
Version 5.10 of stream.c has been released.
This version includes improved validation code and will automatically
use 64-bit array indices on 64-bit systems to allow very large arrays.
-------------------------------------------------------------------------
Revisions as of Thu Feb 19 08:16:57 CST 2009
Note that the codes in the "Versions" subdirectory should be
considered obsolete -- the versions of stream.c and stream.f
in this main directory include the OpenMP directives and structure
for creating "TUNED" versions.
Only the MPI version in the "Versions" subdirectory should be
of any interest, and I have not recently checked that version for
errors or compliance with the current versions of stream.c and
stream.f.
I added a simple Makefile to this directory. It works under Cygwin
on my Windows XP box (using gcc and g77).
A user suggested a sneaky trick for "mysecond.c" -- instead of using
the #ifdef UNDERSCORE to generate the function name that the Fortran
compiler expects, the new version simply defines both "mysecond()"
and "mysecond_()", so it should automagically link with most Fortran
compilers.
-------------------------------------------------------------------------
Revisions as of Wed Nov 17 09:15:37 CST 2004
The most recent "official" versions have been renamed "stream.f" and
"stream.c" -- all other versions have been moved to the "Versions"
subdirectory.
The "official" timer (was "second_wall.c") has been renamed "mysecond.c".
This is embedded in the C version ("stream.c"), but still needs to be
externally linked to the FORTRAN version ("stream.f").
-------------------------------------------------------------------------
Revisions as of Tue May 27 11:51:23 CDT 2003
Copyright and License info added to stream_d.f, stream_mpi.f, and
stream_tuned.f
-------------------------------------------------------------------------
Revisions as of Tue Apr 8 10:26:48 CDT 2003
I changed the name of the timer interface from "second" to "mysecond"
and removed the dummy argument in all versions of the source code (but
not the "Contrib" versions).
-------------------------------------------------------------------------
Revisions as of Mon Feb 25 06:48:14 CST 2002
Added an OpenMP version of stream_d.c, called stream_d_omp.c. This is
still not up to date with the Fortran version, which includes error
checking and advanced data flow to prevent overoptimization, but it is
a good start....
-------------------------------------------------------------------------
Revisions as of Tue Jun 4 16:31:31 EDT 1996
I have fixed an "off-by-one" error in the RMS time calculation in
stream_d.f. This was already corrected in stream_d.c. No results are
invalidated, since I use minimum time instead of RMS time anyway....
-------------------------------------------------------------------------
Revisions as of Fri Dec 8 14:49:56 EST 1995
I have renamed the timer routines to:
second_cpu.c
second_wall.c
second_cpu.f
All have a function interface named 'second' which returns a double
precision floating point number. It should be possible to link
second_wall.c with stream_d.f without too much trouble, though the
details will depend on your environment.
If anyone builds versions of these timers for machines running the
Macintosh O/S or DOS/Windows, I would appreciate getting a copy.
To clarify:
* For single-user machines, the wallclock timer is preferred.
* For parallel machines, the wallclock timer is required.
* For time-shared systems, the cpu timer is more reliable,
though less accurate.
-------------------------------------------------------------------------
Revisions as of Wed Oct 25 09:40:32 EDT 1995
(1) NOTICE to C users:
stream_d.c has been updated to version 4.0 (beta), and
should be functionally identical to stream_d.f
Two timers are provided --- second_cpu.c and second_wall.c
second_cpu.c measures cpu time, while second_wall.c measures
elapsed (real) time.
For single-user machines, the wallclock timer is preferred.
For parallel machines, the wallclock timer is required.
For time-shared systems, the cpu timer is more reliable,
though less accurate.
(2) cstream.c has been removed -- use stream_d.c
(3) stream_wall.f has been removed --- to do parallel aggregate
bandwidth runs, comment out the definition of FUNCTION SECOND
in stream_d.f and compile/link with second_wall.c
(4) stream_offset has been deprecated. It is still here
and usable, but stream_d.f is the "standard" version.
There are easy hooks in stream_d.f to change the
array offsets if you want to.
(5) The rules of the game are clarified as follows:
The reference case uses array sizes of 2,000,000 elements
and no additional offsets. I would like to see results
for this case.
But, you are free to use any array size and any offset
you want, provided that the arrays are each bigger than
the last-level of cache. The output will show me what
parameters you chose.
I expect that I will report just the best number, but
if there is a serious discrepancy between the reference
case and the "best" case, I reserve the right to report
both.
Of course, I also reserve the right to reject any results
that I do not trust....
--
John D. McCalpin, Ph.D.
john@mccalpin.com
*=======================================================================
*-----------------------------------------------------------------------
* Copyright 1991-2003: John D. McCalpin
*-----------------------------------------------------------------------
* License:
* 1. You are free to use this program and/or to redistribute
* this program.
* 2. You are free to modify this program for your own use,
* including commercial use, subject to the publication
* restrictions in item 3.
* 3. You are free to publish results obtained from running this
* program, or from works that you derive from this program,
* with the following limitations:
* 3a. In order to be referred to as "STREAM benchmark results",
* published results must be in conformance to the STREAM
* Run Rules, (briefly reviewed below) published at
* http://www.cs.virginia.edu/stream/ref.html
* and incorporated herein by reference.
* As the copyright holder, John McCalpin retains the
* right to determine conformity with the Run Rules.
* 3b. Results based on modified source code or on runs not in
* accordance with the STREAM Run Rules must be clearly
* labelled whenever they are published. Examples of
* proper labelling include:
* "tuned STREAM benchmark results"
* "based on a variant of the STREAM benchmark code"
* Other comparable, clear and reasonable labelling is
* acceptable.
* 3c. Submission of results to the STREAM benchmark web site
* is encouraged, but not required.
* 4. Use of this program or creation of derived works based on this
* program constitutes acceptance of these licensing restrictions.
* 5. Absolutely no warranty is expressed or implied.
*-----------------------------------------------------------------------
CC = gcc
CFLAGS = -O2
FF = g77
FFLAGS = -O2
all: stream_f.exe stream_c.exe
stream_f.exe: stream.f mysecond.o
$(CC) $(CFLAGS) -c mysecond.c
$(FF) $(FFLAGS) -c stream.f
$(FF) $(FFLAGS) stream.o mysecond.o -o stream_f.exe
stream_c.exe: stream.c
$(CC) $(CFLAGS) stream.c -o stream_c.exe
clean:
rm -f stream_f.exe stream_c.exe *.o
===============================================
STREAM is the de facto industry standard benchmark
for measuring sustained memory bandwidth.
Documentation for STREAM is on the web at:
http://www.cs.virginia.edu/stream/ref.html
===============================================
NEWS
===============================================
UPDATE: October 28 2014:
"stream_mpi.c" released in the Versions directory.
Based on Version 5.10 of stream.c, stream_mpi.c
brings the following new features:
* MPI implementation that *distributes* the arrays
across all MPI ranks. (The older Fortran version
of STREAM in MPI *replicates* the arrays across
all MPI ranks.)
* Data is allocated using "posix_memalign"
rather than using static arrays. Different
compiler flags may be needed for both portability
and optimization.
See the READ.ME file in the Versions directory
for more details.
* Error checking and timing done by all ranks and
gathered by rank 0 for processing and output.
* Timing code uses barriers to ensure correct
operation even when multiple MPI ranks run on
shared memory systems.
NOTE: MPI is not a preferred implementation for
STREAM, which is intended to measure memory
bandwidth in shared-memory systems. In stream_mpi,
the MPI calls are only used to properly synchronize
the timers (using MPI_Barrier) and to gather
timing and error data, so the performance should
scale linearly with the size of the cluster.
But it may be useful, and was an interesting
exercise to develop and debug.
===============================================
UPDATE: January 17 2013:
Version 5.10 of stream.c is finally available!
There are no changes to what is being measured, but
a number of long-awaited improvements have been made:
* Updated validation code does not suffer from
accumulated roundoff error for large arrays.
* Defining the preprocessor variable "VERBOSE"
when compiling will (1) cause the code to print the
measured average relative absolute error (rather than
simply printing "Solution Validates", and (2) print
the first 10 array entries with relative error exceeding
the error tolerance.
* Array index variables have been upgraded from
"int" to "ssize_t" to allow arrays with more
than 2 billion elements on 64-bit systems.
* Substantial improvements to the comments in
the source on how to configure/compile/run the
benchmark.
* The proprocessor variable controlling the array
size has been changed from "N" to "STREAM_ARRAY_SIZE".
* A new preprocessor variable "STREAM_TYPE" can be
used to override the data type from the default
"double" to "float".
This mechanism could also be used to change to
non-floating-point types, but several "printf"
statements would need to have their formats changed
to accomodate the modified data type.
* Some small changes in output, including printing
array sizes is GiB as well as MiB.
* Change to the default output format to print fewer
decimals for the bandwidth and more decimals for
the min/max/avg execution times.
===============================================
UPDATE: February 19 2009:
The most recent "official" versions have been renamed
"stream.f" and "stream.c" -- all other versions have
been moved to the "Versions" subdirectory and should be
considered obsolete.
The "official" timer (was "second_wall.c") has been
renamed "mysecond.c". This is embedded in the C version
("stream.c"), but still needs to be externally linked to
the FORTRAN version ("stream.f"). The new version defines
entry points both with and without trailing underscores,
so it *should* link automagically with any Fortran compiler.
===============================================
STREAM is a project of "Dr. Bandwidth":
John D. McCalpin, Ph.D.
john@mccalpin.com
===============================================
The STREAM web and ftp sites are currently hosted at
the Department of Computer Science at the University of
Virginia under the generous sponsorship of Professor Bill
Wulf and Professor Alan Batson.
===============================================
/* A gettimeofday routine to give access to the wall
clock timer on most UNIX-like systems.
This version defines two entry points -- with
and without appended underscores, so it *should*
automagically link with FORTRAN */
#include <sys/time.h>
double mysecond()
{
/* struct timeval { long tv_sec;
long tv_usec; };
struct timezone { int tz_minuteswest;
int tz_dsttime; }; */
struct timeval tp;
struct timezone tzp;
int i;
i = gettimeofday(&tp,&tzp);
return ( (double) tp.tv_sec + (double) tp.tv_usec * 1.e-6 );
}
double mysecond_() {return mysecond();}
This diff is collapsed.
*=======================================================================
* Program: STREAM
* Programmer: John D. McCalpin
* RCS Revision: $Id: stream.f,v 5.6 2005/10/04 00:20:48 mccalpin Exp mccalpin $
*-----------------------------------------------------------------------
* Copyright 1991-2003: John D. McCalpin
*-----------------------------------------------------------------------
* License:
* 1. You are free to use this program and/or to redistribute
* this program.
* 2. You are free to modify this program for your own use,
* including commercial use, subject to the publication
* restrictions in item 3.
* 3. You are free to publish results obtained from running this
* program, or from works that you derive from this program,
* with the following limitations:
* 3a. In order to be referred to as "STREAM benchmark results",
* published results must be in conformance to the STREAM
* Run Rules, (briefly reviewed below) published at
* http://www.cs.virginia.edu/stream/ref.html
* and incorporated herein by reference.
* As the copyright holder, John McCalpin retains the
* right to determine conformity with the Run Rules.
* 3b. Results based on modified source code or on runs not in
* accordance with the STREAM Run Rules must be clearly
* labelled whenever they are published. Examples of
* proper labelling include:
* "tuned STREAM benchmark results"
* "based on a variant of the STREAM benchmark code"
* Other comparable, clear and reasonable labelling is
* acceptable.
* 3c. Submission of results to the STREAM benchmark web site
* is encouraged, but not required.
* 4. Use of this program or creation of derived works based on this
* program constitutes acceptance of these licensing restrictions.
* 5. Absolutely no warranty is expressed or implied.
*-----------------------------------------------------------------------
* This program measures sustained memory transfer rates in MB/s for
* simple computational kernels coded in FORTRAN.
*
* The intent is to demonstrate the extent to which ordinary user
* code can exploit the main memory bandwidth of the system under
* test.
*=======================================================================
* The STREAM web page is at:
* http://www.streambench.org
*
* Most of the content is currently hosted at:
* http://www.cs.virginia.edu/stream/
*
* BRIEF INSTRUCTIONS:
* 0) See http://www.cs.virginia.edu/stream/ref.html for details
* 1) STREAM requires a timing function called mysecond().
* Several examples are provided in this directory.
* "CPU" timers are only allowed for uniprocessor runs.
* "Wall-clock" timers are required for all multiprocessor runs.
* 2) The STREAM array sizes must be set to size the test.
* The value "N" must be chosen so that each of the three
* arrays is at least 4x larger than the sum of all the last-
* level caches used in the run, or 1 million elements, which-
* ever is larger.
* ------------------------------------------------------------
* Note that you are free to use any array length and offset
* that makes each array 4x larger than the last-level cache.
* The intent is to determine the *best* sustainable bandwidth
* available with this simple coding. Of course, lower values
* are usually fairly easy to obtain on cached machines, but
* by keeping the test to the *best* results, the answers are
* easier to interpret.
* You may put the arrays in common or not, at your discretion.
* There is a commented-out COMMON statement below.
* Fortran90 "allocatable" arrays are fine, too.
* ------------------------------------------------------------
* 3) Compile the code with full optimization. Many compilers
* generate unreasonably bad code before the optimizer tightens
* things up. If the results are unreasonably good, on the
* other hand, the optimizer might be too smart for me
* Please let me know if this happens.
* 4) Mail the results to mccalpin@cs.virginia.edu
* Be sure to include:
* a) computer hardware model number and software revision
* b) the compiler flags
* c) all of the output from the test case.
* Please let me know if you do not want your name posted along
* with the submitted results.
* 5) See the web page for more comments about the run rules and
* about interpretation of the results.
*
* Thanks,
* Dr. Bandwidth
*=========================================================================
*
PROGRAM stream
* IMPLICIT NONE
C .. Parameters ..
INTEGER n,offset,ndim,ntimes
PARAMETER (n=2000000,offset=0,ndim=n+offset,ntimes=10)
C ..
C .. Local Scalars ..
DOUBLE PRECISION scalar,t
INTEGER j,k,nbpw,quantum
C ..
C .. Local Arrays ..
DOUBLE PRECISION maxtime(4),mintime(4),avgtime(4),
$ times(4,ntimes)
INTEGER bytes(4)
CHARACTER label(4)*11
C ..
C .. External Functions ..
DOUBLE PRECISION mysecond
INTEGER checktick,realsize
EXTERNAL mysecond,checktick,realsize
!$ INTEGER omp_get_num_threads
!$ EXTERNAL omp_get_num_threads
C ..
C .. Intrinsic Functions ..
C
INTRINSIC dble,max,min,nint,sqrt
C ..
C .. Arrays in Common ..
DOUBLE PRECISION a(ndim),b(ndim),c(ndim)
C ..
C .. Common blocks ..
* COMMON a,b,c
C ..
C .. Data statements ..
DATA avgtime/4*0.0D0/,mintime/4*1.0D+36/,maxtime/4*0.0D0/
DATA label/'Copy: ','Scale: ','Add: ',
$ 'Triad: '/
DATA bytes/2,2,3,3/
C ..
* --- SETUP --- determine precision and check timing ---
nbpw = realsize()
PRINT *,'----------------------------------------------'
PRINT *,'STREAM Version $Revision: 5.6 $'
PRINT *,'----------------------------------------------'
WRITE (*,FMT=9010) 'Array size = ',n
WRITE (*,FMT=9010) 'Offset = ',offset
WRITE (*,FMT=9020) 'The total memory requirement is ',
$ 3*nbpw*n/ (1024*1024),' MB'
WRITE (*,FMT=9030) 'You are running each test ',ntimes,' times'
WRITE (*,FMT=9030) '--'
WRITE (*,FMT=9030) 'The *best* time for each test is used'
WRITE (*,FMT=9030) '*EXCLUDING* the first and last iterations'
!$OMP PARALLEL
!$OMP MASTER
PRINT *,'----------------------------------------------'
!$ PRINT *,'Number of Threads = ',OMP_GET_NUM_THREADS()
!$OMP END MASTER
!$OMP END PARALLEL
PRINT *,'----------------------------------------------'
!$OMP PARALLEL
PRINT *,'Printing one line per active thread....'
!$OMP END PARALLEL
!$OMP PARALLEL DO
DO 10 j = 1,n
a(j) = 2.0d0
b(j) = 0.5D0
c(j) = 0.0D0
10 CONTINUE
t = mysecond()
!$OMP PARALLEL DO
DO 20 j = 1,n
a(j) = 0.5d0*a(j)
20 CONTINUE
t = mysecond() - t
PRINT *,'----------------------------------------------------'
quantum = checktick()
WRITE (*,FMT=9000)
$ 'Your clock granularity/precision appears to be ',quantum,
$ ' microseconds'
PRINT *,'----------------------------------------------------'
* --- MAIN LOOP --- repeat test cases NTIMES times ---
scalar = 0.5d0*a(1)
DO 70 k = 1,ntimes
t = mysecond()
a(1) = a(1) + t
!$OMP PARALLEL DO
DO 30 j = 1,n
c(j) = a(j)
30 CONTINUE
t = mysecond() - t
c(n) = c(n) + t
times(1,k) = t
t = mysecond()
c(1) = c(1) + t
!$OMP PARALLEL DO
DO 40 j = 1,n
b(j) = scalar*c(j)
40 CONTINUE
t = mysecond() - t
b(n) = b(n) + t
times(2,k) = t
t = mysecond()
a(1) = a(1) + t
!$OMP PARALLEL DO
DO 50 j = 1,n
c(j) = a(j) + b(j)
50 CONTINUE
t = mysecond() - t
c(n) = c(n) + t
times(3,k) = t
t = mysecond()
b(1) = b(1) + t
!$OMP PARALLEL DO
DO 60 j = 1,n
a(j) = b(j) + scalar*c(j)
60 CONTINUE
t = mysecond() - t
a(n) = a(n) + t
times(4,k) = t
70 CONTINUE
* --- SUMMARY ---
DO 90 k = 2,ntimes
DO 80 j = 1,4
avgtime(j) = avgtime(j) + times(j,k)
mintime(j) = min(mintime(j),times(j,k))
maxtime(j) = max(maxtime(j),times(j,k))
80 CONTINUE
90 CONTINUE
WRITE (*,FMT=9040)
DO 100 j = 1,4
avgtime(j) = avgtime(j)/dble(ntimes-1)
WRITE (*,FMT=9050) label(j),n*bytes(j)*nbpw/mintime(j)/1.0D6,
$ avgtime(j),mintime(j),maxtime(j)
100 CONTINUE
PRINT *,'----------------------------------------------------'
CALL checksums (a,b,c,n,ntimes)
PRINT *,'----------------------------------------------------'
9000 FORMAT (1x,a,i6,a)
9010 FORMAT (1x,a,i10)
9020 FORMAT (1x,a,i4,a)
9030 FORMAT (1x,a,i3,a,a)
9040 FORMAT ('Function',5x,'Rate (MB/s) Avg time Min time Max time'
$ )
9050 FORMAT (a,4 (f10.4,2x))
END
*-------------------------------------
* INTEGER FUNCTION dblesize()
*
* A semi-portable way to determine the precision of DOUBLE PRECISION
* in Fortran.
* Here used to guess how many bytes of storage a DOUBLE PRECISION
* number occupies.
*
INTEGER FUNCTION realsize()
* IMPLICIT NONE
C .. Local Scalars ..
DOUBLE PRECISION result,test
INTEGER j,ndigits
C ..
C .. Local Arrays ..
DOUBLE PRECISION ref(30)
C ..
C ..