[[Category:SPO600 Labs- Retired]]{{Admon/lab|Purpose of this Lab|In this lab, you will select one investigate the impact of two different algorithms for adjusting which produce the volume of PCM audio samples based on benchmarking of two possible approachessame effect.}}{{Chris Tyler DraftAdmon/important|x86_64 and AArch64 Systems|This lab must be performed on both x86_64 and AArch64 systems. You may use the [[SPO600 Servers]] or you may use other system(s) -- it might make sense to use your own x86_64 system and [[SPO600_Servers#AArch64:_israel.cdot.systems|israel.cdot.systems]] for AArch64.}}

=== Background:===* Digital sound is typically represented, uncompressed, as signed 16-bit integer signal samples. There is one stream are two streams of samples , one each for the left and right stereo channels, at typical sample rates of 44.1 or 48 thousand samples (kHz)per secondper channel, for a total of 88.2 or 96 thousand samples per second. Since there are 16 bits (2 bytes) per sample, the data rate is 88.2 * 1000 * 2 = 176,400 bytes/second (~172 KiB/sec) or 96 * 1000 * 2 = 192,000 bytes/second (~187.5 KiB/sec).* To change the volume of sound, each sample can be scaled (multiplied) by a volume factor, in the range of 0.00 (silensesilence) to 1.00 (full volume).

B# vol0. Scale c is the basic or naive algorithm. This approach multiplies each sound sample by the volume scaling factor (0, casting from signed 16-bit integer to floating point and back again. Casting between integer and floating point can be [[Expensive|expensive]] operations.# vol1.75)c does the math using fixed-point calculations. Store This avoids the overhead of casting between integer and floating point and back again.# vol2.c pre-calculates all 65536 different results into , and then looks up the answer for each input value.# vol3.c is a dummy program - it doesn't scale the volume at all. It can be used to determine some of the overhead of the rest of the processing (besides scaling the volume) done by the original array or other programs.# vol4.c uses Single Instruction, Multiple Data (SIMD) instructions accessed through inline assembley (assembly language code inserted into a separate result arrayC program). This program is specific to the AArch64 architecture and will not build for x86_64.# vol5.c uses SIMD instructions accessed through Complier Intrinsics. This program is also specific to AArch64.

C'''Note that vol4. Sum the results c and display the total (just to keep the optimzer from eliminating the scaling code)vol5.c will build only on AArch64 systems because they use architecture-specific SIMD instructions.'''

D. Determine the time taken for step B of each approach. You can add instrumentation to your program or you can use the === Don'time' command.t Compare Across Machines ===

Try using each of these three approaches to step BHowever, and ''do'' compare the results:relative performance of the various algorithms on the ''same'' machine.

# Multiply each sample by the floating point volume factor 0.75# Pre-calculate a lookup table (array) of all possible sample values multiplied by the volume factor, and look up each sample in that table to get the scaled values.# Convert the volume factor 0.75 to a fix-point integer by multiplying by a binary number representing a fixed-point value "1". For example, you could use 0b100000000 (= 256 in decimal). Shift the result to the right the required number of bits after the multiplication (>>8 if you're using 256 as the multiplier).== Important! ===

Blog about You '''must''':* Control variables in your resultstest environment. Important! -- explain what ** What else is the machine doing while you're doing so that a reader coming across are testing?** Who else is logged in to the machine?** What background operations are being performed?** How does your blog post understands login on the context machine affect performance (in e.g., network activity)?* <span style="background: #ffff00">Isolate the performance of the volume scaling code.</span> This is one of the most important parts of this lab! There are two practical approaches:** Subtract the performance of the dummy version of the program from each of the other wordsversions, don't or** Add code to the program to measure and report just jump into a discussion the performance of optimization the volume-scaling code* Repeat the tests multiple times to ensure that the results you are getting are consistent, valid, and accurately reflect the performance of the volume scaling code.** Make sure you are performing enough calculation to give a useful result -- give adjust the SAMPLES value in <code>vol.h</code> to a sufficiently high value** Discard outliers (unusually high or low results)** Average the results.** Take some measure of the amount of variation of your post some contextresults (e.g., tolerance limits or standard deviation).

==== Design of Your Test Tests ====* Most solutions for a problem of this type involve generating a large amount of data in an array, processing that array using the function being evaluated, and then storing that data back into an array. The test setup can take more time than the actual test! Make sure that you measure the time taken for the code in question (the part that scales the sound samples) ONLY -- you need to be able to remove the rest of the processing time from your evaluation.* You may need to run a massive large amount of sample data through the function to be able to detect its performance.* If you do not use the output from your calculation (e.g., do something with the output array), the compiler may recognize that, and remove the code you're trying to test. Be sure to process the results in some way so that the optimizer preserves the code you want to test. It is a good idea to calculate some sort of verification value to ensure that both approaches generate the same results.* Be aware of what other tasks the system is handling during your test run, including software running on behalf of other users.

* Most solutions for a problem of this type involve generating === Tips ==={{Admon/tip|Analysis|Do a large amount thorough analysis of data in an array, processing that array using the function being evaluated, results. Be certain (and then storing prove!) that data back into an array. Make sure that you measure your performance measurement ''does not'' include the time taken in generation or summarization of the test function only -- you need to be able to remove the rest of data. Do multiple runs and discard the processing time from your evaluationoutliers.* You may need Decide whether to run a very large amount of sample data through the function to be able to detect its performance.* If you do not use the output from your calculation (e.g.mean, do something with the output array)minimum, or maximum time values from the compiler may recognize thatmultiple runs, and remove the code explain why you're trying to test. Be sure to process the results in some way so made that the optimizer preserves the code you want to testdecision. It is a good idea to calculate some sort of verification value to ensure that both approaches generate the same resultsControl your variables well.* You can test using actual sound data (see the tips sectionShow relative performance as percentage change, below) or using generated datae.g. If you're generating data, it is best to use a pseudo-random number generator which is seeded with the same value every time, so "this approach was NN% faster than that each run processes the same data.* Be aware of what other tasks the system is handling during your test runapproach".}}

==== Analyzing Results ====* What is the impact {{Admon/tip|Time and Memory Usage of various optimization levels on a Program|You can get basic timing information for a program by running <code>time ''programName''</code> -- the software performance?* Does output will show the distribution of data matter?* If samples are fed at CD rate total time taken (44100 samples per second x 2 channelsreal), can both algorithms keep up?* What is the memory footprint amount of each approach?* What is the performance of each approach?* What is CPU time used to run the energy consumption of each approach? application (What information do you need to calculate this?user)* Aarchie , and Betty have different performance profiles, so it's not reasonable to compare performance between the machines, but it is reasonable to compare amount of CPU time used by the relative performance operating system on behalf of the two algorithms in each contextapplication (system). Do you get similar results?* What other optimizations can be applied to this problem?

{{Admon/tip|Stack Limitstdint.h|Fixed-size, non-static arrays will be placed in the stack space. The size of the stack space is controlled by per-process limits, inherited from the shell, and adjustable with the <code>ulimitstdint.h</code> command. Allocating an array larger than the stack header provides definitions for many specialized integer size limit will cause a segmentation fault, usually on the first writetypes. To see the current stack limit, use Use <code>ulimit -sint16_t</code> (displayed value is in KB; default is usually 8192 KB or 8 MB). To set the current stack limit, place a new size in KB or the keyword <code>unlimited</code>after the <code>for 16-s</code> argument.<br /><br />Alternate (bit signed integers and preferred) approach: allocate the array space with <code>malloc()</code> or <code>calloc()uint16_t</code>for 16-bit unsigned integers.}}

{{Admon/tip|stdint.hScripting|The <code>stdint.h</code> header provides definitions for many specialized integer size types. Use <code>int16_t</code> for 16-bit signed integers.bash scripting capabilities to reduce tedious manual steps!}}