{"id":13576342,"url":"https://github.com/nfinit/ansibench","last_synced_at":"2026-01-24T22:30:58.732Z","repository":{"id":43114061,"uuid":"160494264","full_name":"nfinit/ansibench","owner":"nfinit","description":"A selection of ANSI C benchmarks and programs useful as benchmarks","archived":false,"fork":false,"pushed_at":"2026-01-13T00:18:11.000Z","size":359,"stargazers_count":98,"open_issues_count":0,"forks_count":12,"subscribers_count":1,"default_branch":"master","last_synced_at":"2026-01-13T03:12:46.844Z","etag":null,"topics":["ansi-c","benchmark","benchmark-suite","benchmarking","c","performance","performance-analysis","performance-testing","performance-tuning"],"latest_commit_sha":null,"homepage":null,"language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nfinit.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-12-05T09:34:20.000Z","updated_at":"2026-01-13T00:18:15.000Z","dependencies_parsed_at":"2024-01-14T03:51:00.754Z","dependency_job_id":"958401d9-3dfc-4387-bf87-43e36017b614","html_url":"https://github.com/nfinit/ansibench","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/nfinit/ansibench","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nfinit%2Fansibench","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nfinit%2Fansibench/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nfinit%2Fansibench/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nfinit%2Fansibench/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nfinit","download_url":"https://codeload.github.com/nfinit/ansibench/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nfinit%2Fansibench/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28738944,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-24T22:12:27.248Z","status":"ssl_error","status_checked_at":"2026-01-24T22:12:10.529Z","response_time":89,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ansi-c","benchmark","benchmark-suite","benchmarking","c","performance","performance-analysis","performance-testing","performance-tuning"],"created_at":"2024-08-01T15:01:09.386Z","updated_at":"2026-01-24T22:30:58.703Z","avatar_url":"https://github.com/nfinit.png","language":"C","funding_links":[],"categories":["C"],"sub_categories":[],"readme":"[![](http://assets.amuniversal.com/a10595106d5401301d7c001dd8b71c47)](https://dilbert.com/strip/2004-12-25)\n\n# ANSI C (and mostly compatible) Benchmarks for Unix and Unix-like systems\n\n_Jump to [classic benchmarks](http://github.com/nfinit/ansibench#classic-benchmarks): \n          [LINPACK](http://github.com/nfinit/ansibench#linpack), \n          [STREAM](http://github.com/nfinit/ansibench#stream),\n          [Whetstone](http://github.com/nfinit/ansibench#whetstone),\n          [Dhrystone](http://github.com/nfinit/ansibench#dhrystone),\n          [NBench](http://github.com/nfinit/ansibench#nbench)_\n          \n_Jump to [modern benchmarks](http://github.com/nfinit/ansibench#modern-benchmarks):\n          [CoreMark](http://github.com/nfinit/ansibench#coremark),\n          [HINT](http://github.com/nfinit/ansibench#hint)_\n\nThis repository packages a selection of C program sources useful for\nbenchmarking a wide variety of systems and compilers, including a number of\nclassic, industry-standard benchmarks as well as some select programs that\ncan be used as benchmarks. Sources in this package generally target ANSI C \n(ISO C90) compliance to maximize compatibility, though most benchmarks are\nstill in the process of being refactored to that standard. \n\nSources in this package are at a minimum tested with GCC on Linux and a strict\nwarning set. They are (variably) further tested with GCC on Mac OS, OpenBSD,\nAIX, HP-UX and other systems, as well as proprietary compilers such as IBM\nVisualAge C and HP C.\n\nAlways remember that a benchmark is ultimately only accurate for evaluating \na system's performance on that very specific set of operations which don't \nalways reflect its typical workload, and thus only paints a partial picture of\nyour system's overall capabilities. Many of the programs included in this\npackage are single-threaded and very CPU-focused, and won't tell you as much\nabout your system's memory, disk, or I/O capabilities among other critical\narchitectural features that may allow it to pull ahead of supposedly faster\nsystems in many use cases.\n\nNonetheless, these programs are still easy and useful tools for evaluating \ncompilers and giving you a *rough* idea of how your system performs and \nhow it may compare to others.\n\n## Building, configuring and running benchmarks\n\nEach benchmark in this package resides in its own directory and can be quickly\nbuilt by issuing the `make` command, or built and run with default parameters\nusing `make run`. ANSIbench makefiles by default expect the GNU C Compiler to\nbe used, though this can be changed using the `cc` and `opt` directives.\n\nMost benchmarks support run parameters whose defaults can be seen at the top\nof each makefile. The most common parameter is `n`, which is used to specify\narray sizes or numbers of loops to iterate through in most benchmarks. \n\nSome benchmarks may require platform-specific accomodations that the benchmark\nitself can't determine automatically. These can be specified using the \n`platform` parameter, presets of which are found in the `mk` directory if\napplicable.\n\n### Optimizing benchmarks\n\nBy default, benchmarks attempt to build using GCC with second-level \noptimizations, but alternative compilers and optimizations can be specified \nusing the `cc` and `opt` directives, for example in this attempt to build\nCoreMark on an HP-UX system with HP C:\n```\nmake cc=hp-c opt=o4\n```\nDirective values refer to files or directories within the `mk` directory,\nwhich allow for more modular, editor-free benchmark configuration and quicker\nvalidation of multiple compilers and optimization levels.\n\nIf a specific optimization flag you are looking for is not present in a default\noptimization preset, check your compiler's corresponding `xflags` directory or\nspecify it directly at build time using the `XCFLAGS` parameter.\n\n## Packaged benchmarks\n\n### Classic Benchmarks\n\nMature, venerable industry-standard benchmarks designed for use on a wide\nvariety of systems and architectures\n\n---------------------------------------------------------------------------\n#### LINPACK\n\nFirst introduced in 1979, the LINPACK benchmark measures a system's \nfloating-point math capabilities by solving a dense system of linear \nequations. LINPACK remains an industry standard particularly in\nsupercomputing, where it is used to build the TOP500 list of the world's\nfastest computers. LINPACK measures system performance in terms of Floating\nPoint Operations per Second, or FLOPS. Most small systems today typically \noperate on the order of megaFLOPS, gigaFLOPS and teraFLOPS, while\nsupercomputers often operate in the petaFLOPS range.\n\nLINPACK evaluates performance with both single-precision (32-bit) and\ndouble-precision (64-bit) floating-point numbers, usually selectable\nat compile time. Single-precision values are most frequently used in \n\"everyday\" desktop computing applications where precision and \nutmost accuracy are not as necessary, while double-precision values\nare more frequently used in scientific and technical applications where\nminimal approximation is preferable. Many LINPACK variants default to\ndouble-precision (including the one in this package) because of the\nbenchmark's significance in high-performance computing.\n\nThis version of LINPACK is a C translation of the original FORTRAN version\nfirst written in 1988 by Bonnie Toy and later updated in 1993 by Will \nMenninger, it most notably allows for user-definable matrix sizes and\naverages rolled and unrolled performance in its report. The original\nsource can be found [here](http://www.netlib.org/benchmark/linpackc.new).\n\nThis source has been slightly modified in this package to make it easier\nto automate and execute from scripts. It can now take the matrix size as\nan argument and the output has changed slightly for a cleaner look.\n\n##### Run notes\n\nLINPACK has a single parameter `n` which can be passed to it when running \nwith `make run`, this corresponds to the matrix size. Typical matrices \nused with LINPACK are of order 100x100 or 1000x1000, though any value of \n`n` can be passed in, within reason. LINPACK can also be run without the\nmakefile by simply running the executable, which will then ask for `n` if\nit wasn't supplied as the first argument.\n\nThe single LINPACK source file is used to build two executables, `linpacksp` \nfor evaluating single-precision performance and `linpackdp` for evaluating \ndouble-precision performance. Both are identical in functionality.\n\nRunning LINPACK with `make run` will run both the single-precision and \ndouble-precision versions of the benchmark.\n\n##### Building and running LINPACK in non-Unix environments\n\n###### CodeWarrior on Macintosh\n\nThe LINPACK sources included in this package build easily under CodeWarrior on\nthe Classic Macintosh with no modification required, using the SIOUX (Simple\nInput and Output User eXchange) library to provide a text console interface for\ninput and output.\n\nBecause CodeWarrior cannot utilize the included makefiles, the source files\nmust be manually included in a CodeWarrior project with appropriate build\ntargets specified for single and double-precision executables. Because LINPACK\nbuilds by default in double-precision mode, the symbol `SP` must be defined at\ncompile time to override this, typically accomplished using a command-line\noption such as `-DSP` when calling GCC, for example.\n\nRather than using command-line options to define symbols prior to compilation,\nCodeWarrior instead utilizes \"prefix files,\" and to this end a simple header\nfile `sp.h` is included in the LINPACK `utils` directory to define `SP` at\ncompile time. **Simply include `sp.h` in your project and reference it as a\nprefix file in your build target to build a single-precision executable.**\nYou'll likely need to include it in all of your build targets to avoid errors;\ndouble-precision builds simply won't need to reference it.\n\nAfter setting up your build targets, LINPACK can be easily built and run\ndirectly from the CodeWarrior IDE. \n\n##### [LINPACK results](http://github.com/nfinit/ansibench/wiki/LINPACK-results) \n---------------------------------------------------------------------------\n#### STREAM\n\nSTREAM is a synthetic memory benchmark first developed in 1991 by \nDr. John McCalpin at the University of Delaware's College of Marine Studies.\nIt is described by McCalpin as \"an extremely simplified representation of the\nlow-compute-intensity, long-vector operations characteristic of ocean\ncirculation models\" and has since become a standard for measuring\nmemory performance on various computer systems.\n\nSTREAM measures memory performance using four separately timed kernels \ncorresponding to copy, scale, add and \"triad\" operations, with the latter \nkernel (a combination of the three others) usually cited for in-general \ncomparison. STREAM results are often used alongside LINPACK when evaluating\nsupercomputer performance, as memory bandwidth is often even more important\nthan raw processor speed when working with the large data sets typical in\nsupercomputing workloads.\n\nThis is the \"official\" C version of STREAM which can be found on the\n[STREAM website](http://www.cs.virginia.edu/stream/). The source has been very\nminimally modified for inclusion in this package mostly to make it acceptable\nto an ANSI C compiler and easier to automate using a makefile. Only comments,\nprint statement formatting and some macro definitions have been modified\n(to allow the default array size to still be properly set in the event of an \nempty STREAM array size definition argument from a non-GNU makefile) with the\ndeprecated Time Zone structure removed in the `mysecond()` function.\nBecause of the minimal nature of these modifications, this version of STREAM\nshould still be compliant with the official \n[run rules](http://www.cs.virginia.edu/stream/ref.html#runrules).\n\n##### Run notes \n\nSTREAM by default operates on an array of 10,000,000 elements, which may be\ntoo small or too large for some systems. In a similar manner to LINPACK, the\narray size can be configured from the makefile using the parameter `n`. Unlike\nLINPACK, this parameter is defined at compile-time, and STREAM will need to be\nrecompiled to use a different array size.\n\nIt is recommended to specify an array size at least 4 times the size of your\nsystem's processor caches in order to ensure that the system memory is\nactually what is being benchmarked. The default `n`=10,000,000 parameter\nshould be acceptable for caches up to 4 MiB, but many modern systems are now\nshipping with 8 MiB of cache and beyond, meaning `n` will need to be larger\nfor a result that properly reflects memory performance.\n\nSTREAM by default is built expecting OpenMP support on the target system. This\ncan be disabled simply by specifying `mp=` to wipe the `mp` parameter when\nrunning the makefile. `-DDIS_OPENMP` may also need to be passed in through \n`XCFLAGS`.\n\nHP-UX with HP C requires certain preprocessor macros defined to compile STREAM\nsuccessfully which are included as platform directives `hp-ux` and `hp-ux-mp`\ndepending on whether or not OpenMP is being used. `mp` will need to be cleared\nif using the former.\n\n##### [STREAM results](http://github.com/nfinit/ansibench/wiki/STREAM-results)\n---------------------------------------------------------------------------\n#### Whetstone\n\nThe Whetstone benchmark is a synthetic benchmark that primarily measures \na computer's floating-point performance. Originally written in ALGOL 60 in 1972 \nby Harold Curnow of the Technical Support Unit of the United Kingdom's \nDepartment of Trade and Industry, it was one of the first general-prupose\nbenchmarks to set industry standards for evaluating computing performance.\n\nThe Whetstone benchmark is based on prior work by Brian Wichmann of the UK's\nNational Physical Laboratory (NPL) who collected statistics from a modified\nversion of the \"Whetstone\" ALGOL compiler running on an [English Electric KDF9\ncomputer](https://en.wikipedia.org/wiki/English_Electric_KDF9) at the NPL \nand used the data to build a set of 42 simple statements that could be used \nto evaluate the efficiency of other compilers and processor performance. \n\nWhetstone speed ratings are measured in Whetstone Instructions Per Second \n(WIPS), and most early versions of the benchmark output ratings in KWIPS, \nwhile most newer versions (including this one) produce ratings in MWIPS. \nAlthough Whetstone performs a general mix of calculations, most of them \nare still overwhelmingly floating-point heavy, and because only a small \namount of data is referenced, architectural factors such as the performance \nof the memory subsystem are barely if at all evaluated, especially if the \nprocessor being evaluated has large enough caches.\n\nThe Whetstone version included in this package is the \"updated\" C translation\nfound on the [Netlib repository](http://www.netlib.org/benchmark/whetstone.c)\nwith minimal modification, mostly just to printed output. This version was\ntranslated directly from the original ALGOL 60 version of the benchmark, and\nhas output similar to the \n[FORTRAN version](http://www.netlib.org/benchmark/whetstoned).\n\n##### Run notes\n\nBy default, Whetstone is configured to loop 1,000,000 times, which is often\ntoo little for newer systems. Change the loop count by specifying the `n`\nparameter with `make run` or running the binary directly with the loop count\nas the first argument.\n\nWhetstone can also loop continuously with the `-c` flag, which is not\nused by the makefile.\n\nIt's always recommended to build Whetstone with `PRINTOUT` defined for proper\noutput, this ensures that optimizing compilers do not over-optimize the\nbenchmark by omitting computations whose end result are never shown to the\nuser.\n\n##### [Whetstone results](http://github.com/nfinit/ansibench/wiki/Whetstone-results)\n---------------------------------------------------------------------------\n#### Dhrystone\n\nA pun on the name of the floating-point focused \"Whetstone\" benchmark, the\nDhrystone benchmark is, like Whetstone, a synthetic benchmark derived from\nstatistical analysis with the goal of representing an \"average\" program.\nDhrystone is unlike Whetstone in that it focuses entirely on integer arithmetic,\nmaking it more relevant to small systems and typical computing use cases \nin general than the more scientific and technically-oriented Whetstone.\n\nDhrystone was originally written in the Ada programming language by Reinhold P. \nWeicker of Siemens Nixdorf Information Systems in 1984, based on analysis of a\nnumber of programs in numerous languages. Weicker characterized these programs\nbased on common constructs such as procedure calls and variable assignments, and\nused this data to write a benchmark corresponding to a \"representative mix\" of\nthese features, similar to the design process of the Whetstone benchmark over \na decade earlier.\n\nDhrystone was first ported to C by Rick Richardson of PC Research, Inc. and \ndistributed via Usenet. Richardson and Weicker later collaborated on subsequent\nversions of the benchmark, their work mostly centered around standardizing the\nAda, C and Pascal versions as well as out-smarting increasingly intelligent\noptimizing compilers.\n\nDhrystone speed ratings are measured in Dhrystones Per Second, corresponding to\nthe number of times the main Dhrystone loop iterates in a single second. This\nquantity is often further refined into \"VAX MIPS,\" corresponding to a multiple\nof the [DEC VAX-11/780 superminicomputer](http://en.wikipedia.org/wiki/VAX-11)'s\nreported score of 1,757 Dhrystones per second.\n\nWhile Dhrystone attempts to emulate the \"typical\" program, it is nonetheless\nunsuitable for use as a sole means of benchmarking a system for a number of\nreasons, many cited by the authors themselves:\n* Dhrystone only evaluates processor integer performance, it does not evaluate\n  other significant architectural components such as memory/disk subsystems, or\n  perform any I/O operations. Dhrystone also makes limited use of operating\n  system calls.\n* Dhrystone is an extremely small benchmark operating on an extremely small\n  data set, both of which can easily fit completely into extremely fast modern\n  processor caches.  Most \"typical\" programs are too large to completely fit in\n  cache, and often operate on data stored in memory or on disk as well as \n  cached, frequently accessed data.\n* Dhrystone's integer/system focus may paint a skewed picture of systems\n  designed with an emphasis on scientific and technical computing where\n  floating-point math is more prevalent.\n* The C version of Dhrystone places increased emphasis on string operations\n  compared to the reference benchmarks, due to C's lack of a built-in string\n  data type.\n\nWith this in mind, it's important to treat Dhrystone results as only a rough\noverview of a system processor's integer performance under very ideal\nconditions, and combine it with other benchmarks when evaluating a system as a\nwhole. Dhrystone nonetheless is still widely used in the industry, especially\nin embedded systems where VAX MIPS is\nstill often cited in marketing literature.\n\nA modern alternative to Dhrystone that attempts to provide solutions to many of its\nshortcomings is the EEMBC's [CoreMark](http://github.com/nfinit/ansibench#coremark)\nbenchmark, which is also included in this package and recommended for use especially\nwith newer systems where Dhrystone's reporting can be quite inaccurate.\n\nThe Dhrystone version included in this package is the \n[most widely used version (2.1)](http://www.netlib.org/benchmark/dhry-c) \nwith some modifications mostly to make it acceptable to ANSI-compliant C compilers \nas well as automation improvements such as the ability to take in the number of \niterations as an argument at execution time. It has also been modified to compute\nand report the VAX MIPS rating from the benchmark result and display it after the\nDhrystones per second rating.\n\nBecause the C Dhrystone translation is still mostly written in K\u0026R-style C, it\ngenerates a lot of warnings when compiled with the package's standard flag set.\nThe whetstone source will eventually be revised to bring it into compliance\nwith ANSI C.\n\n##### Run notes\n\nBy default, the Dhrystone benchmark loops 10,000,000 times. This can be \nincreased or decreased to better evaluate a given system by setting the \n`n` parameter when running the benchmark through the makefile, or \nby specifying the number of loops when running the executable directly. \n\nDhrystone requires the parameter `HZ` to be defined at compile time, which\ncorresponds to the granularity of the timing function. This is typically 100\non most newer systems and is the default value, however it can still vary and\nshould be confirmed before running the benchmark. If you're working in a POSIX\nenvironment, the script `gethz.sh` will compile and run a simple program that\ndetermines the value of the `_SC_CLK_TCK` parameter which corresponds to the\nnumber of clock \"ticks\" per second as configured in the kernel. This\ninformation can also be retrieved by issuing `getconf _SC_CLK_TCK` (or `getconf\nCLK_TCK` if `_SC_CLK_TCK` is unsupported) and passing the value into make using\nthe `hz` parameter. An example build and run operation might be: `make run\nn=50000000 hz=120 occ=gcc-ofast` to build and run Dhrystone on a GNU/Linux\nsystem with maximal optimization and a kernel configured for 120 clock \"ticks\"\nper second.\n\nThe timing function to use can also be passed at compile time, by default\nDhrystone will be built to use wall clock time with `time()` specified by the\n`-DTIME` flag, but it can also be configured to use `times()` for process time\nwith `-DTIMES`.  You can configure Dhrystone to be built with the `times()`\nfunction for timing by including `time=TIMES` in your `make` command.\n\nThe makefile is configured to build and run Dhrystone both with and without\nregister variables, meaning that Dhrystone will assign some variables to\ndedicated processor registers when possible for faster access than from cache\nor memory.\n\n##### [Dhrystone results](http://github.com/nfinit/ansibench/wiki/Dhrystone-results)\n---------------------------------------------------------------------------\n#### NBench\n\nFormerly known as BYTEmark or the BYTE Native Mode Benchmarks, NBench is a\nself-contained suite of synthetic benchmarks designed to test the capabilities\nof a computer's CPU, FPU and memory subsystem, scoring them using an index\nbased on a Dell Pentium 90 running MS-DOS or an AMD K6-2/233 running Linux.\n\nNBench was ported to Linux by Uwe F. Mayer (who still hosts the sources on [his\nUniversity of Utah website](http://www.math.utah.edu/~mayer/linux/bmark.html))\nin late 1996 based on BYTEmark 2.0 which was largedly developed by Rick Grehan,\na significant contributor to BYTE's many benchmarking efforts, who started work\non that version in 1994, describing it in BYTE's March 1995 issue.\n\nBYTEmark 2.0 and NBench are described as an \"algorithm-based\" suite that, while\nstill synthetic, is far less so than its predecessors, evaluating a system using\na suite of small program kernels as opposed to simple repetitive sequences of\nsingle or similarly few instructions. In total, NBench evaluates ten algorithms:\n\n* **Numeric Sort**: Measures the time needed to sort a one-dimensional array\n  of signed long integers using a heapsort algorithm. Chosen as a general-purpose\n  processor performance test due to its common and fundamental nature.\n* **String Sort**: Similar to the above, but uses a heapsort algorithm to sort\n  strings of abritrary content and length rather than integers.\n* **Bitfield**: Evaluates a system's ability to manipulate single bits with\n  an algorithm best described as a simulation of how an operating system might\n  keep track of disk block allocation using a bit map in memory.\n* **Emulated Floating-Point**: A small floating point emulation software package\n  that performs fundamental arithmetic; addition, subtraction, multiplication and\n  division without the use of a hardware floating-point unit.\n* **Fourier Coefficients**: Exercises a system's trigonometric abilities by\n  calculating the first *n* Fourier coefficients for a cyclic waveform constructed\n  using a logarithmic function.\n* **Assignment Algorithm**: Performs a variety of operations on two-dimensional\n  integer arrays by solving a simulated resource allocation problem.\n* **Huffman Compression**: Uses the Huffman compression algorithm to test a system's\n  competence at a mixture of text processing, complex data management and bit\n  manipulation.\n* **IDEA Encryption**: Measures the ability of a system to encrpyt and decrypt data\n  using the International Data Encryption Algorithm (IDEA), operating on groups of\n  16 bits at a time.\n* **Neural Net**: Teaches a simple back-propagation neural network (of the type\n  originally presented by Maureen Caudill in the October 1991 BYTE article \"Expert \n  Networks\") to recognize various ASCII characters. Primarily a floating-point\n  benchmark making heavy use of the exponential function.\n* **LU Decomposition**: Uses the LU Decomposition algorithm to solve systems of\n  linear equations and measure a system's fundamental floating-point capabilities.\n\nThere are caveats to this suite noted by Grehan in his 1995 article,\nmost notably the extremely small size of the tests - typically less than\n16 KiB. This means that NBench tests will often fit completely in a CPU's fast\ncache memories and thus their scores will represent ideal scenarios rather\nthan the average case, where complex programs often do not fully fit within\ncache.\n\nNBench was designed to be highly portable and builds on most systems with ease.\nThe version included in this package sports no modifications from Mayer's standard\ndistribution, differing only in the way the files are structured and the way the\nbenchmark is built: dynamically linked rather than statically linked due to some\nproblems with the standard build method on certain (mostly embedded) systems.\n\n##### Run notes \n\nNBench determines workloads dynamically requires no parameters from the user, \nthus you can simply build and run it immediately with `make run` from its \ndirectory.\n\n##### [NBench results](http://github.com/nfinit/ansibench/wiki/NBench-results) \n---------------------------------------------------------------------------\n### Modern Benchmarks\n\nModern industry-standard (and upcoming) benchmarks that attempt to solve\nthe various problems of or otherwise improve on their \"classic\" predecessors\n\n---------------------------------------------------------------------------\n#### CoreMark\n\nThe [CoreMark](https://www.eembc.org/coremark/) benchmark is a product of \nthe [Embedded Microprocessor Benchmark Consortium](https://www.eembc.org/),\nand aims to provide a modern alternative to the venerable integer-focused\n[Dhrystone](http://github.com/nfinit/ansibench#dhrystone) benchmark while\nanswering many of its shortcomings and improving its relevance primarily in\nthe area of low-power embedded systems, where Dhrystone is still predominantly\nused by vendors to provide rough performance estimates and means of comparison\nwith competing products.\n\nCoreMark was primarily developed by Shay Gal-On, then the director of software\nengineering at the EEMBC, as the EEMBC's first freely available standard \nbenchmark. CoreMark answers a number of problems with the original synthetic\nDhrystone benchmark with an entirely new design built around a number of\ncommonly used algorithms in microcontrollers and microprocessors alike,\nincluding list procesing, matrix manipulation, state machines and cyclic\nredundancy checks, as opposed to Dhrystone's purely synthetic, statistically\nderived loop that intends to simulate the \"average\" program. In addition to\na more real-world focus, CoreMark also does not call any external libraries\nin timed sections of the benchmark, so as to most effectively report on the\nperformance of the processor itself rather than the quality of the target \nsystem's standard libraries. Lastly, CoreMark is also designed more defensively\nagainst compiler optimizations than Dhrystone, to keep any actual computation\nfrom being \"optimized away\" at compile time, an oft-cited (and exploited)\nproblem with Dhrystone.\n\nLike Dhrystone, CoreMark reports its scores in terms of the number of benchmark\niterations per second.\n\nCoreMark is freely distributed by the EEMBC under the Apache 2.0 license and is\navailable to any interested party through the EEMBC's \n[official GitHub repository](https://github.com/eembc/coremark). The source\nfiles included in this package are mostly identical to those in the official\nrepository, but with some modifications to address compiler warnings:\n- Prototypes for seed argument handling have been moved from `core_main.c`\n  to `coremark.h` as the functions are called from multiple files \n- Missing function prototypes have been added to `core_list_join.c`\n- Definition of `check_data_types()` in `core_util.c` has been changed to\n  `check_data_types(void)`\n\nThough these changes are minimal and likely don't impact benchmark performance,\nit's still recommended to use the official repository for any official\nvalidation and score submission purposes due mostly to differences in building,\ndirectory structure, documentation and reporting arising from this package's\nexclusive focus on convenient personal and non-marketing usage.\n\n##### Run notes\n\nBy default, the makefile is configured to build and run CoreMark with the seeds\n0x0, 0x0 and 0x66 and 20,000 iterations, the latter of which can be tweaked\nwith the `n` parameter. CoreMark is required to run for at least 10 seconds in\norder to obtain a valid result.\n\nCoreMark is capable of multi-threaded execution by setting the `threads`\nparameter. By default, an EEMBC sample POSIX Threads implementation will be\nused, but a `fork()`-based implementation is also available. Lines for both are\nprovided in the CoreMark makefile. \n\n##### [ANSIbench CoreMark results](http://github.com/nfinit/ansibench/wiki/CoreMark-results)\n##### [Official EEMBC CoreMark results](https://www.eembc.org/coremark/scores.php) \n---------------------------------------------------------------------------\n#### HINT\n\nAlthough released in 1994, the Hierarchical INTegration (HINT) benchmark is\nconsidered a \"modern\" benchmark due to its novel and innovative design, which\nevaluates a computer system's performance in terms of the *quality* of a\nsolution, rather than simply the overall amount of time it took to compute it,\nand in fact is built around a solving problem that has no exact, final\nsolution, something which accurately reflects many problems encountered in the\nworld of high-performance computing, where models are continuously refined and\nimproved to gain more and more resolution, rather than solved outright to\nobtain some exact quantity or output.\n\nHINT was designed by Dr. John Gustafson and Quinn Snell of the US DoE's Ames\nLaboratory, taking some ideas from the earlier SLALOM benchmark but with an\nentirely new fundamental concept based on the measurement of Quality\nImprovements Per Second (QUIPS) on a problem not of fixed size nor fixed time.\nHINT derives this metric from the following task, described in [this\npublication](http://www.johngustafson.net/images/Hint.pdf) on Gustafson's\nwebsite:\n\n\u003eUse interval subdivision to find rational bounds on the area in the xy plane for which x ranges from 0 to 1 and y ranges from 0 to (1- x) / (1+ x). Subdivide x and y ranges into an integer power of two equal subintervals and count the squares thus defined that are completely inside the area (lower bound) or completely contain the area (upper bound). Use the knowledge that the function (1- x) / (1+ x) is monotone decreasing, so the upper bound comes from the left function value and the lower bound from the right function value on any subinterval. No other knowledge about the function may be used. The objective is to obtain the highest quality answer in the least time, for as large a range of times as possible.\n\nIn the simplest terms, HINT successively refines the upper and lower bounds\n(quality) of the function `(1-x)/(1+x)` with each subinterval, eventually\narriving at a solution similar to this example with 8-bit data types shown\nbelow:\n\n[![](http://www.johngustafson.net/pubs/pub47/Figure4.gif)](http://www.johngustafson.net/pubs/pub47/Hint.htm)\n\nThe quality of this solution can further be refined theoretically infinitely, only\nlimited by the hardware of the system it is running on and the precision of the\nselected data types.\n\nWhile HINT outputs a \"Net QUIPS\" score at the end of every run, actual HINT\nresults are dumped to a file as a table of QUIPS observed over time and are\nmeant to be plotted to better evaluate the performance of not only the\nprocessor but the memory subsystems as well. Gustafson and Snell provide an\nexample plot of HINT results from an SGI Indy workstation with a variety of\ndata types in HINT's introductory publication:\n\n[![](http://www.johngustafson.net/pubs/pub47/Figure5.gif)](http://www.johngustafson.net/pubs/pub47/Hint.htm)\n\nWhile net QUIPS can still be considered a valid performance estimate, plotting\nHINT data provides much more insight into more significant system components,\nas well as the system's ability to sustain a given rate of QUIPS over an\nextended period of time.\n\nThe version of HINT included in this package is the \"serial\" variant for\nsingle-processor Unix systems, which isn't properly optimized for parallel\nexecution. A parallel version of HINT does exist, and may be included in this\npackage at a later time. Some modifications were introduced primarily for\npackaging and ANSI compliance, mainly the removal of the `long long` data type\nand fixed data file names to allow for proper execution from the makefile.\n\nJohn Gustafson maintains a \n[small page dedicated to HINT](http://www.johngustafson.net/hint.html)\non his website, including links to some interesting publications, results and\nsource code.\n\n##### Run notes\n\nBy default, the makefile builds a `double` executable when run or builds all\nexecutables when run with `make` alone.\n\nThe data type used by HINT can be changed at compile time with the make target\nor `dtype` parameter (when using `make run`) set to one of the following values:\n* `short`\n* `int`\n* `long`\n* `float`\n* `double` (default)\n* `ldouble` (long double)\n\nHINT requires additional flags to compile on some platforms, currently only\nHP-UX with `platform=hp-ux` is accounted for. \n\nThe HINT benchmark can take a considerably long time to run depending on the\ndata type selected, be patient with it!\n\n##### [HINT results](http://github.com/nfinit/ansibench/wiki/HINT-results)\n---------------------------------------------------------------------------\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnfinit%2Fansibench","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnfinit%2Fansibench","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnfinit%2Fansibench/lists"}