EEE 4084 F Digital Systems Lecture 2 Terms

  • Slides: 27
Download presentation
EEE 4084 F Digital Systems Lecture 2: Terms, Amdahl Law & Dealing with reading

EEE 4084 F Digital Systems Lecture 2: Terms, Amdahl Law & Dealing with reading assignments Lecturer: Simon Winberg Attribution-Share. Alike 4. 0 International (CC BY-SA 4. 0)

Outline for Lecture Class Activity – Quiz#0 Terms Validation vs. Verification Commonly used verification

Outline for Lecture Class Activity – Quiz#0 Terms Validation vs. Verification Commonly used verification methods Amdahl’s Law Dealing with reading assignments

TODO … short quiz EEE 4084 F Digital Systems

TODO … short quiz EEE 4084 F Digital Systems

Class Activity #0 - “Initial impressions” 10 minutes to complete a few simple survey

Class Activity #0 - “Initial impressions” 10 minutes to complete a few simple survey questions and prerequisite tests. This quiz is not for marks Name & student number voluntary Quiz

Marking of Quiz 0 ? ! Please swap your Quiz 0 with a buddy

Marking of Quiz 0 ? ! Please swap your Quiz 0 with a buddy I’ll show you the correct solutions in a moment Please hand back your quizzes at end of the lecture (you’re about to find out why!)

Quiz 0 marking … other slideshow

Quiz 0 marking … other slideshow

TERMS TRENDS

TERMS TRENDS

Terms Golden measure: A (usually) sequential solution that you develop as the ‘yard stick’

Terms Golden measure: A (usually) sequential solution that you develop as the ‘yard stick’ A solution that may run slowly, isn’t optimized, but you know it gives (numerically speaking) excellent results E. g. , a solution written in OCTAVE or Mat. Lab, verify it is correct using graphs, inspecting values, checking by hand with calculator, etc. Discussed a bit more later…

Terms Sequential A / Serial (serial. c) non-parallized code solution Generally, you can call

Terms Sequential A / Serial (serial. c) non-parallized code solution Generally, you can call your code solutions parallel. c (or para 1. c, para 2. c if you have multiple versions) You can also include some test data (if it isn’t too big, <1 Mb), e. g. gold. csv or serial. csv, and paral 1. csv

