New location for FTensor library
Hello, The FTensor library referenced at http://gcc.gnu.org/testing/testing-ftensor.html has moved. The new location is http://www.gps.caltech.edu/~walter/FTensor/index.html Cheers, Walter Landry wlan...@caltech.edu
Using up double diskspace for working copies (Was Re: Details forsvn test repository)
Daniel Berlin wrote: > On Fri, 2005-02-11 at 15:29 +, Joern RENNECKE wrote: > > Daniel Berlin wrote: > > > > > > > > > > >>Because svn keeps an extra pristine copy for checkouts, I'll have to use > > >>svn export for > > >>automatic regression tests. > > >> > > >> > > > > > >I don't understand why. > > >Is this because of the amount of space the working copy takes up? > > > > > > > > > > Yes. Sometimes stuff breaks and you don't notice it right away (E.g. > > because the > > feature is not automatically tested, or because of noise from other test > > failures). > > So it is useful to keep several month worth of test builds around. > > Doubling the > > amount of space taken up by this is not acceptable. > > Then you are correct, the only way to do what you want is export, or cp > excluding the .svn directories. > Do you consider this a show stopper, or are you willing to export your > trees? > Because if it's a show stopper, then so will be arch, monotone, or any > of our other replacements (they all either store the entire repo on your > disk, or have stuff in the working copy), and we will be stuck with cvs > until everyone is happy to use up double/whatever disk. This is not actually true. Both ArX and tla support hardlinking the tree against the extra pristine copy. In fact, for the use case given (lots of old test builds), some or all could be linked against each other. If you are worried about hard links because you might muck all of your different versions with careless editing, ArX at least will let you get away without a pristine tree. It then builds a new one when needed, and then deletes it. Regards, Walter Landry [EMAIL PROTECTED]
C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC
Hello Everyone, I thought you might be interested in some C++ expression template benchmarks I have done. http://www.wlandry.net/Projects/FTensor#Benchmarks I found that GCC optimized the expression template code better than unrolling expressions by hand. In fact, GCC was far, far better at optimizing code with expression templates than any other compiler. I ran the same benchmarks back in 2003, and GCC has improved quite a lot since then. Cheers, Walter Landry wlan...@caltech.edu
Re: C++ Expression Template Benchmarks for GCC/Clang/Intel/PGI/MSVC
Richard Guenther wrote: > On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote: >> Hello Everyone, >> >> I thought you might be interested in some C++ expression template >> benchmarks I have done. >> >> http://www.wlandry.net/Projects/FTensor#Benchmarks >> >> I found that GCC optimized the expression template code better than >> unrolling expressions by hand. In fact, GCC was far, far better at >> optimizing code with expression templates than any other compiler. I >> ran the same benchmarks back in 2003, and GCC has improved quite a lot >> since then. > > Heh, yeah - quite possibly because I myself was working with a POOMA > based CFD code during my PhD which made me start working on inproving > GCC for expression template code ;) It is btw interesting to try to enable > profile-feedback for the compilers - for some compilers you'll see that > the profile-generating executables are so slow as to be unusable (as they > seem to keep all calls of the expression templates). I got around to trying profile guided optimization. For GCC it did not make much difference, but for Intel it made a huge improvement for the expression template code. Of course, the training executable ran 20 times slower. But that was better than the Open64 compiler which was too slow for me to get results. I have added a section on PGO. http://www.wlandry.net/Projects/FTensor#PGO I also added results from Open64 and Pathscale's ENZO. Cheers, Walter Landry wlan...@caltech.edu
