Management Options

Here we list and explain the stream and behavior management that can be done statically or dinamically during the execution of a benchmark.

Static Management

Static management is done by the use of specific arguments in the command-line through the exec command. See Command-Line Interface or run ./SPBench exec -h for more information.

All of these are also OPTIONAL arguments that you can use within the ‘exec’ command.

  • -in-memory

    It runs the application in-memory, which means that all the input is first loaded into the memory before start processing it. The opposite is true for the writing phase, where the result stays in memory and is only writen to the disk after all the input is proccessed.

  • -nthreads <number_of_threads>

    Here you can define a number of threads to run the parallel versions. To be more preciselly, the degree of parallelism of the parallel stages (Obs.: some PPIs can create more threads than parallel stages). It shows up as a global variable that can be used inside the parallel versions.

  • -frequency <item_delay> (microsecond)

    Here you can choose a frequency for items to be generated at source operator. The default frequency is the one given by the speed of reading items from the disk (or from the memory, in a in-memory execution). The frequency control in SPBench is done by adding a varying time-delay for each item generation. So higher time-delays imply in lower frequencies. Notice that this time-delay is given in microseconds, e.g. 1000 = 1 millisecond. So, if you run a benchmark using a -frequency 1000000 argument, the frequency will be no more than one item per second. However, the frequency can be lower than that if the time it takes for reading an item from the disk is higher than one second.

  • -batch <batch_size>

    Here you can change the size of the batches, so each item can carry more data. By default, the size of each batch is 1.

  • -d

    This a specific argument for bzip2. You can use it to run this application in decompress mode. Observe that for de decompression mode it is required a compressed file as input (e.g. my_compressed_file.tar.bz2).

Real time management

There are some static methods of the SPbench class that you can use within your code to dynamically access or modify some attributes, such as batch size and item read frequency.

  • Batch: You can change the size of batches dinamically. You can do it either inside or outside the stream region of the benchmarks. You can do that by using the SPBench method spb::SPBench::set_batch_size(<batch_size>).

  • Frequency: Frequency in SPBench means the frequency in which items are generated at sources. However, what defines the frequency in SPBench is the size of the time-delay among items generation. Varying the time delay can imply in varying the frequency. You can set this time-delay with micro-second precision using spb::SPBench::set_items_reading_frequency(<us_time-delay>). Of course, there is a maximum frequency for each application, which is limited by the speed at which the items are read from the input stream. In normal executions this speed is limited by the time it takes to read the data from the disk. Therefore, to achieve high frequencies it is recommended to run the benchmark using the in-memory option, since reading data from memory is usually faster than reading from disk.

  • User arguments: Arguments that the user passed on the command line via the -user-arg option can be retrieved within the benchmark code via the spb::SPBench::getArg(<argument_index>) method.

Usage example:

// Example of possible use for custom user argument
my_PPI.setQueueSize(spb::SPBench::getArg(0));

/* Init of stream region */
while(1){
    spb::Item item;
    if(!spb::source_op(item)) break;
    if(/*my_condition*/){
        spb::SPBench::set_batch_size(spb::SPBench::get_batch_size()+1);
        spb::SPBench::set_items_reading_frequency(50000);
    }
    spb::some_op(item);
    spb::some_other_op(item);
    spb::sink_op(item);
} // End of stream region