Free hpc challenge benchmark suite software for linux

The Open CORBA Benchmarking Suite measures several basic performance aspects of various CORBA brokers.
The suite produces an XML output that can be submitted to a searchable database of broker performance data and browsed in a graphical form. The suite is portable to a number of platforms and brokers.
For C++ brokers
Enter the "C++" directory. Then enter the subdirectory of that directory that corresponds to the broker of your choice. Check the README file there for further instructions, usually you will use "make" to compile the benchmark.
For Java brokers
Enter the "Java" and then the "build" directory. Then enter the subdirectory of that directory that corresponds to the broker of your choice. Check the README file there for further instructions, usually you will use "ant" to compile the benchmark "ant run" to execute the benchmark.
Understanding results
The results do not get printed until the benchmark is finished, which can take from 2 to 4 hours depending on the platform. The best way to view the results is to capture them to a file and view them graphically at http://nenya.ms.mff.cuni.cz/~bench.
Enhancements:
- Support for system information on Linux 2.6 kernels.
- Slight extensions to the documentation.
- Support for some recent brokers on Solaris (VisiBroker 6.0, omniORB 4.0.5, JacORB 2.2.1).
- Support for some recent brokers on Linux (omniORB 4.0.5, JacORB 2.2.1, JDK 1.5.0, TAO 1.4.3).

HPC Challenge is a high performance benchmark suite. The HPC Challenge consists of basically 7 benchmarks:
1. HPL - the Linpack TPP benchmark which measures the floating point rate of execution for solving a linear system of equations.
2. DGEMM - measures the floating point rate of execution of double precision real matrix-matrix multiplication.
3. STREAM - a simple synthetic benchmark program that measures sustainable memory bandwidth (in GB/s) and the corresponding computation rate for simple vector kernel.
4. PTRANS (parallel matrix transpose) - exercises the communications where pairs of processors communicate with each other simultaneously. It is a useful test of the total communications capacity of the network.
5. RandomAccess - measures the rate of integer random updates of memory (GUPS).
6. FFTE - measures the floating point rate of execution of double precision complex one-dimensional Discrete Fourier Transform (DFT).
7. Communication bandwidth and latency - a set of tests to measure latency and bandwidth of a number of simultaneous communication patterns; based on b_eff (effective bandwidth benchmark).
Compiling:
The first step is to create a configuration file that reflects characteristics of your machine. The configuration file should be created in the hpl directory. This directory contains instructions (the files README and INSTALL) on how to create the configuration file. The directory hpl/setup contains many examples of configuration files. A good approach is to copy one of them to the hpl directory and if it doesnt work then change it. This file is reused by all the components of the HPC Challange suite.
When configuration is done, a file should exist in the hpl directory whose name starts with Make. and ends with the name for the system used for tests. For example, if the name of the system is Unix, the file should be named Make.Unix.
To build the benchmark executable (for the system named Unix) type: make arch=Unix. This command should be run in the top directory (not in the hpl directory). It will look in the hpl directory for the configuration file and use it to build the benchmark executable.
Configuration:
The HPC Challange is driven by a short input file named hpccinf.txt that is almost the same as the input file for HPL (customarily called HPL.dat). Refer to the file hpl/www/tuning.html for details about the input file for HPL. A sample input file is included with the HPC Challange distribution.
The differences between HPL input file and HPC Challange input file can be summarized as follows:
- Lines 3 and 4 are ignored. The output always goes to the file named hpccoutf.txt.
- There are additional lines (starting with line 33) that may (but do not have to) be used to customize the HPC Challenge benchmark. They are described below.
The additional lines in the HPC Challenge input file (compared to the HPL input file) are:
Lines 33 and 34 describe additional matrix sizes to be used for running the PTRANS benchmark (one of the components of the HPC Challange benchmark).
- Lines 35 and 36 describe additional blocking factors to be used for running PTRANS benchmark.
Just for completeness, here is the list of lines of the HPC Challanges input file with brief descriptions of their meaning:
- Line 1: ignored
- Line 2: ignored
- Line 3: ignored
- Line 4: ignored
- Line 5: number of matrix sizes for HPL (and PTRANS)
- Line 6: matrix sizes for HPL (and PTRANS)
- Line 7: number of blocking factors for HPL (and PTRANS)
- Line 8: blocking factors for HPL (and PTRANS)
- Line 9: type of process ordering for HPL
- Line 10: number of process grids for HPL (and PTRANS)
- Line 11: numbers of process rows of each process grid for HPL (and
PTRANS)
- Line 12: numbers of process columns of each process grid for HPL
(and PTRANS)
- Line 13: threshold value not to be exceeded by scaled residual for
HPL (and PTRANS)
- Line 14: number of panel factorization methods for HPL
- Line 15: panel factorization methods for HPL
- Line 16: number of recursive stopping criteria for HPL
- Line 17: recursive stopping criteria for HPL
- Line 18: number of recursion panel counts for HPL
- Line 19: recursion panel counts for HPL
- Line 20: number of recursive panel factorization methods for HPL
- Line 21: recursive panel factorization methods for HPL
- Line 22: number of broadcast methods for HPL
- Line 23: broadcast methods for HPL
- Line 24: number of look-ahead depths for HPL
- Line 25: look-ahead depths for HPL
- Line 26: swap methods for HPL
- Line 27: swapping threshold for HPL
- Line 28: form of L1 for HPL
- Line 29: form of U for HPL
- Line 30: value that specifies whether equilibration should be used
by HPL
- Line 31: memory alignment for HPL
- Line 32: ignored
- Line 33: number of additional problem sizes for PTRANS
- Line 34: additional problem sizes for PTRANS
- Line 35: number of additional blocking factors for PTRANS
- Line 36: additional blocking factors for PTRANS
Enhancements:
- This version contains many bugfixes, major features, and minor enhancements, many of which were contributed by users.
- The major focus of this release was to improve accuracy of the reported performance results and ensure scalability of the code on the largest supercomputer installations with hundreds of thousands of computational cores.