Speed-up = Tp 1 /Tp 2 Where Tp 1 = Run-time of original (or

Speed-up = Tp 1 /Tp 2 Where Tp 1 = Run-time of original (or non-optimized) program Tp 2 = Run-time of optimised program Best practice for measuring speedup: Run the program more than one, discarding the first result (where the cache, etc. is getting ‘warmed up’) To be precise should indicate results from when system wasn’t ‘warmed up’* * (which can be simulated by running a whole lot of other things like Counter. Strike, Half-Life, maybe some Solitare* for good measure -- but more seriously you could write your own ‘cache cleaning program’)

Speed-up graphs

Speed-up graphs

Other Important Terms Verification These terms are not merely theoretical terms to remember, but

Other Important Terms Verification These terms are not merely theoretical terms to remember, but relate directly to your project. Validation Testing Correctness proof Not something done in the project (but if you want to, you can experiment with doing a correctness proof if you are keen)

Verification and Validation (V&V) Two terms you should already know… Verification “Are we building

Verification and Validation (V&V) Two terms you should already know… Verification “Are we building the product right? ” Have we made what we understood we wanted to make? Does the product satisfy its specifications? Validation “Are we building the right product? ” Does the product satisfy the users’ requirements Verification before validation (except in duress)… While it would be nice to be able to validate before verifying, doing so would mean your specifications and design may be wrong in the final version (obviously this sometimes happens in practice due to insufficient time for proper validation) Sommerville, I. Software Engineering. Addison-Wesley, 2000.

Verification before validation The RC engineer (i. e. , you) are effectively designing both

Verification before validation The RC engineer (i. e. , you) are effectively designing both custom hardware and custom software for the RC platform Before attempting to make claims about the validity of your system, it’s usually best practice to establish your own (or team’s) confidence in what your system is doing, i. e. be sure that: The custom hardware working; The software implementation is doing what it was designed to do; and The custom software runs reliably on the custom hardware.

Verification Checking plans, documents, code, Focus of requirements and specifications project Is everything that

Verification Checking plans, documents, code, Focus of requirements and specifications project Is everything that you need there? Algorithms/functions working properly? Done during phase interval (e. g. , design => implementation) Activities: Review meetings, walkthroughs, inspections Informal demonstrations Focus of project

Commonly used verification methods 1. Dual processing, producing two result sets 1. 2. 3.

Commonly used verification methods 1. Dual processing, producing two result sets 1. 2. 3. One version using PC & simulation only; Other version including RC platform Assume the PC version is the correct one (i. e. , the gold measure) Correlate the results to establish correlation coefficients (complex systems may have many different sets of possibly multidimensional data that need to be compared) The correlation coefficients can be used as a kind of ‘confidence factor’

Validation Testing Focus of project of the whole product / system Input: checklist of

Validation Testing Focus of project of the whole product / system Input: checklist of things to test or list of issues that need to have been provided/fixed Towards end of project Activities: Formal demonstrations Factory Acceptance Test

Testing and Correctness proofs Testing refers to aspects of dynamic validation in which a

Testing and Correctness proofs Testing refers to aspects of dynamic validation in which a program is executed and the results analysed Generally Correctness proofs / formal verification More a mathematical approach Exhaustive test => specification guaranteed correct Formal verification of hardware is especially relevant to RC. Formal methods include: Model checking / state space exploration Use of linear temporal logic and computational tree logic Mathematical proof (e. g. proof by induction)

Speed-up Number of processors Amdahl’s Law EEE 4084 F

Speed-up Number of processors Amdahl’s Law EEE 4084 F

Amdahl’s Law: History The guy: Gene Amdahl Was chief architect for IBM's first mainframe

Amdahl’s Law: History The guy: Gene Amdahl Was chief architect for IBM's first mainframe series of computers Founder of Amdahl Corporation Amdahl found stringent restrictions on the speedup possible for given parallelized tasks. Thee observations packaged as: Amdahl's Law

Video Clip… Linux Magazine Video: Understanding Parallel Computing: Amdahl's Law https: //www. youtube. com/watch?

Video Clip… Linux Magazine Video: Understanding Parallel Computing: Amdahl's Law https: //www. youtube. com/watch? v=Wd. Ri. ZEw. Bhs. M Amdahl. flv

Cl as sic Amdahl’s Law ve rsi on Define f as: fraction of computation

Cl as sic Amdahl’s Law ve rsi on Define f as: fraction of computation that can be parallelized (ignoring scheduling overhead) Then (1 - f ) is the fraction that is sequential Define n = no. processors for parallel case The maximum speed-up achievable is: Speedupparallel = 1 (1–f)+ f n Should be able to remember this formula for exams

Amdahl’s Law: Alternate Representation P = expected performance improvement Eu = Execution time on

Amdahl’s Law: Alternate Representation P = expected performance improvement Eu = Execution time on a uniprocessor (serial) Ep = Execution time on a number of processors (parallel) n = number of processors S = fraction of time spent in the sequential time

Homework task Watch 2 nd part of Amdahl’s law video Understanding Parallel Computing (Part

Homework task Watch 2 nd part of Amdahl’s law video Understanding Parallel Computing (Part 2): The Lawn Mower Law Linux. Magazine Amdahl 2. flv

Dealing with reading assignments, seminar and blog You are suppose to read (at least

Dealing with reading assignments, seminar and blog You are suppose to read (at least speed read) the chapters and readings assigned for each seminar Each Seminar Facilitation Group meant to read their aspects in depth, i. e. Whole team to read word-for-word over chapter and paper. Look up things you don’t understand or make notes to discuss with rest of team Meet with team to discuss the readings, to plan your blog and seminar, allocate who does what. Make notes on the work allocations (e. g. you could have one person write up most of the blog, from team notes, and the other two make most of the slides)

Assigned Reading For Thursday next week… S 1 - Landscape of parallel computing research:

Assigned Reading For Thursday next week… S 1 - Landscape of parallel computing research: a view from Berkeley Find it on: Vula Resources/SEMINARS Short Seminar #1 facilitated by lecturer next Thursday 2 pm

End of Lecture 2

End of Lecture 2