You can subscribe to this list here.
1998 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(19) 
_{May}
(9) 
_{Jun}
(62) 
_{Jul}
(42) 
_{Aug}
(32) 
_{Sep}
(10) 
_{Oct}
(23) 
_{Nov}
(10) 
_{Dec}
(38) 

1999 
_{Jan}
(15) 
_{Feb}
(27) 
_{Mar}
(31) 
_{Apr}
(19) 
_{May}
(3) 
_{Jun}
(24) 
_{Jul}
(5) 
_{Aug}
(7) 
_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}
(2) 
2000 
_{Jan}
(6) 
_{Feb}
(1) 
_{Mar}
(3) 
_{Apr}

_{May}
(1) 
_{Jun}
(2) 
_{Jul}

_{Aug}
(6) 
_{Sep}

_{Oct}
(8) 
_{Nov}
(5) 
_{Dec}
(1) 
2001 
_{Jan}
(18) 
_{Feb}
(7) 
_{Mar}
(2) 
_{Apr}
(2) 
_{May}

_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}

_{Sep}
(1) 
_{Oct}
(2) 
_{Nov}

_{Dec}
(1) 
2002 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(2) 
_{Aug}

_{Sep}

_{Oct}
(34) 
_{Nov}
(7) 
_{Dec}
(5) 
2003 
_{Jan}
(13) 
_{Feb}
(4) 
_{Mar}

_{Apr}

_{May}
(3) 
_{Jun}
(1) 
_{Jul}
(3) 
_{Aug}

_{Sep}
(3) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}
(14) 
2004 
_{Jan}

_{Feb}
(1) 
_{Mar}
(2) 
_{Apr}
(8) 
_{May}
(13) 
_{Jun}

_{Jul}
(9) 
_{Aug}
(2) 
_{Sep}

_{Oct}
(2) 
_{Nov}

_{Dec}
(1) 
2005 
_{Jan}

_{Feb}
(3) 
_{Mar}

_{Apr}
(6) 
_{May}

_{Jun}
(9) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}
(2) 
_{Dec}

2006 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(2) 
_{Jul}

_{Aug}
(1) 
_{Sep}
(3) 
_{Oct}
(1) 
_{Nov}

_{Dec}

2007 
_{Jan}

_{Feb}
(2) 
_{Mar}
(1) 
_{Apr}
(2) 
_{May}
(1) 
_{Jun}
(3) 
_{Jul}
(7) 
_{Aug}
(5) 
_{Sep}
(2) 
_{Oct}
(3) 
_{Nov}
(4) 
_{Dec}
(3) 
2008 
_{Jan}
(1) 
_{Feb}
(7) 
_{Mar}
(3) 
_{Apr}
(1) 
_{May}
(6) 
_{Jun}
(4) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2009 
_{Jan}

_{Feb}
(5) 
_{Mar}
(2) 
_{Apr}
(1) 
_{May}
(1) 
_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(2) 
_{Dec}
(1) 
2010 
_{Jan}
(9) 
_{Feb}
(1) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(2) 
_{Aug}

_{Sep}
(2) 
_{Oct}

_{Nov}

_{Dec}
(3) 
2011 
_{Jan}

_{Feb}
(8) 
_{Mar}

_{Apr}

_{May}
(27) 
_{Jun}
(35) 
_{Jul}
(22) 
_{Aug}
(13) 
_{Sep}
(5) 
_{Oct}

_{Nov}

_{Dec}
(9) 
2012 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(6) 
_{May}
(4) 
_{Jun}
(7) 
_{Jul}
(1) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2013 
_{Jan}
(2) 
_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(1) 
_{Nov}

_{Dec}

2014 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}

_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(1) 
_{Dec}

S  M  T  W  T  F  S 






1

2

3

4

5

6

7

8

9

10

11

12
(1) 
13
(2) 
14

15
(1) 
16
(1) 
17

18

19

20

21

22

23
(1) 
24

25
(8) 
26

27
(1) 
28

29

30

31







From: Luc Bourhis <luc.bourhis@du...>  19990127 19:10:33

