HARDWARE ACCELERATOR for ELIAS GAMMA CODE by Karuna

Total Page:16

File Type:pdf, Size:1020Kb

HARDWARE ACCELERATOR for ELIAS GAMMA CODE by Karuna HARDWARE ACCELERATOR FOR ELIAS GAMMA CODE by Karuna Ranganathapura Chandrai Gowda A thesis submitted to the Graduate Council of Texas State University in partial fulfillment of the requirements for the degree of Master of Science with a Major in Engineering August 2017 Committee Members: Semih Aslan, Chair Dan Tamir Stan McClellan COPYRIGHT by Karuna Ranganathapura Chandrai Gowda 2017 FAIR USE AND AUTHOR’S PERMISSION STATEMENT Fair Use This work is protected by the Copyright Laws of the United States (Public Law 94-553, section 107). Consistent with fair use as defined in the Copyright Laws, brief quotations from this material are allowed with proper acknowledgment. Use of this material for financial gain without the author’s express written permission is not allowed. Duplication Permission As the copyright holder of this work I, Karuna Ranganathapura Chandrai Gowda, authorize duplication of this work, in whole or in part, for educational or scholarly purposes only. DEDICATION To my Advisor and Mentor, thank you for your valuable guidance and support, without which, this work would not have been possible. To my Family, thank you for your unconditional love and tremendous support. ACKNOWLEDGEMENTS I would first like to thank my thesis advisor Dr. Semih Aslan of the Ingram School of Engineering at Texas State University. Dr. Aslan always was available to provide his valuable inputs whenever I ran into a trouble spot or had a question about my research or academics. He always enabled me with industry standard tool suite, which enhanced this research work and exposed me to the latest technology. He consistently allowed this thesis to be my work but steered me in the right direction whenever I needed it. I would also like to express my sincere gratitude to my thesis committee member Dr. Dan Tamir of the Computer Science Department at Texas State University. Amidst his busy schedule, he always supported my work with his insightful inputs. His valuable ideas unblocked me at critical junctures of this thesis work. Thank you for your kind and invaluable support. I would like to thank Dr. Stan McClellan, Director Ingram School of Engineering at Texas State University for his continued support through this research. I would like to express my sincere gratitude to Dr. Vishu Viswanathan, Graduate Advisor at Ingram School of Engineering at Texas State University. He was always available to support with all the degree related processes and enabled me to maintain focus at school work. He always provided his valuable advice at difficult times, which enabled me to see opportunities amidst the challenges. I immensely thank Dr. Hamid Mahmoodi at San Francisco State University. He taught me everything I know about the HDL design. This knowledge was crucial in v developing and implementing the experiments. I would like to thank my friend Ilya Wagner at Intel Corporation, who answered my HDL design questions that helped in resolving issues in the experiments. Finally, I must express my profound gratitude to my husband and children for providing me with unfailing support and continuous encouragement throughout my years of study and through the process of researching and writing this thesis. This accomplishment would not have been possible without them. Thank you. vi TABLE OF CONTENTS Page 1. INTRODUCTION ...................................................................................................1 2. BACKGROUND .....................................................................................................5 3. LITERATURE REVIEW ......................................................................................19 4. METHODOLOGY ................................................................................................21 5. EXPERIMENTAL SETUP ....................................................................................26 6. DESIGN IMPLEMENTATION ............................................................................37 7. DESIGN VALIDATION .......................................................................................53 8. RESULT EVALUATION AND COMPARISON.................................................60 9. CONCLUSION AND FURTHER RESEARCH .................................................105 vii LIST OF TABLES Table Page 1. Examples of Elias Gamma Encoding ............................................................................7 2. Example of Data Packing...............................................................................................8 3. Example of Data Packing with MSB First ...................................................................10 4. Encode Engine – FSM State Transition Table .............................................................39 5. Pack Engine – FSM State Transition Table .................................................................42 6. Fundamental Design: Decode Engine – FSM State Transition Table .........................46 7. Interconnect Design: EncodePack Engine - FSM State Transition Table ...................50 8. Software Implementation: Best and Worst Case Compression Latencies ...................61 9. Software Implementation: Summary of Compression Efficiency Metrics ..................62 10. Software Implementation: Best and Worst-Case Decompression Latencies ...............63 11. Software Implementation: Summary of Decompression Efficiency Metrics ..............64 12. Expr01: Fundamental Design: Best and Worst Case Compression Latencies ............67 13. Expr01: Fundamental Design: Summary of Compression Efficiency Metrics ...........68 14. Compression Data Comparison: HW Implementation in Expr01 vs Software Implementation .....................................................................................71 15. Expr01: Fundamental Design: Best and Worst Case Decompression Latencies .........72 16. Expr01: Fundamental Design: Summary of Decompression Efficiency Metrics ........73 17. Decompression Data Comparison: HW Implementation in Expr01 vs Software Implementation .....................................................................................76 18. Expr02: Interconnected Design: Best and Worst Case Latencies ................................79 viii 19. Expr02: Interconnected Design: Summary of Compression Efficiency Metrics .........79 20. Compression Data Summary: SW vs Expr01 vs Expr02.............................................85 21. Expr03: Best and Worst Case Latencies ......................................................................90 22. Expr03: Summary of Compression Efficiency Metrics ...............................................91 23. Compression Data Summary: SW vs Expr01 vs Expr02 vs Expr03 ...........................96 24. Performance Summary: Latency and Throughput .....................................................101 25. Performance Summary: Cost and Power ...................................................................101 26. Other Authors' Work: Comparative Perspective .......................................................104 ix LIST OF FIGURES Figure Page 1. Hardware Accelerator Block Diagram ...........................................................................5 2. Top-down Design Hierarchy ........................................................................................11 3. Bottom-up Design Hierarchy .......................................................................................12 4. ASIC Design and Implementation Flow ......................................................................13 5. FPGA Design Flow ......................................................................................................17 6. Hardware Accelerator Block Diagram .........................................................................22 7. Hardware Accelerator Design Validation Methodology .............................................24 8. Hardware accelerator Test Setup .................................................................................26 9. Test Bench Components ..............................................................................................27 10. 0.5 Gaussian Probability Distribution Data Plot ..........................................................29 11. Poisson Distribution Data Plot .....................................................................................29 12. Vivado™ Design Suite ................................................................................................31 13. Vivado Project Manager ..............................................................................................32 14. Vivado Simulation Environment .................................................................................33 15. Vivado™ RTL Analysis Tool ......................................................................................34 16. Vivado Synthesis Tool .................................................................................................35 17. Vivado Implementation Tool .......................................................................................36 18. Fundamental Design – Block Diagram ........................................................................38 19. Fundamental Design – Finite State Machine (FSM) ...................................................39 x 20. Fundamental Design: Encode Engine: Architectural Diagram ....................................41 21. Pack Engine – FSM .....................................................................................................42 22. Fundamental Design: Pack Engine:
Recommended publications
  • Pixel-Based Video Coding
    UPTEC IT 14 003 Examensarbete 30 hp Mars 2014 Pixel-based video coding Johannes Olsson Sandgren Abstract Pixel-based video coding Johannes Olsson Sandgren Teknisk- naturvetenskaplig fakultet UTH-enheten This paper studies the possibilities of extending the pixel-based compression algorithm LOCO-I, used by the lossless and near lossless image compression standard Besöksadress: JPEG-LS, introduced by the Joint Photographic Experts Group (JPEG) in 1999, to Ångströmlaboratoriet Lägerhyddsvägen 1 video sequences and very low bit-rates. Bitrates below 1 bit per pixel are achieved Hus 4, Plan 0 through skipping signaling when the prediction of a pixels sufficiently good. The pixels to be skipped are implicitly detected by the decoder, minimizing the overhead. Postadress: Different methods of quantization are tested, and the possibility of using vector Box 536 751 21 Uppsala quantization is investigated, by matching pixel sequences against a dynamically generated vector tree. Several different prediction schemes are evaluated, both linear Telefon: and non-linear, with both static and adaptive weights. Maintaining the low 018 – 471 30 03 computational complexity of LOCO-I has been a priority. The results are compared Telefax: to different HEVC implementations with regards to compression speed and ratio. 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Jonatan Samuelsson Ämnesgranskare: Cris Luengo Examinator: Lars-Åke Nordén ISSN: 1401-5749, UPTEC IT 14 003 Tryckt av: Reprocentralen ITC Sammanfattning på svenska De dominerande videokomprimeringsstandarderna idag, som H.26x, är blockbaserade, och har förhållandevis hög beräkningsmässig komplexitet, framförallt i kodningsfasen. I följande text utforskas möjligheten att utöka en välkänd algoritm, LOCO-I, för pixel- baserad komprimering så att komprimering lägre än 1 bit per pixel blir möjlig.
    [Show full text]
  • Vosoughi, Mbw2, Cavallar}@Rice.Edu
    Baseband Signal Compression in Wireless Base Stations Aida Vosoughi, Michael Wu, and Joseph R. Cavallaro {vosoughi, mbw2, cavallar}@rice.edu Unused Significant USBR code Motivation 010, 5(=101) Experimental Setup and Results Bit Removal binary code 01011001 11001 Using WARP hardware and WARPLab framework for over-the- With new wireless standards, base stations require 01010000 10000 Used before in air experiments: (a) Downlink, (b) Uplink greater data rates over the serial data link between base 01000111 00111 Network on chip serial station processor and (remote) RF unit. 01001100 01100 link compression 10011100 1001, 4(=100) This link is especially important in: 10010011 1100 10011010 0011 • Distributed Antenna Systems 10010001 1010 • Cooperating base stations …. 0001 • Cloud-based Radio Access Networks … We propose to use a differencing step before compressing with Baseband signals: each of the above lossless schemes. • Usually oversampled and correlated Compression Ratio Results: • Represented with extra bit resolution Proposed Lossy Compression Lossless Schemes: Lossy Scheme: LSB Removal/Quantization: Algorithm TX RX DQPSK 16-QAM Compression can decrease hardware complexity and cost. The number of LSBs that can [1] 1.51 1.07 TX 4 2.3 be removed without causing USBR 1.41 1.17 RX 3.5 2 distortion depends on the Elias-gamma + 1.40 0.84 Introduction and Related Work Adaptive AC modulation type. Adaptive AC 1.26 0.95 Base station architecture with compression/decompression: Elias-gamma 1.22 0.72 With higher size constellations, more bit
    [Show full text]
  • Compressing Integers for Fast File Access
    Compressing Integers for Fast File Access Hugh E. Williams and Justin Zobel Department of Computer Science, RMIT University GPO Box 2476V, Melbourne 3001, Australia Email: hugh,jz @cs.rmit.edu.au { } Fast access to files of integers is crucial for the efficient resolution of queries to databases. Integers are the basis of indexes used to resolve queries, for exam- ple, in large internet search systems and numeric data forms a large part of most databases. Disk access costs can be reduced by compression, if the cost of retriev- ing a compressed representation from disk and the CPU cost of decoding such a representation is less than that of retrieving uncompressed data. In this paper we show experimentally that, for large or small collections, storing integers in a com- pressed format reduces the time required for either sequential stream access or random access. We compare different approaches to compressing integers, includ- ing the Elias gamma and delta codes, Golomb coding, and a variable-byte integer scheme. As a conclusion, we recommend that, for fast access to integers, files be stored compressed. Keywords: Integer compression, variable-bit coding, variable-byte coding, fast file access, scientific and numeric databases. 1. INTRODUCTION codes [2], and parameterised Golomb codes [3]; second, we evaluate byte-wise storage using standard four-byte Many data processing applications depend on efficient integers and a variable-byte scheme. access to files of integers. For example, integer data is We have found in our experiments that coding us- prevalent in scientific and financial databases, and the ing a tailored integer compression scheme can allow indexes to databases can consist of large sequences of retrieval to be up to twice as fast than with integers integer record identifiers.
    [Show full text]
  • Lampiran a Listing Program
    LAMPIRAN A LISTING PROGRAM Private Sub Command3_Click() If UBound(OriginalArray) = 0 Then Exit Sub End MsgBox "There is nothing to End If compress/Decompress" End Sub Else Exit Sub LastCoder = WichCompressor End If Private Sub compress_Click() End If If AutoDecodeIsOn = False Then m1.Visible = True Call Copy_Orig2Work decompress = True m2.Visible = True LastDeCoded = decompress If CompDecomp = 0 Then Exit Sub End Sub If JustLoaded = True Then If CompDecomp = 1 Then decompress = False JustLoaded = False Else Private Sub d1_Click() ReDim UsedCodecs(0) decompress = True CompDecomp = 2 End If End If Dim wktmulai As Single compression.MousePointer = If decompress = True Then MousePointerConstants.vbHourglass Dim decompress As Boolean LastUsed = wktmulai = Timer Dim Dummy As Boolean UsedCodecs(UBound(UsedCodecs)) Call DeCompress_arithmetic_Dynamic(hasil) Dim StTime As Double If JustLoaded = True Then LastUsed = 0 Label12.Caption = Timer - wktmulai & " detik" Dim Text As String If WichCompressor <> LastUsed Then compression.MousePointer = Dim LastUsed As Integer Text = "This is not compressed with ." & MousePointerConstants.vbDefault Chr(13) Call Show_Statistics(False, hasil) MsgBox Text A-1 Call afterContent(hasil) If AutoDecodeIsOn = False Then End If compression.save.Visible = True decompress = True Call Copy_Orig2Work d1.Visible = False If CompDecomp = 0 Then Exit Sub LastDeCoded = decompress d2.Visible = False If CompDecomp = 1 Then decompress = False If JustLoaded = True Then End Sub Else JustLoaded = False decompress = True ReDim UsedCodecs(0)
    [Show full text]
  • Entropy Coding and Different Coding Techniques
    Journal of Network Communications and Emerging Technologies (JNCET) www.jncet.org Volume 6, Issue 5, May (2016) Entropy Coding and Different Coding Techniques Sandeep Kaur Asst. Prof. in CSE Dept, CGC Landran, Mohali Sukhjeet Singh Asst. Prof. in CS Dept, TSGGSK College, Amritsar. Abstract – In today’s digital world information exchange is been 2. CODING TECHNIQUES held electronically. So there arises a need for secure transmission of the data. Besides security there are several other factors such 1. Huffman Coding- as transfer speed, cost, errors transmission etc. that plays a vital In computer science and information theory, a Huffman code role in the transmission process. The need for an efficient technique for compression of Images ever increasing because the is a particular type of optimal prefix code that is commonly raw images need large amounts of disk space seems to be a big used for lossless data compression. disadvantage during transmission & storage. This paper provide 1.1 Basic principles of Huffman Coding- a basic introduction about entropy encoding and different coding techniques. It also give comparison between various coding Huffman coding is a popular lossless Variable Length Coding techniques. (VLC) scheme, based on the following principles: (a) Shorter Index Terms – Huffman coding, DEFLATE, VLC, UTF-8, code words are assigned to more probable symbols and longer Golomb coding. code words are assigned to less probable symbols. 1. INTRODUCTION (b) No code word of a symbol is a prefix of another code word. This makes Huffman coding uniquely decodable. 1.1 Entropy Encoding (c) Every source symbol must have a unique code word In information theory an entropy encoding is a lossless data assigned to it.
    [Show full text]
  • STUDIES on GOPALA-HEMACHANDRA CODES and THEIR APPLICATIONS. by Logan Childers December, 2020
    STUDIES ON GOPALA-HEMACHANDRA CODES AND THEIR APPLICATIONS. by Logan Childers December, 2020 Director of Thesis: Krishnan Gopalakrishnan, PhD Major Department: Computer Science Gopala-Hemachandra codes are a variation of the Fibonacci universal code and have ap- plications in data compression and cryptography. We study a specific parameterization of Gopala-Hemachandra codes and present several results pertaining to these codes. We show that GHa(n) always exists for n ≥ 1 when −2 ≥ a ≥ −4, meaning that these are universal codes. We develop two new algorithms to determine whether a GH code exists for a given a and n, and to construct them if they exist. We also prove that when a = −(4 + k) where k ≥ 1, that there are at most k consecutive integers for which GH codes do not exist. In 2014, Nalli and Ozyilmaz proposed a stream cipher based on GH codes. We show that this cipher is insecure and provide experimental results on the performance of our program that cracks this cipher. STUDIES ON GOPALA-HEMACHANDRA CODES AND THEIR APPLICATIONS. A Thesis Presented to The Faculty of the Department of Computer Science East Carolina University In Partial Fulfillment of the Requirements for the Degree Master of Science in Computer Science by Logan Childers December, 2020 Copyright Logan Childers, 2020 STUDIES ON GOPALA-HEMACHANDRA CODES AND THEIR APPLICATIONS. by Logan Childers APPROVED BY: DIRECTOR OF THESIS: Krishnan Gopalakrishnan, PhD COMMITTEE MEMBER: Venkat Gudivada, PhD COMMITTEE MEMBER: Karl Abrahamson, PhD CHAIR OF THE DEPARTMENT OF COMPUTER SCIENCE: Venkat Gudivada, PhD DEAN OF THE GRADUATE SCHOOL: Paul J. Gemperline, PhD Table of Contents LIST OF TABLES ..................................
    [Show full text]
  • Mp3
    <d.w.o> mp3 book: Table of Contents <david.weekly.org> January 4 2002 mp3 book Table of Contents Table of Contents auf deutsch en español {en français} Chapter 0: Introduction <d.w.o> ● What's In This Book about ● Who This Book Is For ● How To Read This Book books Chapter 1: The Hype code codecs ● What Is Internet Audio and Why Do People Use It? mp3 book ● Some Thoughts on the New Economy ● A Brief History of Internet Audio news ❍ Bell Labs, 1957 - Computer Music Is Born pictures ❍ Compression in Movies & Radio - MP3 is Invented! poems ❍ The Net Circa 1996: RealAudio, MIDI, and .AU projects ● The MP3 Explosion updates ❍ 1996 - The Release ❍ 1997 - The Early Adopters writings ❍ 1998 - The Explosion video ❍ sidebar - The MP3 Summit get my updates ❍ 1999 - Commercial Acceptance ● Why Did It Happen? ❍ Hardware ❍ Open Source -> Free, Convenient Software ❍ Standards ❍ Memes: Idea Viruses ● Conclusion page source http://david.weekly.org/mp3book/toc.php3 (1 of 6) [1/4/2002 10:53:06 AM] <d.w.o> mp3 book: Table of Contents Chapter 2: The Guts of Music Technology ● Digital Audio Basics ● Understanding Fourier ● The Biology of Hearing ● Psychoacoustic Masking ❍ Normal Masking ❍ Tone Masking ❍ Noise Masking ● Critical Bands and Prioritization ● Fixed-Point Quantization ● Conclusion Chapter 3: Modern Audio Codecs ● MPEG Evolves ❍ MP2 ❍ MP3 ❍ AAC / MPEG-4 ● Other Internet Audio Codecs ❍ AC-3 / Dolbynet ❍ RealAudio G2 ❍ VQF ❍ QDesign Music Codec 2 ❍ EPAC ● Summary Chapter 4: The New Pipeline: The New Way To Produce, Distribute, and Listen to Music ● Digital
    [Show full text]
  • CRAM Format Specification (Version 3.0)
    CRAM format specification (version 3.0) [email protected] 4 Feb 2021 The master version of this document can be found at https://github.com/samtools/hts-specs. This printing is version c467e20 from that repository, last modified on the date shown above. license: Apache 2.0 1 Overview This specification describes the CRAM 3.0 format. CRAM has the following major objectives: 1. Significantly better lossless compression than BAM 2. Full compatibility with BAM 3. Effortless transition to CRAM from using BAM files 4. Support for controlled loss of BAM data The first three objectives allow users to take immediate advantage of the CRAM format while offering a smooth transition path from using BAM files. The fourth objective supports the exploration of different lossy compres- sion strategies and provides a framework in which to effect these choices. Please note that the CRAM format does not impose any rules about what data should or should not be preserved. Instead, CRAM supports a wide range of lossless and lossy data preservation strategies enabling users to choose which data should be preserved. Data in CRAM is stored either as CRAM records or using one of the general purpose compressors (gzip, bzip2). CRAM records are compressed using a number of different encoding strategies. For example, bases are reference compressed by encoding base differences rather than storing the bases themselves.1 2 Data types CRAM specification uses logical data types and storage data types; logical data types are written as words (e.g. int) while physical data types are written using single letters (e.g.
    [Show full text]
  • Reducing Memory Access Latencies Using Data Compression in Sparse, Iterative Linear Solvers
    College of Saint Benedict and Saint John's University DigitalCommons@CSB/SJU All College Thesis Program, 2016-2019 Honors Program Spring 2019 Reducing Memory Access Latencies using Data Compression in Sparse, Iterative Linear Solvers Neil Lindquist [email protected] Follow this and additional works at: https://digitalcommons.csbsju.edu/honors_thesis Part of the Numerical Analysis and Computation Commons, and the Numerical Analysis and Scientific Computing Commons Recommended Citation Lindquist, Neil, "Reducing Memory Access Latencies using Data Compression in Sparse, Iterative Linear Solvers" (2019). All College Thesis Program, 2016-2019. 63. https://digitalcommons.csbsju.edu/honors_thesis/63 Copyright 2019 Neil Lindquist Reducing Memory Access Latencies using Data Compression in Sparse, Iterative Linear Solvers An All-College Thesis College of Saint Benedict/Saint John's University by Neil Lindquist April 2019 Project Title: Reducing Memory Access Latencies using Data Compression in Sparse, Iterative Linear Solvers Approved by: Mike Heroux Scientist in Residence Robert Hesse Associate Professor of Mathematics Jeremy Iverson Assistant Professor of Computer Science Bret Benesh Chair, Department of Mathematics Imad Rahal Chair, Department of Computer Science Director, All College Thesis Program i Abstract Solving large, sparse systems of linear equations plays a significant role in cer- tain scientific computations, such as approximating the solutions of partial dif- ferential equations. However, solvers for these types of problems usually spend most of their time fetching data from main memory. In an effort to improve the performance of these solvers, this work explores using data compression to reduce the amount of data that needs to be fetched from main memory. Some compression methods were found that improve the performance of the solver and problem found in the HPCG benchmark, with an increase in floating point operations per second of up to 84%.
    [Show full text]
  • Double Compression of Test Data Using Huffman Code
    Journal of Theoretical and Applied Information Technology 15 May 2012. Vol. 39 No.2 © 2005 - 2012 JATIT & LLS. All rights reserved . ISSN: 1992-8645 www.jatit.org E-ISSN: 1817-3195 DOUBLE COMPRESSION OF TEST DATA USING HUFFMAN CODE 1R.S.AARTHI, 2D. MURALIDHARAN, 3P. SWAMINATHAN 1 School of Computing, SASTRA University, Thanjavur, Tamil Nadu, India 2Assistant professor, School of Computing, SASTRA University, Thanjavur 3Dean, School of Computing, SASTRA University, Thanjavur E-Mail: [email protected] , [email protected] , [email protected] ABSTRACT Increase in design complexity and fabrication technology results in high test data volume. As test size increases memory capacity also increases, which becomes the major difficulty in testing System-on-Chip (SoC). To reduce the test data volume, several compression techniques have been proposed. Code based schemes is one among those compression techniques. Run length coding is one of the most popular coding methodology in code based compression. Run length codes like Golomb code, Frequency directed run Length Code (FDR code), Extended FDR, Modified FDR, Shifted Alternate FDR and OLEL coding compress the test data and the compression ratio increases drastically. For further reduction of test data, double compression technique is proposed using Huffman code. Compression ratio using Double compression technique is presented and compared with the compression ratio obtained by other Run length codes. Keywords:– Test Data Compression, Run Length Codes, Golomb Code, OLEL Code, Huffman Code 1. INTRODUCTION be decreased. One way to achieve it is to compress the test data. Compression is possible for data that are redundant or repeated in a given test set.
    [Show full text]
  • The State of the Art in High Throughput Sequencing Data Compression
    The State of the Art in High Throughput Sequencing Data Compression Supplementary Materials Ibrahim Numanagic,´ James K. Bonfield, Faraz Hach, Jan Voges, Jorn¨ Ostermann, Claudio Alberti, Marco Mattavelli, S. Cenk Sahinalp 1 Nature Methods: doi:10.1038/nmeth.4037 Supplementary Tables and Figures Supplementary Figure 1: Visualised single-threaded and 4-threaded performance of FASTQ and SAM tools' compression rate and compression speed. Center of the coordinate system represents the Gzip's (pigz) or Samtools' performance. On the x-axis, left side represents the compression gain over pigz (Samtools), while right side denotes the compression loss, measured in multiples of pigz's (Samtools') size. For example, 1.5 on the left side in the SAM plot indicates that the compression ratio is 1.5x higher than Samtools. On the y-axis, upper part indicates the slow down, while lower part indicates speed-up. Each point represents the performance of one tool on one sample; shaded polygon represents the performance of one tool across the all samples. For each such polygon, its centroid (representing average performance of the tool) is shown as a large point in the middle. 2 Nature Methods: doi:10.1038/nmeth.4037 Sample SRR554369 SRR327342 MH0001.081026 SRR1284073 SRR870667 ERR174310 ERP001775 Original 165 1.00 947 1.00 512 1.00 649 1.00 7,463 1.00 20,966 1.00 368,183 1.00 pigz 48 0.29 277 0.29 149 0.29 188 0.29 2,108 0.28 5,982 0.29 104,927 0.28 pbzip2 44 0.27 251 0.27 139 0.27 176 0.27 1,879 0.25 5,473 0.26 95,969 0.26 DSRC2 41 0.25 257 0.27 128 0.25
    [Show full text]
  • A New Look at Counters: Don't Run Like Marathon in a Hundred Meter Race
    This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TC.2017.2710125 1 A New Look at Counters: Don’t Run Like Marathon in a Hundred Meter Race Avijit Dutta, Ashwin Jha and Mridul Nandi Abstract—In cryptography, counters (classically encoded as bit strings of fixed size for all inputs) are employed to prevent collisions on the inputs of the underlying primitive which helps us to prove the security. In this paper we present a unified notion for counters, called counter function family. Based on this generalization we identify some necessary and sufficient conditions on counters which give (possibly) simple proof of security for various counter-based cryptographic schemes. We observe that these conditions are trivially true for the classical counters. We also identify and study two variants of the classical counter which satisfy the security conditions. The first variant has message length dependent counter size, whereas the second variant uses universal coding to generate message length independent counter size. Furthermore, these variants provide better performance for shorter messages. For instance, when the message size is 219 bits, AES-LightMAC with 64-bit (classical) counter takes 1:51 cycles per byte (cpb), whereas it takes 0:81 cpb and 0:89 cpb for the first and second variant, respectively. We benchmark the software performance of these variants against the classical counter by implementing them in MACs and HAIFA hash function.
    [Show full text]