Apache Hello World Benchmarks is a benchmarking tool that seeks to give a sense of Web application execution speed on various software platforms running under the Apache Web server.

Benchmarks can vary greatly from system to system, so this tool allows one to get numbers on ones own platform. Applications tested include mod_perl, mod_php, Tomcat, and Apache::ASP, with over 62 benchmarks in all.

Benchmark Descriptions:

Hello World 2000 ( 2000 )

The 2000 benchmark tries to emulate a heavy web page template. It is typically 3K+ in program length that results in output of over 20K. While this does not properly reflect any web applications speed of back end business logic execution, it does show a template heavy request with some application logic and loops, some HTTP parameter passing, and much variable interpolation in the output stream.

Hello World ( hello )

The Hello World benchmark merely prints "Hello World" and as such is a good test for the fastest a web page could ever run under the given web application environment. For historical reasons, the benchmarks are written to print "Hello" and then add to the output World as a raw string.

HelloDB ( hellodb )

The HelloDB benchmark merely queries the database for the string "Hello World", and as such represents the fastest a web application can process a request when talking to a database. This is a new benchmark with only MySQL supported for now, but more environments and databases will be added over time.

XSLT Big ( xsltbig )

This benchmark hits an XSLT rendering engine hard with 18K+ XML being transformed with a 1K+ XSL stylesheet for over 20K output. Though XSLT is generally slow, many applications will use XSLT caching to speed up response times. This benchmark should emulate well a real world XSLT usage scenario, with perhaps the XSL itself being too trivial.

Hello XSLT ( xslt )

Like the Hello World benchmark, the XSLT version just outputs "Hello World", or the closest we can get when doing XSLT, so it too demonstrates the fastest an application can render a page with XSLT. Benchmarks should be similarly configured between xsltbig and xslt, so a slow caching layer that benefits the former might slow down this benchmark.

The Bioinformatics Benchmark System is an attempt to build a reasonable testing framework, tests, and data, to enable end users and vendors to probe the performance of their systems.

What we are trying to do is to create a framework for testing, and a core set of tests that all may download and use to probe specific elements of systems performance.

Moreover, the source to these tests are available under GPL, and are hosted on Bioinformatics.org and Scalable Informatics LLC The idea is to enable end users, consumers, systems developers, and others to easily build and use meaningful tests for measurement and tuning reasons.

Joe Landman from Scalable Informatics LLC conceived the idea and wrote the original codes. We are looking for additional benchmark code suggestions, tests, data sets, etc.

Current baseline tests are several NCBI BLAST runs, several HMMer runs, and a variety of others. We plan to include ClustalW, X!Tandem, various chemistry, dynamics, and related tests, as well as several others.

Tests such as LINPACK or HPL simply do not provide meaningful performance indicators or predictive models for high performance informatics. Unfortunately, nor do a number of more recent and focused tests.