Allan Stokes [cbi] wrote: > > I'll do it if noone else volunteers. > > Luc Bourhis wrote: > >I did some researchs on the web and it appears that Makoto Matsumoto and > >Takuji Nishimura have created a new generator even better than their > >previous TT800 currently implemented in Blitz++ : see > >http://www.math.keio.ac.jp/~matumoto/emt.html > > The "cokus.c" version looks promising for incorporating into > Blitz. If anyone wants to repackage the C code as a blitzstyle > RNG, I'd be happy to fold it into the sources. Otherwise it'll > go on the TODO. > > http://www.math.keio.ac.jp/~matumoto/cokus.c > > Cheers, > Todd > warning : the main difference between the "cokus" version and the original version is the use of "*a" coding instead of "a[i]". We know that the interest of this trick is platform and compiler dependent. So, the implementer of this class should use the preprocessor flag introduced by Todd or Blitz++ array classes and their iterators. For example on my MacOS powerPC box with the compiler Codewarrior Pro 4, the speed difference between these two versions is very small, with a small advantage to the original one.  Luc Bourhis Center for Particle Theory University of Durham, UK  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Allan Stokes [cbi] <allan@st...>  19990125 23:04:14

I'll do it if noone else volunteers. Original Message From: ownerblitzdev@... [mailto:ownerblitzdev@...] On Behalf Of tveldhui Sent: Monday, January 25, 1999 11:35 AM To: blitzdev@... Subject: BZDEV: Re: RNGs Luc Bourhis wrote: >I did some researchs on the web and it appears that Makoto Matsumoto and >Takuji Nishimura have created a new generator even better than their >previous TT800 currently implemented in Blitz++ : see >http://www.math.keio.ac.jp/~matumoto/emt.html The "cokus.c" version looks promising for incorporating into Blitz. If anyone wants to repackage the C code as a blitzstyle RNG, I'd be happy to fold it into the sources. Otherwise it'll go on the TODO. http://www.math.keio.ac.jp/~matumoto/cokus.c Cheers, Todd  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Jason Riedy <ejr@ci...>  19990125 22:35:11

And tveldhui writes:  Uniform is adapted from DLARAN in LAPACK. It is finished and usable,  except that "randomize()" is not implemented. It has period 2^481. Another resource to examine: http://www.ncsa.uiuc.edu/Apps/CMP/RNG/RNGhome.html As far as I know, that's the only prepackaged set of random number generators that has been designed and tested for generating parallel random streams. Jason  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: tveldhui <tveldhui@ex...>  19990125 22:18:58

Luc Bourhis wrote: >I did some researchs on the web and it appears that Makoto Matsumoto and >Takuji Nishimura have created a new generator even better than their >previous TT800 currently implemented in Blitz++ : see >http://www.math.keio.ac.jp/~matumoto/emt.html The "cokus.c" version looks promising for incorporating into Blitz. If anyone wants to repackage the C code as a blitzstyle RNG, I'd be happy to fold it into the sources. Otherwise it'll go on the TODO. http://www.math.keio.ac.jp/~matumoto/cokus.c Cheers, Todd  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Luc Bourhis <Luc.B<ourhis@du...>  19990125 22:14:11

I did some researchs on the web and it appears that Makoto Matsumoto and Takuji Nishimura have created a new generator even better than their previous TT800 currently implemented in Blitz++ : see http://www.math.keio.ac.jp/~matumoto/emt.html  Luc Bourhis Center for Particle Theory University of Durham, UK  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: tveldhui <tveldhui@ex...>  19990125 22:00:51

