GitXplorerGitXplorer
j

CppPerformanceBenchmarks

public
10 stars
0 forks
0 issues

Commits

List of commits on branch master.
Unverified
75cfe367f7fdad2f4628c971b69a4e7184d4e901

STL and naive container testsing

CChrisCoxArt committed 3 years ago
Unverified
12b2621f3e973f6f14467d80b25974e23094265d

major updates, unit tests (because some compilers and library routines have bugs)

CChrisCoxArt committed 3 years ago
Unverified
78345b2b7695908d9b4c68961668ad02030a176a

loop dependent branches, convolution example

CChrisCoxArt committed 3 years ago
Unverified
7858bdfbe0725978f2a64970b4dd691cdf698883

libcpp versions, clang support, few tweaks

CChrisCoxArt committed 3 years ago
Unverified
5c6d19b3d371673c65d6d9f1265c1ee661940d33

cleanup, bug fixes, comments, balancing

CChrisCoxArt committed 3 years ago
Unverified
7cb9ff663d7a6531c09bdcb74e8304c95b12dae4

update copyrights

CChrisCoxArt committed 3 years ago

README

The README file for this repository.

/* Copyright 2007-2008 Adobe Systems Incorporated Copyright 2018-2022 Chris Cox Distributed under the MIT License (see accompanying file LICENSE_1_0_0.txt or a copy at http://stlab.adobe.com/licenses.html ) */

/******************************************************************************/

Goals:

To help compiler vendors identify places where they may be able to improve the performance of the code they generate, or the libraries they supply.

To help developers understand the performance impact of using different data types, operations, and C++ language features with their target compilers and OSes.

/******************************************************************************/

Secondary goals:

To take performance problems found in real world code and turn them into benchmarks for compiler vendors and other developers to learn from.

Keep the benchmark portable to as many compilers and OSes as possible. This means keeping things simple and external dependencies minimal.

Not to use specialized optimization flags per test. No pragmas or other compiler directives are allowed in the source. All source files should use the same compilation flags. Use the common optimization flags (-O, -O1, -O2, -O3, or -Os). If another option improves optimization, then why isn't it on for -O3? If an optimization flag doesn't always improve performance, that is most likely a bug in the optimization code that needs to be fixed. In the real world, developers can't test all permutations of all optimization flags. They expect the standard flags to work.

/******************************************************************************/

**** A note to compiler vendors: Please match the idioms, not the instances. The benchmark code will be changing over time. And we do read your assembly output.

/******************************************************************************/

Building:

Unix users should be able to use "make all" to build and "make report" to generate the report. If you wish to use a different compiler, you can set that from the make command line, or edit the makefile.

Solaris users will need to use "gmake all" to build and "gmake report" to generate the report.

Windows users will need to make sure that the VC environment variables are set for their shell (command prompt), then use "nmake -f makefile.nt all" and "nmake -f makefile.nt report" from within that shell.

A CMakeLists.txt file is provided for convenience, but not tested as thoroughly as the makefiles. (thanks to Denis Glazachev)