This is a problem as LINPACK and HPL specifically test the performance on various matrix operations, where you have effectively regular memory access patterns, and specific mathematical operations.

These codes are most useful for comparison to codes with heavy floating point operations, and interleaved memory traffic. These codes were not designed for comprehensive systems benchmarking, where disk I/O, memory latency, and other factors all contribute to the performance issues.

The best tests are the ones that are most similar to the codes you will run on the machine. The tests themselves should be reasonable approximations to a real execution of your code, using real data. You may need to pare it back in order to get realistic run times.

You should have a reasonable subset of data sizes. A single test does not tell you how your system scales, and one of the reasons for the existance of this test is specifically to allow you to test the performance while you increase various aspects of the workload.

You rarely get a quiescent system in a cluster, so we would recommend that you try to run in as realistic an operating environment as possible. A baseline in a quiescent system is fine, but it may set your expectations unreasonably.
top

Benchmark is a Perl module with benchmark running times of Perl code.

SYNOPSIS

use Benchmark qw(:all) ;

timethis ($count, "code");

# Use Perl code in strings...
timethese($count, {
Name1 => ...code1...,
Name2 => ...code2...,
});

# ... or use subroutine references.
timethese($count, {
Name1 => sub { ...code1... },
Name2 => sub { ...code2... },
});

# cmpthese can be used both ways as well
cmpthese($count, {
Name1 => ...code1...,
Name2 => ...code2...,
});

cmpthese($count, {
Name1 => sub { ...code1... },
Name2 => sub { ...code2... },
});

# ...or in two stages
$results = timethese($count,
{
Name1 => sub { ...code1... },
Name2 => sub { ...code2... },
},
none
);
cmpthese( $results ) ;

$t = timeit($count, ...other code...)
print "$count loops of other code took:",timestr($t),"n";

$t = countit($time, ...other code...)
$count = $t->iters ;
print "$count loops of other code took:",timestr($t),"n";

# enable hires wallclock timing if possible
use Benchmark :hireswallclock;

The Benchmark module encapsulates a number of routines to help you figure out how long it takes to execute some code.

timethis - run a chunk of code several times
timethese - run several chunks of code several times
cmpthese - print results of timethese as a comparison chart
timeit - run a chunk of code and see how long it goes
countit - see how many times a chunk of code runs in a given time

c42 Backup Suite is a simple python program for maintaining a central backup in a small, but distributed environment with a central file share. Basically it is a wrapper around the tar backup facility.
Main features:
- Common, simple configuration of backup tasks.
- Use same configuration for full and incremental backups.
- Provide a network wide index of backups.
- Separates creating and compressing of backup files
- Automatically delete outdated backup files.
- The rules which defines if a backup file is outdated or not are specified in the configuration.
- Provide a configuration mechanism that is strong enough to write general backup configurations, which can be shared between different machines and users.
A task is defined backup template. At invocation of the task it is determined if a full or incremental backup should be done.
The separation of creating and compressing of backup files allow the use on a client machine with low CPU resources. For client machines with big CPU resources or a small network bandwidth the compression can be done also on the client side.

The Million Musician Challenge is a project to allow you to play music by playing games. The first game is a 2D vertically scrolling shoot-em-up game.

The keyboard (qwerty or musical) controls an array of sprites corresponding to the music notes. As you shoot the falling sprites, you play notes corresponding to the music.

The Zaval Proxy Suite is an easy-to-use solution that allows monitoring TCP-based protocols, such as HTTP, NNTP and others. It is extremely useful in software development and can be used as a debug tool. Another area of appliance is multiple connections logging with proxy facilities. As soon as its a pure java solution it can be used almost everywhere.

The Zaval Proxy functions as a proxy and transfers data between the server and the client writing incoming and outgoing traffic into log files. So you can see these raw data as is.

On start the Zaval Proxy Suite goes through configuration file and creates the specified number of proxy servers and the shutdown server.

"Proxy server" is a server socket listening on the specified port. When the client is connected proxy connects to the target server and transfers data between them logging entire traffic. On each connection 2 files are created - xxx-input (request data from the client) and xxx-output (response data from the server). The "xxx" means here the sequential number of the connection for the proxy server. The traffic is logged into the separate directory for each proxy.

Shutdown server is needed to close all open connections correctly and close the program.

So, in the particular case you should specify address of proxy server in client application (web browser, for example) and address of the target server in the proxy configuration file. You can create any number of proxy servers that run at the same time, however, they should use different port numbers.