Uniform is adapted from DLARAN in LAPACK. It is finished and usable, except that "randomize()" is not implemented. It has period 2^481. TT800 is a "twisted generalized feedback shift register (TGFSR)" RNG. It has period 2^8001. However, it currently only generates 32 bits of precision. The changes required to up this to 53 bits (ieee double) are minor (basically, just generate 2 random integers and use their bits to fill out to full precision). The comment in the code said that there were only 15 bits of precision, but this was wrong (I've changed it now). TT800 is fine if you are working with floats (only 24 bits of mantissa). I've bumped up the precision of TT800 to 64 bits (this change will appear in the next release). Also, randomize() in TT800 is not implemented. Oops, it is not implemented in Uniform either. > The random generator used by my Monte Carlo generates uniformly two > integers x and y and then builds a floatingpoint number z=(x+y/m1)/m0 > where m0 = 1664557 and m1 = 1048583. If z is a double and assuming that > integers have 32 bits, does this algorithm gives 53 significant bits for > the significand of z ? (Sorry to ask a question not directly related to > Blitz++) I notice that log2(m0 * m1) = 40.67. So if z is in the range [0,1) then there is no way for it can only have 40 bits of precision, not 53. I think. Cheers, Todd  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: John Poole <jfpoole@un...>  19990125 21:33:43

 Original Message  From: Luc Bourhis <Luc.Bourhis@...> To: <blitzdev@...> Sent: Monday, January 25, 1999 10:48 AM Subject: Re: BZDEV: a common performanceassessment framework >I have a Monte Carlo library written in FORTRAN that I want to port in >C++. Therefore, I need a generator of random doubles uniformly >distributed in [0,1[. Blitz++ provides two of them (classes Uniform ant >TT800) but there are several "NEEDS WORK" comments : so what are their >status ? If all you're looking for is a random number generator, you might want to look at the Mersenne Twister PRNG. Information about it can be found at http://www.math.keio.ac.jp/~matumoto/emt.html >From what I've heard it's a pretty solid PRNG, and there's code available on the page that generates uniform doubles over [0,1]. >(Sorry to ask a question not directly related to Blitz++) Sorry to suggest something other than Blitz++ :)  jfpoole  {} http://fluffy.ml.org/  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Rolf Mantel <mantel@ma...>  19990125 21:21:30

On Mon, 25 Jan 1999, Luc Bourhis wrote: > I have a Monte Carlo library written in FORTRAN that I want to port in > C++. Therefore, I need a generator of random doubles uniformly > distributed in [0,1[. Blitz++ provides two of them (classes Uniform ant > TT800) but there are several "NEEDS WORK" comments : so what are their > status ? In this context, it may be interesting to notice (and possibly use) the results of the recent threads on RNGs in sci.math.numanalysis, where first sombody famous in the RNG world posted C macros with fast RNGs, then somebody else posted a C++ version that, after compilation with egcs, was faster than the C macros. rolf Mantel  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Luc Bourhis <Luc.B<ourhis@du...>  19990125 20:25:04

I have a Monte Carlo library written in FORTRAN that I want to port in C++. Therefore, I need a generator of random doubles uniformly distributed in [0,1[. Blitz++ provides two of them (classes Uniform ant TT800) but there are several "NEEDS WORK" comments : so what are their status ? The random generator used by my Monte Carlo generates uniformly two integers x and y and then builds a floatingpoint number z=(x+y/m1)/m0 where m0 = 1664557 and m1 = 1048583. If z is a double and assuming that integers have 32 bits, does this algorithm gives 53 significant bits for the significand of z ? (Sorry to ask a question not directly related to Blitz++)  Luc Bourhis Center for Particle Theory University of Durham, UK  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Luc Bourhis <Luc.B<ourhis@du...>  19990123 07:42:45

What will be the influence on Blitz++ of the new sets of vector processing instructions that will be soon avalaible for Pentium (Katmai) and PowerPC (Altivec) ? Basically, the processor will be able in one cycle to add, substract, ... 128 Bits vectors (both for integer and floatingpoint on Altivec) : this means 16 double or 32 float or integer > this would be an implementation of choice for the classes TinyVector and like.  Luc Bourhis Center for Particle Theory University of Durham, UK  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: tveldhui <tveldhui@ex...>  19990116 23:29:00

The newer versions of the (free) ddd debugger can graphically plot 1D and 2D arrays, so in theory you could look at plots of field variables while debugging code: http://www.cs.tubs.de/softech/ddd/dddpicture.html It will even animate the plots as their values change. Cheers, Todd  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: tveldhui <tveldhui@ex...>  19990115 00:38:03

Array iterators are now working, and will appear in the next snapshot. Here's the relevant documentation for Array member functions: bf(verb(\ Array<T,N>::iterator begin(); Array<T,N>::const_iterator begin() const; )) These functions return STLstyle forward and input iterators, respectively, positioned at the first element of the array. Note that the array data is traversed in memory order (i.e. by rows for Cstyle arrays, and by columns for Fortranstyle arrays). The tt(Array<T,N>::const_iterator) has these methods: verb(\ const_iterator(const Array<T,N>&); T operator*() const; const T* [restrict] operator>() const; const_iterator& operator++(); void operator++(int); bool operator==(const const_iterator<T,N>&) const; bool operator!=(const const_iterator<T,N>&) const; const TinyVector<int,N>& position() const; ) Note that postfix ++ returns void (this is not STLcompliant, but is done for efficiency). The method tt(position()) returns a vector containing current index positions of the iterator. The tt(Array<T,N>::iterator) has the same methods as tt(const_iterator), with these exceptions: verb(\ iterator& operator++(); T& operator*(); T* [restrict] operator>(); ) The tt(iterator) type may be used to modify array elements. To obtain iterator positioned at the end of the array, use the tt(end()) methods. .... bf(verb(\ Array<T,N>::iterator end(); Array<T,N>::const_iterator end() const; )) Returns STLstyle forward and input iterators (respectively) for the array, positioned at the end of the array.  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Scott Haney <swhaney@la...>  19990113 20:10:50

>> /usr/bin/time eg++ c > /home/spike/pooma2.0/benchmarks/SimpleArray/atest.cpp \ >>o /home/spike/pooma2.0/benchmarks/SimpleArray/SOLARISEGCS/atest.o \ >> ftemplatedepth40 \ >>DNOPAssert DNOCTAssert O3 funrollloops fstrictaliasing \ >>I/home/spike/pooma2.0/src \ >>I/home/spike/pooma2.0/lib/SOLARISEGCS >> C C >>N w/o restrict w/ restrict CppTran PoomaII >>> > 10 35.24 52.64 6.754 4.881 >>> > 21 36.64 60.19 9.167 5.915 >>> > 46 34.53 36.24 8.36 6.723 >>> > 100 39.9 32.66 8.12 5.87 >>> > 215 39.66 35.78 7.812 5.556 >>> > 464 18.27 14.12 6.437 5.082 >>> > 1000 14.56 12.79 5.769 4.491 Alexander, Your results that Blitz++ meets or exceeds C performance are not a surprise. Nor is the the fact that Pooma doesn't perform as well as Blitz++. Pooma has a more general array/expression template implementation and evaluation mechanism (e.g., to support parallelism) than Blitz++ which, in turn, means increased overhead and difficulty in optimization. Also, of course, Todd has done an excellent job tuning Blitz++. Blitz's good performance at small vector sizes is particularly impressive. However, normally the difference is in the ballpark of 20% except at small vector sizes, not a factor of 510. "CppTran" above refers to writing the loops using explicit scalar indexing of the arrays. We typically see that the CppTran results track the C without restrict column pretty well. No reason why they shouldn't. However, that is clearly not the case above. I presume this is due to some EGCS code generation peculiarities on the Sun since I see better performance on the SGI (see below). On an SGI Origin 2K with KCC 3.3 I get: C C N w/o restrict w/ restrict CppTran PoomaII 10 15.00 15.63 16.30 6.70 21 30.62 21.76 38.46 11.33 46 30.40 23.76 27.74 13.31 100 21.16 20.88 19.35 14.16 215 20.83 20.62 17.63 14.41 464 11.96 12.32 11.65 9.76 1000 9.39 9.52 10.72 9.85 Note: this test is with a newer version of Pooma and it uses an updated version of the Benchmark class that exploits SGI's highspeed hardware timers. The numbers reported on all columns are the highest MFLOPs for 50 trials (e.g., the commandline is atest samples 50). With this many trials, I get fairly good reproducibility of the results above, even though the test is real short. Here, we see the CppTran results compare well with the C w/o restrict results and the Pooma results are slower by a lot at the low end and 1030% at the highend. These results aren't great, but they are not surprising compared to what I've seen in the past and they're better than the factors on the sun. With EGCS, again on the O2K, I get C C N w/o restrict w/ restrict CppTran PoomaII 10 14.42 15 12.1 1.769 21 28.03 16.21 14.01 2.912 46 24.05 22.8 20.09 2.941 100 16.27 16.05 14.49 2.98 215 13.63 13.64 11.72 2.953 464 10.67 10.58 9.617 2.696 1000 9.491 9.475 9.215 2.692 The CppTran results compare better than on the Sun, but the Pooma II results are even worse. The factor of 36 compared to KCC is a bit worse than results we've seen for other benchmarks, but generally consistent with previous EGCS results. Looking at the SimpleArray benchmark, I notice that the run() member function actually calls setInitialConditions(), which is generating overhead, but is not included in the MFLOP calculation. That is, we're really trying to time w += x + y + z; not filling w, x, y, and z with numbers and, in particular, not measuring the cost of the first touch of memory. Moving this call out of run() and into initialize() gives the following results for KCC: N w/o restrict w/ restrict CppTran PoomaII 10 46.88 41.67 75.00 17.05 21 78.75 82.69 91.88 53.35 46 60.11 61.51 54.35 53.26 100 72.53 69.57 62.81 60.58 215 75.63 70.09 62.17 59.67 464 24.91 25.71 25.48 23.13 1000 23.15 23.87 22.90 23.88 and for EGCS: C C N w/o restrict w/ restrict CppTran PoomaII 10 62.5 62.5 37.5 4.412 21 87.04 87.04 63.61 6.919 46 53.98 53.98 45.09 6.719 100 57.6 58.32 49.73 6.773 215 59.38 59.26 48.29 6.636 464 23.35 23.4 22.68 5.637 1000 21.39 21.39 21.01 5.633 As expected, the MFLOPs are better across the board. Also, for KCC, Pooma is much closer to CppTran and C, except at the small sizes where our overhead is getting us. EGCS is doing a better job with CppTran, but the Pooma results are still off by the large factor you reported. I agree that Pooma needs more aggressive compiler optimization than Blitz++ to get Clike results. It looks to me that KCC can supply these, but EGCS currently cannot. Specifically, my guess is that KCC more aggressively inlines. Now, admittedly, this realization doesn't doesn't do EGCS users interested in Pooma that much good right now. However, we're working with EGCS developers to improve the optimization and hope to see restrict plus better inlining implemented sometime this year. These enhancements would presumably benefit Blitz++ as well. Also, of course, we in the Pooma Team can work to try to make our code more palatable to compilers. Alexander and Todd, thanks for bringing this to our attention. Scott  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Scott W. Haney  email: swhaney@... Technical Staff Member, Pooma Team  phone: 5056675486 Los Alamos National Lab, CICACL, MS B287  fax: 5056654939 Los Alamos, NM 87545   blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: Alexander Samoilov <spike@Gambit.Msk.SU>  19990113 06:38:36

Hi folks! Happy New Year and best wishes! Recently I compared Blitz with Pooma II performance. At first glance Blitz outperforms Pooma II greatly, Blitz' performance is about the same as for C arrays version, but Pooma II performance is about ten times (one order) worser. Maybe something wrong have been done by me? It goes without saying that Blitz (thanks to author) has excellent implementation, but the difference is impressive. About compiler used for testing: EGCS snapshot 19990103, Blitz snapshot 19980903, PoomaII distribution from http://www.acl.lanl.gov/pooma/ Hardware: UltraSparcIII with 768MB RAM About test results: below are results for SimpleArray benchmark in PoomaII distribution. At first this benchmark build unmodified with these swithes: /usr/bin/time eg++ c /home/spike/pooma2.0/benchmarks/SimpleArray/atest.cpp \ o /home/spike/pooma2.0/benchmarks/SimpleArray/SOLARISEGCS/atest.o \ ftemplatedepth40 \ DNOPAssert DNOCTAssert O3 funrollloops fstrictaliasing \ I/home/spike/pooma2.0/src \ I/home/spike/pooma2.0/lib/SOLARISEGCS below are results: ./atest Benchmark  Running C w/o restrict Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. Running C w/ restrict Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. Running CppTran Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. Running PoomaII Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. C C N w/o restrict w/ restrict CppTran PoomaII 10 35.24 52.64 6.754 4.881 21 36.64 60.19 9.167 5.915 46 34.53 36.24 8.36 6.723 100 39.9 32.66 8.12 5.87 215 39.66 35.78 7.812 5.556 464 18.27 14.12 6.437 5.082 1000 14.56 12.79 5.769 4.491 And then PoomaII Array<...> class was substituted (to avoid name clashes not added but substituted) by Blitz Array<...> class, e.g. Blitz Array<...> was ported into PoomaII Benchmark class framework and built with the same switches. Here are the results: ./atest Benchmark  Running C w/o restrict Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. Running C w/ restrict Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. Running Blitz Implementation: N = 10... Correctness test value for N = 10 is 110. N = 21... Correctness test value for N = 21 is 231. N = 46... Correctness test value for N = 46 is 506. N = 100... Correctness test value for N = 100 is 1100. N = 215... Correctness test value for N = 215 is 2365. N = 464... Correctness test value for N = 464 is 5104. N = 1000... Correctness test value for N = 1000 is 11000. C C N w/o restrict w/ restrict Blitz 10 37.45 56.24 30.39 21 44.45 50.24 42.24 46 30.21 35.47 31.65 100 34.14 33.64 34.22 215 38.6 35.82 41.23 464 15.3 16.41 17.69 1000 15.19 15.34 13.85 What do you think about this? Best regards. Alexander.  blitzdev list  * To subscribe/unsubscribe: mail to majordomo@..., with "subscribe blitzdev" or "unsubscribe blitzdev" in the body of the message * Blitz++ web page: http://oonumerics.org/blitz/ 
From: tveldhui <tveldhui@ex...>  19990112 22:55:49

Hi Prem, The ".m" files are matlab (this is a bit lazy of me, but matlab generates nice plots). If you don't have access to matlab, you could cut and paste the table of numbers into a gnuplot file (there is one column for each implementation: Fortran, Blitz, valarray, etc.) The incache number is obtained from the peak performance (maximum Mflops). This usually corresponds to the point just before the endofcache dropoff. The outofcache figure is taken from the largest array size. Best, Todd > I was wondering how I could obtain the > timing information of a blitz benchmark program. > I see that it generates a '.m' file, is there > a preferred method for viewing the file? Can > 'gnuplot' read it? Also, how did you obtain the > incache and outofcache figures? > > Thank you, > Prem Anand. > 