DOCSLIB.ORG

The Racket Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Racket Guide The Racket Guide Version 8.2.0.8 Matthew Flatt, Robert Bruce Findler, and PLT September 25, 2021 This guide is intended for programmers who are new to Racket or new to some part of Racket. It assumes programming experience, so if you are new to programming, consider instead reading How to Design Programs. If you want an especially quick introduction to Racket, start with Quick: An Introduction to Racket with Pictures. Chapter 2 provides a brief introduction to Racket. From Chapter 3 on, this guide dives into details—covering much of the Racket toolbox, but leaving precise details to The Racket Reference and other reference manuals. The source of this manual is available on GitHub. 1 Contents 1 Welcome to Racket 16 1.1 Interacting with Racket . 17 1.2 Definitions and Interactions . 17 1.3 Creating Executables . 18 1.4 A Note to Readers with Lisp/Scheme Experience . 19 2 Racket Essentials 20 2.1 Simple Values . 20 2.2 Simple Definitions and Expressions . 21 2.2.1 Definitions . 21 2.2.2 An Aside on Indenting Code . 22 2.2.3 Identifiers . 23 2.2.4 Function Calls (Procedure Applications) . 23 2.2.5 Conditionals with if, and, or, and cond .............. 25 2.2.6 Function Calls, Again . 28 2.2.7 Anonymous Functions with lambda ................. 28 2.2.8 Local Binding with define, let, and let* ............. 30 2.3 Lists, Iteration, and Recursion . 32 2.3.1 Predefined List Loops . 33 2.3.2 List Iteration from Scratch . 34 2.3.3 Tail Recursion . 35 2.3.4 Recursion versus Iteration . 37 2.4 Pairs, Lists, and Racket Syntax . 38 2.4.1 Quoting Pairs and Symbols with quote ............... 39 2 2.4.2 Abbreviating quote with ' ...................... 41 2.4.3 Lists and Racket Syntax . 42 3 Built-In Datatypes 44 3.1 Booleans . 44 3.2 Numbers . 44 3.3 Characters . 47 3.4 Strings (Unicode) . 49 3.5 Bytes and Byte Strings . 50 3.6 Symbols . 52 3.7 Keywords . 54 3.8 Pairs and Lists . 55 3.9 Vectors . 58 3.10 Hash Tables . 59 3.11 Boxes . 61 3.12 Void and Undefined . 61 4 Expressions and Definitions 63 4.1 Notation . 63 4.2 Identifiers and Binding . 64 4.3 Function Calls (Procedure Applications) . 65 4.3.1 Evaluation Order and Arity . 66 4.3.2 Keyword Arguments . 66 4.3.3 The apply Function . 67 4.4 Functions (Procedures): lambda ....................... 68 4.4.1 Declaring a Rest Argument . 69 3 4.4.2 Declaring Optional Arguments . 70 4.4.3 Declaring Keyword Arguments . 71 4.4.4 Arity-Sensitive Functions: case-lambda .............. 73 4.5 Definitions: define .............................. 74 4.5.1 Function Shorthand . 74 4.5.2 Curried Function Shorthand . 75 4.5.3 Multiple Values and define-values ................ 76 4.5.4 Internal Definitions . 78 4.6 Local Binding . 79 4.6.1 Parallel Binding: let ......................... 79 4.6.2 Sequential Binding: let* ...................... 80 4.6.3 Recursive Binding: letrec ..................... 81 4.6.4 Named let .............................. 82 4.6.5 Multiple Values: let-values, let*-values, letrec-values .. 83 4.7 Conditionals . 84 4.7.1 Simple Branching: if ........................ 84 4.7.2 Combining Tests: and and or .................... 85 4.7.3 Chaining Tests: cond ......................... 85 4.8 Sequencing . 87 4.8.1 Effects Before: begin ........................ 87 4.8.2 Effects After: begin0 ........................ 88 4.8.3 Effects If...: when and unless .................... 89 4.9 Assignment: set! .............................. 90 4.9.1 Guidelines for Using Assignment . 91 4.9.2 Multiple Values: set!-values ................... 93 4 4.10 Quoting: quote and ’ ............................ 94 4.11 Quasiquoting: quasiquote and ‘ ...................... 96 4.12 Simple Dispatch: case ............................ 98 4.13 Dynamic Binding: parameterize ...................... 99 5 Programmer-Defined Datatypes 103 5.1 Simple Structure Types: struct ....................... 103 5.2 Copying and Update . 104 5.3 Structure Subtypes . 104 5.4 Opaque versus Transparent Structure Types . 105 5.5 Structure Comparisons . 106 5.6 Structure Type Generativity . 107 5.7 Prefab Structure Types . 108 5.8 More Structure Type Options . 110 6 Modules 115 6.1 Module Basics . 115 6.1.1 Organizing Modules . 116 6.1.2 Library Collections . 117 6.1.3 Packages and Collections . 118 6.1.4 Adding Collections . 119 6.2 Module Syntax . 120 6.2.1 The module Form . 120 6.2.2 The #lang Shorthand . 121 6.2.3 Submodules . 122 6.2.4 Main and Test Submodules . 124 5 6.3 Module Paths . 126 6.4 Imports: require ............................... 130 6.5 Exports: provide ............................... 133 6.6 Assignment and Redefinition . 134 6.7 Modules and Macros . 136 6.8 Protected Exports . 137 7 Contracts 139 7.1 Contracts and Boundaries . 139 7.1.1 Contract Violations . 139 7.1.2 Experimenting with Contracts and Modules . 140 7.1.3 Experimenting with Nested Contract Boundaries . 141 7.2 Simple Contracts on Functions . 141 7.2.1 Styles of -> .............................. 142 7.2.2 Using define/contract and -> .................. 143 7.2.3 any and any/c ............................ 143 7.2.4 Rolling Your Own Contracts . 144 7.2.5 Contracts on Higher-order Functions . 147 7.2.6 Contract Messages with “???” . 147 7.2.7 Dissecting a contract error message . 149 7.3 Contracts on Functions in General . 150 7.3.1 Optional Arguments . 150 7.3.2 Rest Arguments . 151 7.3.3 Keyword Arguments . 151 7.3.4 Optional Keyword Arguments . 152 7.3.5 Contracts for case-lambda ..................... 153 6 7.3.6 Argument and Result Dependencies . 154 7.3.7 Checking State Changes . 156 7.3.8 Multiple Result Values . 157 7.3.9 Fixed but Statically Unknown Arities . 159 7.4 Contracts: A Thorough Example . 160 7.5 Contracts on Structures . 166 7.5.1 Guarantees for a Specific Value . 166 7.5.2 Guarantees for All Values . 166 7.5.3 Checking Properties of Data Structures . 168 7.6 Abstract Contracts using #:exists and #:D ................. 170 7.7 Additional Examples . 171 7.7.1 A Customer-Manager Component . 172 7.7.2 A Parameteric (Simple) Stack . 174 7.7.3 A Dictionary . 177 7.7.4 A Queue . 179 7.8 Building New Contracts . 181 7.8.1 Contract Struct Properties . 186 7.8.2 With all the Bells and Whistles . 188 7.9 Gotchas . 193 7.9.1 Contracts and eq? .......................... 193 7.9.2 Contract boundaries and define/contract ............ 193 7.9.3 Exists Contracts and Predicates . 195 7.9.4 Defining Recursive Contracts . 195 7.9.5 Mixing set! and contract-out .................. 196 8 Input and Output 197 7 8.1 Varieties of Ports . 197 8.2 Default Ports . 199 8.3 Reading and Writing Racket Data . 200 8.4 Datatypes and Serialization . ..
Load more

