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

== Lab 6 5 ==

* Digital sound is typically represented, uncompressed, as signed 16-bit integer signal samples. There is 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 second per channel, for a total of 88.2 or 96 thousand samples per second (kHz). 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).

=== Three Multiple Approaches ===

Three approaches Six programs are provided, each with a different approach to this the problem are provided:, named <code>vol0.c</code> through <code>vol5.c</code>. A header file, <code>vol.h</code>, defines how much data (in number of sample) will be processed by each program, as well as the volume level to be used for scaling (50%).

These are the six programs: # The vol0.c is the basic or Naive naive algorithm (<code>vol1.c</code>). This approach multiplies each sound sample by 0.75the volume scaling factor, casting from signed 16-bit integer to floating point and back again, which . Casting between integer and floating point can be [[Expensive|expensive]] operations.# A lookupvol1.c does the math using fixed-based algorithm (<code>point calculations. This avoids the overhead of casting between integer and floating point and back again.# vol2.c</code>). This approach uses a pre-calculated table of calculates all 65536 possible different results, and then looks up the answer for each sample in that table instead of multiplyinginput value.# A fixedvol3.c is a dummy program -point algorithm it doesn't scale the volume at all. It can be used to determine some of the overhead of the rest of the processing (<code>vol3besides scaling the volume) done by the other programs.# vol4.c</uses Single Instruction, Multiple Data (SIMD) instructions accessed through inline assembley (assembly language code>inserted into a C program). This approach program is specific to the AArch64 architecture and will not build for x86_64.# vol5.c uses fixed-point math SIMD instructions accessed through Complier Intrinsics. This program is also specific to AArch64. '''Note that vol4.c and bit shifting to perform the multiplication without using floatingvol5.c will build only on AArch64 systems because they use architecture-point mathspecific SIMD instructions.'''

In this lab, ''do not'' compare the relative performance across different machines, because the various systems provided have a wide range of processor different microarchitectures, memory configurations, peripheral implementations, and clock speeds, from servermobile-class to mobileserver-class(e.g. Intel Atom vs. Xeon; AMD APU vs. Threadripper; ARM Cortex-A55 vs. Neoverse-V2).  However, ''do'' compare the relative performance of the various algorithms on the ''same'' machine. === Important! ===

The hardest part of this lab, and the most critical component, is being able to separate the performance of the volume scaling code from the rest of the code (which only exists to set up the test of the scaling code). The volume scaling code runs ''very'' quickly, and is dwarfed by the rest of the code. You '''must''':* Control variables in your test environment.** What else is the machine doing while you are testing?** Who else is logged in to the machine?** What background operations are being performed?** How does your login on the machine affect performance (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 versions, or** Add code to the program to measure and report just the performance of 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 -- 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 results (e.g., tolerance limits or standard deviation). === Resources ===* ARM Aarch64 documentation** [http://developer.arm.com/ ARM Developer Information Centre]*** [https://developer.arm.com/docs/den0024/latest ARM Cortex-A Series Programmer’s Guide for ARMv8-A]*** The ''short'' guide to the ARMv8 instruction set: [https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf ARMv8 Instruction Set Overview] ("ARM ISA Overview")*** The ''long'' guide to the ARMv8 instruction set: [https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile] ("ARM ARM")** [https://developer.arm.com/docs/ihi0055/latest/procedure-call-standard-for-the-arm-64-bit-architecture Procedure Call Standard for the ARM 64-bit Architecture (AArch64)] * x86_64 Documentation** AMD: https://developer.amd.com/resources/developer-guides-manuals/ (see the AMD64 Architecture section, particularly the ''AMD64 Architecture Programmer’s Manual Volume 3: General Purpose and System Instructions'')** Intel: http://www.intel.com/content/www/us/en/processors/architectures-software-developer-manuals.html** Web sites*** http://ref.x86asm.net/*** http://sandpile.org/ * Assembler and Inline Assembler** [[Assembler Basics]]** [[Inline Assembly Language]]** GAS Manual - Using as, The GNU Assembler: https://sourceware.org/binutils/docs/as/*** Specifically, the [http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Extended-Asm.html Assembler Instructions with C Expression Operands] section  == Benchmarking ===

Review The files for this lab are in the contents archive <code>/public/spo600-volume-examples.tgz</code> on each of this the SPO600 servers. The archivecontains:* <code>vol.h</code> controls the number of samples to be processedand the volume level to be used* <code>vol1vol0.c</code>, through <code>vol2vol5.c</code>, and implement the various algorithms* <code>vol3vol_createsample.c</code> implement the various algorithmscontains a function to create dummy samples

Perform these steps'''on both x86_64 and AArch64 systems''':# Unpack the archive <code>/public/spo600-algorithmvolume-selection-labexamples.tgz</code>

#* Change the number of samples so that each program takes a reasonable amount of time to execute (suggested minimum is 20 seconds, 1 minute or more is better).# Test the performance of each program.(vol0 through vol3 on x86_64, and vol0 through vol5 on AArch64)

# See if you can measurably increase performance by changing the compiler option (via the Makefile)# Was your prediction about performance accurate?# Find all of the questions, marked with <code>'''Q:'''</code>, in the program comments, and answer those questions.

Blog about your experiments with a detailed analysis of your results, including memory usage, performance, accuracy, and trade-offs. Include answers to all of the questions marked with Q: in the source code.

'''Make sure you convincingly <u>prove </u> your results to your reader! ''' Re-read the [[#Important.21|section marked ''Important'' above]] and make sure you address the issues explained there. Also be sure to explain what you're doing so that a reader coming across your blog post understands the context (in other words, don't just jump into a discussion of optimization results -- give your post some context).

* For AArch64, you could compare the performance on AArchie against the various class servers, or between the class servers and a Raspberry Pi 3 4 (in 64-bit mode) or an ARM Chromebook.* For x86_64, you could compare the performance of different processors, such as xerxesportugal.cdot.systems, your own laptop or desktop, and Seneca systems such as Matrix or lab desktops.

* 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 code under test only 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 very massive large amount of sample data through the function to be able to detect its performance.

{{Admon/tip|stdint.h|The <code>stdint.h</code> header provides definitions for many specialized integer size types. Use <code>int16_t</code> for 16-bit signed integers and <code>uint16_t</code> for 16-bit unsigned integers.}}