Changes

Jump to: navigation, search

SPO600 Algorithm Selection Lab

125 bytes removed, 12:14, 3 February 2017
no edit summary
== Lab 5 ==
1. Write two different algorithmic approaches to adjusting the volume of a sequence of sound samples:* The first one . In each case, you should scale take a series of signed 16-bit integer by multiplying it integers representing sound waveform samples and multiply each by a floating point "volume scaling factor expressed as a floating point number " in the range of 0.000-1.000. This should It is recommended that one approach be implemented as a function that accepts the naive multiplication of the sample (int16) and by the volume scaling factor (float) , and returns the scaled sample second approach be dramatically different (int16)e.g.* The second version of the function should do the same thing, using a lookup table (a pre-computed array of all 65536 possible values). The lookup table should be initialized every time a different volume factor is observed. This should be implemented as a drop, multiplication by bit-in replacement for the function above (same parameters and return valueshifting, memoization, or another approach).
2. Test which approach is faster. Control the variables and use a large run of data (at least hundreds millions of samples). Use both [[SPO600 Servers|x86 and AArch64]] systems for testing - DO NOT compare results between the architectures (because they are different classes of systems) but DO compare the relative performance of the algorithms on each architecture. For example, you might note that "Algorithm I is NN% faster than Algorithm II on Architecture A, but NN% slower on Architecture B".
3. Blog about your results. Important! -- 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).
==== Design of Your Test ====
* 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. Make sure that you measure the time taken in the test function only -- you need to be able toremove to remove the rest of the processing time from your evaluation.
* You may need 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., 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.
* What is the memory footprint of each approach?
* What is the performance of each approach?
* What is the energy consumption of each approach?(What information do you need to calculate this?)* Xerxes and Aarchie Betty have different performance profiles, so it's not reasonable to compare performance between the machines, but it is reasonable to compare the relative performance of the two algorithms in each context. Do you get similar results?
* What other optimizations can be applied to this problem?

Navigation menu