Recommended publications
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • An Optimized R5RS Macro Expander
    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
    [Show full text]
  • PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63P
    DOCUMENT RESUME ED 290 438 IR 012 986 AUTHOR Cunningham, Robert E.; And Others TITLE Chips: A Tool for Developing Software Interfaces Interactively. INSTITUTION Pittsburgh Univ., Pa. Learning Research and Development Center. SPANS AGENCY Office of Naval Research, Arlington, Va. REPORT NO TR-LEP-4 PUB DAM Oct 67 CONTRACT N00014-83-6-0148; N00014-83-K-0655 NOTE 63p. PUB TYPE Reports - Research/Technical (143) EDRS PRICE MF01/PC03 Plus Postage. DESCRIPTORS *Computer Graphics; *Man Machine Systems; Menu Driven Software; Programing; *Programing Languages IDENTIF7ERS Direct Manipulation Interface' Interface Design Theory; *Learning Research and Development Center; LISP Programing Language; Object Oriented Programing ABSTRACT This report provides a detailed description of Chips, an interactive tool for developing software employing graphical/computer interfaces on Xerox Lisp machines. It is noted that Chips, which is implemented as a collection of customizable classes, provides the programmer with a rich graphical interface for the creation of rich graphical interfaces, and the end-user with classes for modeling the graphical relationships of objects on the screen and maintaining constraints between them. This description of the system is divided into five main sections: () the introduction, which provides background material and a general description of the system; (2) a brief overview of the report; (3) detailed explanations of the major features of Chips;(4) an in-depth discussion of the interactive aspects of the Chips development environment; and (5) an example session using Chips to develop and modify a small portion of an interface. Appended materials include descriptions of four programming techniques that have been sound useful in the development of Chips; descriptions of several systems developed at the Learning Research and Development Centel tsing Chips; and a glossary of key terms used in the report.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Allegro CL User Guide
    Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format
    [Show full text]
  • Structured Foreign Types
    Ftypes: Structured foreign types Andrew W. Keep R. Kent Dybvig Indiana University fakeep,[email protected] Abstract When accessing scalar elements within an ftype, the value of the High-level programming languages, like Scheme, typically repre- scalar is automatically marshaled into the equivalent Scheme rep- sent data in ways that differ from the host platform to support resentation. When setting scalar elements, the Scheme value is consistent behavior across platforms and automatic storage man- checked to ensure compatibility with the specified foreign type, and agement, i.e., garbage collection. While crucial to the program- then marshaled into the equivalent foreign representation. Ftypes ming model, differences in data representation can complicate in- are well integrated into the system, with compiler support for ef- teraction with foreign programs and libraries that employ machine- ficient access to foreign data and debugger support for convenient dependent data structures that do not readily support garbage col- inspection of foreign data. lection. To bridge this gap, many high-level languages feature for- The ftype syntax is convenient and flexible. While it is similar in eign function interfaces that include some ability to interact with some ways to foreign data declarations in other Scheme implemen- foreign data, though they often do not provide complete control tations, and language design is largely a matter of taste, we believe over the structure of foreign data, are not always fully integrated our syntax is cleaner and more intuitive than most. Our system also into the language and run-time system, and are often not as effi- has a more complete set of features, covering all C data types along cient as possible.
    [Show full text]
  • Chez Scheme Version 5 Release Notes Copyright C 1994 Cadence Research Systems All Rights Reserved October 1994 Overview 1. Funct
    Chez Scheme Version 5 Release Notes Copyright c 1994 Cadence Research Systems All Rights Reserved October 1994 Overview This document outlines the changes made to Chez Scheme for Version 5 since Version 4. New items include support for syntax-case and revised report high-level lexical macros, support for multiple values, support for guardians and weak pairs, support for generic ports, improved trace output, support for shared incremental heaps, support for passing single floats to and returning single floats from foreign procedures, support for passing structures to and returning structures from foreign procedures on MIPS-based computers, and various performance enhancements, including a dramatic improvement in the time it takes to load Scheme source and object files on DEC Ultrix MIPS-based computers. Overall performance of generated code has increased by an average of 15–50 percent over Version 4 depending upon optimize level and programming style. Programs that make extensive use of locally-defined procedures will benefit more than programs that rely heavily on globally-defined procedures, and programs compiled at higher optimize levels will improve more than programs compiled at lower optimize levels. Compile time is approximately 25 percent faster. Refer to the Chez Scheme System Manual, Revision 2.5 for detailed descriptions of the new or modified procedures and syntactic forms mentioned in these notes. Version 5 is available for the following platforms: • Sun Sparc SunOS 4.X & Solaris 2.X • DEC Alpha AXP OSF/1 V2.X • Silicon Graphics IRIX 5.X • Intel 80x86 NeXT Mach 3.2 • Motorola Delta MC88000 SVR3 & SVR4 • Decstation/Decsystem Ultrix 4.3A • Intel 80x86 BSDI BSD/386 1.1 • Intel 80x86 Linux This document contains four sections describing (1) functionality enhancements, (2) performance enhance- ments, (3) bugs fixed, and (4) compatibility issues.
    [Show full text]
  • S Allegro Common Lisp Foreign Function Interface
    Please do not remove this page Extensions to the Franz, Inc.'s Allegro Common Lisp foreign function interface Keane, John https://scholarship.libraries.rutgers.edu/discovery/delivery/01RUT_INST:ResearchRepository/12643408560004646?l#13643533500004646 Keane, J. (1996). Extensions to the Franz, Inc.’s Allegro Common Lisp foreign function interface. Rutgers University. https://doi.org/10.7282/t3-pqns-7h57 This work is protected by copyright. You are free to use this resource, with proper attribution, for research and educational purposes. Other uses, such as reproduction or publication, may require the permission of the copyright holder. Downloaded On 2021/09/29 22:58:32 -0400 Extensions to the Franz Incs Allegro Common Lisp Foreign Function Interface John Keane Department of Computer Science Rutgers University New Brunswick NJ keanecsrutgersedu January Abstract As provided by Franz Inc the foreign function interface of Allegro Com mon Lisp has a number of limitations This pap er describ es extensions to the interface that facilitate the inclusion of C and Fortran co de into Common Lisp systems In particular these extensions make it easy to utilize libraries of numerical subroutines such as those from Numerical Recip es in C from within ACL including those routines that take functions as arguments A mechanism for creating Lisplike dynamic runtime closures for C routines is also describ ed Acknowledgments The research presented in this do cument is supp orted in part by NASA grants NCC and NAG This research is also part of the Rutgers based
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • Supplementary Material Forrebuilding Racket on Chez Scheme
    Supplementary Material for Rebuilding Racket on Chez Scheme (Experience Report) MATTHEW FLATT, University of Utah, USA CANER DERICI, Indiana University, USA R. KENT DYBVIG, Cisco Systems, Inc., USA ANDREW W. KEEP, Cisco Systems, Inc., USA GUSTAVO E. MASSACCESI, Universidad de Buenos Aires, Argentina SARAH SPALL, Indiana University, USA SAM TOBIN-HOCHSTADT, Indiana University, USA JON ZEPPIERI, independent researcher, USA All benchmark measurements were performed on an Intel Core i7-2600 3.4GHz processor running 64-bit Linux. Except as specifically noted, we used Chez Scheme 9.5.3 commit 7df2fb2e77 at github:cicso/ChezScheme, modified as commit 6d05b70e86 at github:racket/ChezScheme, and Racket 7.3.0.3 as commit ff95f1860a at github:racket/racket. 1 TRADITIONAL SCHEME BENCHMARKS The traditional Scheme benchmarks in figure1 are based on a suite of small programs that have been widely used to compare Scheme implementations. The benchmark sources are in the "common" directory of the racket-benchmarks package in the Racket GitHub repository. The results are in two groups, where the group starting with scheme-c uses mutable pairs, so they are run in Racket as #lang r5rs programs; for Racket CS we expect overhead due to the use of a record datatype for mutable pairs, instead of Chez Scheme’s built-in pairs. The groups are sorted by the ratio of times for Chez Scheme and the current Racket imple- mentation. Note that the break-even point is near the end of the first group. The racket collatz benchmark turns out to mostly measure the performance of the built-in division operator for rational numbers, while fft and nucleic benefit from flonum unboxing.
    [Show full text]
  • A Quick Introduction to Common Lisp
    CSC 244/444 Notes last updated Feb 3, 2020 A Quick Introduction to Common Lisp Lisp is a functional language well-suited to sym- bolic AI, based on the λ-calculus and with list structures as a very flexible basic data type; pro- grams are themselves list structures, and thus can be created and manipulated just like other data. This introduction isn't intended to give you all the details, but just enough to get across the essential ideas, and to let you get under way quickly. The best way to make use of it is in front of a computer, trying out all the things mentioned. Basic characteristics of Lisp and Common Lisp: • Lisp is primarily intended for manipulating symbolic data in the form of list struc- tures, e.g., (THREE (BLIND MICE) SEE (HOW (THEY RUN)) !) • Arithmetic is included, e.g., (SQRT (+ (* 3 3) (* 4 4))) or (sqrt (+ (* 3 3) (* 4 4))) (Common Lisp is case-insensitive, except in strings between quotes " ... ", specially delimited symbols like |Very Unusual Symbol!|, and for characters prefixed with \\"). • Common Lisp (unlike John McCarthy's original \pure" Lisp) has arrays and record structures; this leads to more understandable and efficient code, much as in typed languages, but there is no obligatory typing. • All computation consists of expression evaluation. For instance, typing in the above (SQRT ...) expression and hitting the enter key immediately gives 5. • Lisp is a functional language based on Alonzo Church's λ-calculus (which like Turing machines provides a complete basis for all computable functions). For instance, a function for the square root of the sum of two squares can be expressed as (lambda (x y) (sqrt (+ (* x x) (* y y)))).
    [Show full text]
  • Parallel Programming with Lisp for Performance
    Parallel Programming with Lisp for Performance Pascal Costanza, Intel, Belgium European Lisp Symposium 2014, Paris, France The views expressed are my own, and not those of my employer. Legal Notices • Cilk, Intel, the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries. Other names and brands may be claimed as the property of others. Results have been estimated based on internal Intel analysis and are provided for informational purposes only. Any difference in system hardware or software design or configuration may affect actual performance. Intel does not control or audit the design or implementation of third party benchmark data or Web sites referenced in this document. Intel encourages all of its customers to visit the referenced Web sites or others where similar performance benchmark data are reported and confirm whether the referenced benchmark data are accurate and reflect performance of systems available for purchase. • Optimization Notice: Intel’s compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instructions sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice. (Notice revision #20110804) • Copyright © 2014 Intel Corporation.
    [Show full text]