DOCSLIB.ORG

The Looming Software Crisis Due to the Multicore Menace

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Looming Software Crisis Due to the Multicore Menace The Looming Software Crisis due to the Multicore Menace Saman Amarasinghe Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology The “Software Crisis” “To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem." -- E. Dijkstra, 1972 Turing Award Lecture 2 The First Software Crisis • Time Frame: ’60s and ’70s • Problem: Assembly Language Programming – Computers could handle larger more complex programs • Needed to get Abstraction and Portability without losing Performance 3 How Did We Solve the First Software Crisis? • High-level languages for von-Neumann machines – FORTRAN and C • Provided “common machine language” for uniprocessors – Only the common properties are exposed – Hidden properties are backed-up by good compiler technology Common Properties Single flow of control Single memory image Differences: Register File Register Allocation ISA Instruction Selection Functional Units Instruction Scheduling 4 The Second Software Crisis • Time Frame: ’80s and ’90s • Problem: Inability to build and maintain complex and robust applications requiring multi-million lines of code developed by hundreds of programmers – Computers could handle larger more complex programs • Needed to get Composability, Malleability and Maintainability – High-performance was not an issue Æ left to Moore’s Law 5 How Did We Solve the Second Software Crisis? • Object Oriented Programming –C++ – Now C# and Java • Better tools – Component libraries, Purify • Better software engineering methodology – Design patterns, specification, testing, code reviews 6 Today: Programmers are Oblivious about the Processors • Solid boundary between Hardware and Software • Programmers don’t have to know anything about the processor – High level languages abstract away the processors – Ex: Java bytecode is machine independent – Moore’s law does not require the programmers to know anything about the processors to get good speedups • Programs are oblivious to the processor Æ works on all processors – A program written in ’70 using C still works and is much faster today • This abstraction provides a lot of freedom for the programmers 7 The Origins of a Third Crisis • Time Frame: 2010 to ?? • Problem: Sequential performance is left behind by Moore’s law – All software developers have abstracted away the processor assuming that Moore’s law will always provide performance gains! 8 The March to Multicore: Moore’s Law 100000 1,000,000,000 From Hennessy and Patterson, Computer Architecture:Itanium 2 A Quantitative Approach, 4th edition, 2006 Itanium ) 10000 100,000,000 P4 ??%/year Number of Transistors P3 1000 10,000,000 52%/yearP2 Pentium 100 486 1,000,000 386 Performance (vs. VAX-11/780 100,000 10 286 25%/year 8086 1 10,000 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 9 From David Patterson The March to Multicore: Uniprocessor Performance (SPECint) 100000 1,000,000,000 From Hennessy and Patterson, Computer Architecture:Itanium 2 A Quantitative Approach, 4th edition, 2006 Itanium 10000 ) 100,000,000 P4 Number of Transistors P3 1000 10,000,000 52%/yearP2 Pentium 100 486 1,000,000 386 Performance (vs. VAX-11/780 100,000 10 286 25%/year 8086 1 10,000 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 10 From David Patterson The March to Multicore: Uniprocessor Performance (SPECint) 100000 1,000,000,000 From Hennessy and Patterson, Computer Architecture:Itanium 2 A Quantitative Approach, 4th edition, 2006 Itanium ) 10000 100,000,000 P4 ??%/year Number of Transistors P3 1000 10,000,000 52%/yearP2 Pentium 100 486 1,000,000 386 Performance (vs. VAX-11/780 100,000 10 286 25%/year 8086 1 10,000 1978 1980 1982 1984 1986 1988 1990 1992 1994 1996 1998 2000 2002 2004 2006 2008 2010 2012 2014 2016 • General-purpose unicores have stopped historic performance scaling – Power consumption – Wire delays – DRAM access latency – Diminishing returns of more instruction-level parallelism 11 From David Patterson The Origins of a Third Crisis 512 How to program Picochip Ambric PC102 AM2045 256 multicores? Cisco CSR-1 Intel 128 Tflops 64 32 Raza Cavium # of Raw XLR Octeon cores 16 8 Niagara Cell Opteron 4P A Program written in the 70’s not only works today… Broadcom 1480 Xeon MP 4 but also runs faster (tracking Moore’s law) Xbox360 PA-8800 Opteron Tanglewood 2 Power4 PExtreme Power6 Yonah 4004 80808086 286 386 486 Pentium P2 P3 Itanium 1 P4 8008 Athlon Itanium 2 1970 19751980 1985 1990 1995 2000 2005 20?? 12 The Origins of a Third Crisis • Time Frame: 2010 to ?? • Problem: Sequential performance is left behind by Moore’s law • Needed continuous and reasonable performance improvements – to support new features – to support larger datasets • While sustaining portability, malleability and maintainability without unduly increasing complexity faced by the programmer Æ critical to keep-up with the current rate of evolution in software 13 Why Parallelism is Hard • A huge increase in complexity and work for the programmer – Programmer has to think about performance! – Parallelism has to be designed in at every level • Humans are sequential beings – Deconstructing problems into parallel tasks is hard for many of us • Parallelism is not easy to implement – Parallelism cannot be abstracted or layered away – Code and data has to be restructured in very different (non-intuitive) ways • Parallel programs are very hard to debug – Combinatorial explosion of possible execution orderings – Race condition and deadlock bugs are non-deterministic and illusive – Non-deterministic bugs go away in lab environment and with instrumentation 14 Outline: Ideas on Solving the Third Software Crisis 1. Advances in Computer Architecture 2. Novel Programming Models and Languages 3. Aggressive Compilers 4. Tools to support parallelization, debugging and migration 15 Computer Architecture • Current generation of multicores – How can we cobble together something with existing parts/investments? – Impact of multicores haven’t hit us yet • The move to multicore will be a disruptive shift – An inversion of the cost model – A forced shift in the programming model • A chance to redesign the microprocessor from scratch. • What are the innovations that will reduce/eliminate the extra burden placed on the programmer? 16 Novel Opportunities in Multicores • Don’t have to contend with uniprocessors • Not your same old multiprocessor problem – How does going from Multiprocessors to Multicores impact programs? – What changed? – Where is the Impact? – Communication Bandwidth – Communication Latency 17 Communication Bandwidth • How much data can be communicated between two cores? • What changed? 10,000X – Number of Wires – Clock rate – Multiplexing • Impact on programming model? – Massive data exchange is possible 32 Giga bits/sec ~300 Tera bits/sec – Data movement is not the bottleneck Æ processor affinity not that important 18 Communication Latency • How long does it take for a round trip communication? • What changed? 50X – Length of wire – Pipeline stages • Impact on programming model? ~200 Cycles ~4 cycles – Ultra-fast synchronization – Can run real-time apps on multiple cores 19 Architectural Innovations The Raw Experience Supported by a CISE Experimental Partnership The MIT Raw Processor • Raw project started in 1997 Prototype operational in 2003 • The Problem: How to keep the Moore’s Law going with – Increasing processor complexity – Longer wire delays – Higher power consumption • Raw philosophy – Build a tightly integrated multicore – Off-load most functions to compilers and software • Raw design – 16 single issue cores – 4 register-mapped networks – Huge IO bandwidth 180 nm ASIC (IBM SA-27E) •Raw power 18.2mm x 18.2mm – 16 Flops/ops per cycle ~100 million transistors – 16 Memory Accesses per cycle Designed for 225 MHz – 208 Operand Routes per cycle Tested at 425 MHz – 12 IO Operations per cycle Raw’s networks are tightly coupled into the bypass paths r24 r24 Ex: lb r25, 0x341(r26) r25 r25 r26 r26 r27 r27 Network Network Input Output FIFOs FIFOs E M1 M2 A TL TV IF D RF F P U F4 WB fmul r24, r3, r4 fadd r5, r3, r24 route P->E route W->P software software controlled controlled crossbar crossbar Raw Networks is Rarely the Bottleneck (225 Gb/s @ 225 Mhz) • Raw has 4 bidirectional, point-to-point mesh networks MIPS-Style – Two of them statically routed Pipeline – Two of the dynamically routed • A single issue core may read 8 32-bit from or write to one network in buses a given cycle 100% ave. bandwidth utilization 90% ave. instruction utilization • The cores cannot saturate the 80% 70% network! 60% 50% 40% 30% 20% 10% 0% BitonicSort FFT DCT DES TDE Serpent Outline: Ideas on Solving the Third Software Crisis 1. Advances in Computer Architecture 2. Novel Programming Models and Languages 3. Aggressive Compilers 4. Tools to support parallelization, debugging and migration 24 Programming Models and Languages • Critical to solving the third software crisis • Novel languages were the central solution in the last two crises 25 Lessons from the Last Crisis: The OO Revolution • Object Oriented revolution did not come out of a vacuum • Hundreds of small experimental languages • Rely on lessons learned from lesser-known languages – C++ grew out of C, Simula, and other languages – Java grew out of C++, Eiffel, SmallTalk, Objective C,
Load more

Recommended publications
  • List of Different Digital Practices 3
    Categories of Digital Poetics Practices (from the Electronic Literature Collection) http://collection.eliterature.org/1/ (Electronic Literature Collection, Vol 1) http://collection.eliterature.org/2/ (Electronic Literature Collection, Vol 2) Ambient: Work that plays by itself, meant to evoke or engage intermittent attention, as a painting or scrolling feed would; in John Cayley’s words, “a dynamic linguistic wall- hanging.” Such work does not require or particularly invite a focused reading session. Kinetic (Animated): Kinetic work is composed with moving images and/or text but is rarely an actual animated cartoon. Transclusion, Mash-Up, or Appropriation: When the supply text for a piece is not composed by the authors, but rather collected or mined from online or print sources, it is appropriated. The result of appropriation may be a “mashup,” a website or other piece of digital media that uses content from more than one source in a new configuration. Audio: Any work with an audio component, including speech, music, or sound effects. CAVE: An immersive, shared virtual reality environment created using goggles and several pairs of projectors, each pair pointing to the wall of a small room. Chatterbot/Conversational Character: A chatterbot is a computer program designed to simulate a conversation with one or more human users, usually in text. Chatterbots sometimes seem to offer intelligent responses by matching keywords in input, using statistical methods, or building models of conversation topic and emotional state. Early systems such as Eliza and Parry demonstrated that simple programs could be effective in many ways. Chatterbots may also be referred to as talk bots, chat bots, simply “bots,” or chatterboxes.
    [Show full text]
  • Creating Java Applications Using Netrexx
    SG24-2216-00 Creating Java Applications Using NetRexx September 1997 IBML International Technical Support Organization SG24-2216-00 Creating Java Applications Using NetRexx September 1997 Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix B, “Special Notices” on page 273. First Edition (September 1997) This edition applies to Version 1.0 and Version 1.1 of NetRexx with Java Development Kit 1.1.1 for use with the OS/2 Warp, Windows 95, and Windows NT operating systems. Because NetRexx runs on any platform where Java is implemented, it applies to other platforms and operating systems as well. SAMPLE CODE ON THE INTERNET The sample code for this redbook is available as nrxredbk.zip on the ITSO home page on the Internet: ftp://www.redbooks.ibm.com/redbooks/SG242216 Download the sample code and read “Installing the Sample Programs” on page 4. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. QXXE Building 80-E2 650 Harry Road San Jose, California 95120-6099 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1997. All rights reserved. Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp. Contents Figures . xi Tables . xv Preface . xvii How This Document is Organized ................................ xviii The Team That Wrote This Redbook ...............................
    [Show full text]
  • Chapter 1 Issues—The Software Crisis
    Chapter 1 Issues—The Software Crisis 1. Introduction to Chapter This chapter describes some of the current issues and problems in system development that are caused The term "software crisis" has been used since the by software—software that is late, is over budget, late 1960s to describe those recurring system devel- and/or does not meet the customers' requirements or opment problems in which software development needs. problems cause the entire system to be late, over Software is the set of instructions that govern the budget, not responsive to the user and/or customer actions of a programmable machine. Software includes requirements, and difficult to use, maintain, and application programs, system software, utility soft- enhance. The late Dr. Winston Royce, in his paper ware, and firmware. Software does not include data, Current Problems [1], emphasized this situation when procedures, people, and documentation. In this tuto- he said in 1991: rial, "software" is synonymous with "computer pro- grams." The construction of new software that is both Because software is invisible, it is difficult to be pleasing to the user/buyer and without latent certain of development progress or of product com- errors is an unexpectedly hard problem. It is pleteness and quality. Software is not governed by the perhaps the most difficult problem in engi- physical laws of nature: there is no equivalent of neering today, and has been recognized as such Ohm's Law, which governs the flow of electricity in a for more than 15 years. It is often referred to as circuit; the laws of aerodynamics, which act to keep an the "software crisis".
    [Show full text]
  • The Post Infocom Text Adventure Collection
    The Post Infocom Text Adventure Collection Many of us played and loved the text adventures produced by Infocom in the 1980’s. They were rich in story and puzzles, and contained some excellent writing. In the years since Infocom’s demise in 1989, there have been a lot of good games produced using the Z-Machine - the game format that Infocom was using. This gives us a chance to make these modern-day games run on the computers of the 80’s, like the Commodore 64. I decided to create a collection of Z-machine games for the C64, and this is it. All in all, it’s 31 games, released in 1993-2015. Each game has been put into its own directory, in which is also an empty disk for game saves and a file called AUTOSWAP.LST to make life easier for people using the SD2IEC diskdrive substitute. If you haven’t played text adventures before, or feel that you never got the hang of it, you should read the chapter How to play a text adventure. If you want more of a background on Infocom and the game format they used, you should read the chapter about The Zork Machine at the end of this document. There is also a chapter about the process of porting Z-machine games to the C64 and, finally, a chapter about writing your own games. I created this documentation as a PDF, so that you could easily print it out and keep it nearby if you’re enjoying the collection on a real C64.
    [Show full text]
  • Software Engineering and Ethics: When Code Goes Bad
    Software Engineering and Ethics: when code goes bad Once upon a time, estimates for the Strategic Defense Initiative (SDI or ``Star Wars'') claimed that there would be 30 million lines of code, all bug free. This is at least three orders of magnitude greater than ever has been achieved. ... What have we learned since then? 2017 TSP (MSc CCN) 1 Lecture Plan It is a bad plan that admits of no modification Publilius Syrus •Software Crisis •Ethics •Software Engineering •Software Engineering and Ethics •The root of the problem - computer science boundaries? •When code goes bad - education through classic examples •Proposals for the future 2017 TSP (MSc CCN) 2 Software Crisis Do you recognise this? 3 When everyone is wrong Software Engineering and “Bugs” everyone is right Nivelle de La Chaussee QUESTION: What’s the difference between hardware and software ?… buy some hardware and you get a warranty, buy some software and you get a disclaimer The software crisis: •always late Does this really exist? •always over-budget •always buggy •always hard to maintain •always better the next time round … but never is! This doesn’t seem right … where are our ethics? 2017 TSP (MSc CCN) 4 Is there really a crisis? … To avoid crisis, just hire the best people … look at the advances we have made Success in software development depends most upon the quality of the people involved. There is more software to be developed than there are capable developers to do it. Demand for engineers will continue to outstrip supply for the foreseeable future. Complacency has already set in … some firms acknowledge that many of their engineers make negative contribution.
    [Show full text]
  • Shaping Stories and Building Worlds on Interactive Fiction Platforms
    Shaping Stories and Building Worlds on Interactive Fiction Platforms The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Mitchell, Alex, and Nick Monfort. "Shaping Stories and Building Worlds on Interactive Fiction Platforms." 2009 Digital Arts and Culture Conference (December 2009). As Published http://simonpenny.net/dac/day2.html Publisher Digital Arts and Culture Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/100288 Terms of Use Article is made available in accordance with the publisher's policy and may be subject to US copyright law. Please refer to the publisher's site for terms of use. Shaping Stories and Building Worlds on Interactive Fiction Platforms Alex Mitchell Nick Montfort Communications and New Media Programme Program in Writing & Humanistic Studies National University of Singapore Massachusetts Institute of Technology [email protected] [email protected] ABSTRACT simulates an intricate, systematic world full of robots, made of Adventure game development systems are platforms from the components and functioning together in curious ways. The world developer’s perspective. This paper investigates several subtle model acts in ways that are mechanical and nested, making the differences between these platforms, focusing on two systems for code’s class structure seemingly evident as one plays the game. In interactive fiction development. We consider how these platform contrast, Emily Short’s Savoir-Faire (2002), written in Inform 6 differences may have influenced authors as they developed and of similar complexity, exhibits less obvious inheritance and systems for simulation and storytelling. Through close readings of compartmentalization.
    [Show full text]
  • Arxiv:2105.00534V1 [Cs.SE] 2 May 2021 Solutions
    Metadata Interpretation Driven Development J´ulioG.S.F. da Costaa,d, Reinaldo A. Pettac,d, Samuel Xavier-de-Souzaa,b,d, aGraduate Program of Electrical and Computer Engineering bDepartamento de Engenharia de Computa¸c~aoe Automa¸c~ao cDepartamento de Geologia dUniversidade Federal do Rio Grande do Norte, Natal, RN, Brazil, 59078-900 Abstract Context: Despite decades of engineering and scientific research efforts, sep- aration of concerns in software development remains not fully achieved. The ultimate goal is to truly allow code reuse without large maintenance and evo- lution costs. The challenge has been to avoid the crosscutting of concerns phe- nomenon, which has no apparent complete solution. Objective: In this paper, we show that business-domain code inscriptions play an even larger role in this challenge than the crosscutting of concerns. We then introduce a new methodology, called Metadata Interpretation Driven Develop- ment (MIDD) that suggests a possible path to realize separation of concerns by removing functional software concerns from the coding phase. Method: We propose a change in the perspective for building software, from being based on object representation at the coding level to being based on ob- ject interpretation, whose definitions are put into layers of representation other than coding. The metadata of the domain data is not implemented at the level of the code. Instead, they are interpreted at run time. Results: As an important consequence, such constructs can be applied across functional requirements, across business domains, with no concerns regarding the need to rewrite or refactor code. We show how this can increase the (re)use of the constructs.
    [Show full text]
  • TADS-A CFD-Based Turbomachinery and Analysis Design System with GUI Volume I--Method and Results
    j/l _ 7 NASA Contractor Report 198440 ( -_ e/ i" TADS-A CFD-Based Turbomachinery and Analysis Design System With GUI Volume I--Method and Results D.A. Topp, R.A. Myers, and R.A. Delaney Allison Engine Company Indianapolis, Indiana (NASA-CR-198440) TADS: A CFD-BASED TURBOMACHTNERY AND ANALYSTS DESIGN SYSTEM WITH GUT. VOLUME 1: METHOD AND RESULTS Final Report (A1|ison Engine Co.) 121 p G3107 0099810 December 1995 Prepared for Lewis Research Center Under Contract NAS3-25950 National Aeronautics and Space Administration Contents 1 Summary 1 2 Introduction 3 3 Analysis Coupling 7 3.1 Solution Procedure ........................ 7 3.2 Programming Philosophy and Standards ............ 10 3.2.1 File Naming Convention ................. 11 3.2.2 Data Standards ...................... 11 3.2.3 Coordinate Systems .................... 12 3.2.4 Shared Routines and Data ................ 13 3.3 Input Requirements ........................ 13 4 Development of Program Modules 15 4.1 INTIGG .............................. 15 4.2 TIGGC3D ............................. 19 4.3 ADPAC Input Generation .................... 20 4.4 BODYF .............................. 22 4.4.1 Airfoil Thickness Determination ............. 22 4.4.2 Mean Stream Surface Determination .......... 23 4.4.3 Carter's Rule ....................... 26 4.4.4 Mean Stream Surface from MEANSL .......... 26 4.5 ADPA C .............................. 27 4.5.1 Body Force Implementation ............... 27 4.5.2 Verification of Blockage Model .............. 30 4.5.3 Verification of Body Force Formulation ......... 30 4.6 Streamline Finder and Airfoil Slicer ............... 36 4.6.1 RADSL .......................... 36 4.6.2 SLICER .......................... 40 4.7 GRAPE .............................. 40 4.8 RVCQ3D ............................. 44 4.9 Locating the Mean Stream Surface ............... 44 4.9.1 RESTACK ........................
    [Show full text]
  • Pipelines Guide and Reference
    Pipelines Guide and Reference Ed Tomlinson Jeff Hennick René Jansen Version 4.01-GA of March 20, 2021 THE REXX LANGUAGE ASSOCIATION NetRexx Programming Series ISBN 978-90-819090-3-7 Publication Data ©Copyright The Rexx Language Association, 2011- 2021 All original material in this publication is published under the Creative Commons - Share Alike 3.0 License as stated at http://creativecommons.org/licenses/by-nc-sa/3.0/us/legalcode. The responsible publisher of this edition is identified as IBizz IT Services and Consultancy, Amsteldijk 14, 1074 HR Amsterdam, a registered company governed by the laws of the Kingdom of The Netherlands. This edition is registered under ISBN 978-90-819090-3-7 ISBN 978-90-819090-3-7 9 789081 909037 I Contents The NetR Programming Series i 1 Introduction 1 2 The Pipeline Concept 2 2.1 What is a Pipeline? 2 2.2 Stage 2 2.3 Device Driver 3 3 Running pipelines 4 3.1 Configuration 4 3.2 From the NetREXX Workspace (nrws) with direct execution 5 3.3 From the command line with direct execution 6 3.4 Precompiled Pipelines 6 3.5 Compiled from an .njp file 7 3.6 Compiled from an .njp file with additional stage definitions in NetREXX 7 4 Example Session 8 5 Write your own Filters 12 6 More advanced Pipelines 14 7 Device Drivers 15 8 Record Selection 17 9 Filters 18 10 Other Stages 19 11 Multi-Stream Pipelines 20 12 Pipeline Stalls 22 13 How to use a pipe in a NetR program 24 II 14 Giving commands to the operating system 27 14.1 Built-ins 27 15 TCP/IP Networking 28 16 Selecting from relational databases 30 17 The Pipes Runner 31 18 The Pipes Compiler 32 19 Built-in Stages 33 20 Differences with CMS Pipelines 34 Index 83 III The NetR Programming Series This book is part of a library, the NetR Programming Series, documenting the NetREXX programming language and its use and applications.
    [Show full text]
  • Z-Machine and Descendants
    Glk! A universal user interface for IF! Andrew Plotkin — BangBangCon ’17 Glk! A universal user interface! for interactive fiction! Relatively universal, anyhow. Universal-ish. # 1 Glk! A universal user interface for IF! Andrew Plotkin — BangBangCon ’17 Andrew Plotkin [email protected] http://zarfhome.com/ https://github.com/erkyrath @zarfeblong on Twitter Glk, Glulx, Hadean Lands, System’s Twilight, Spider and Web, Capture the Flag with Stuff, Shade, this t-shirt I’m wearing, Seltani, The Dreamhold, Branches and Twigs and Thorns, quite a lot of adventure game reviews, Praser 5, Boodler, A Change in the Weather, an imperfect diagram of the Soul Reaver timeline, Dual Transform, Draco Concordans, and you know how that game Mafia is also called Werewolf? Ok, funny story there — # 2 Glk! A universal user interface for IF! Andrew Plotkin — BangBangCon ’17 Zork 1 (Infocom) # 3 GrueFacts™: A grue can eat doughnuts indefinitely. Glk! A universal user interface for IF! Andrew Plotkin — BangBangCon ’17 Z-machine and descendants 1979: Z-machine design 1980: Z-machine version 3 (Zork 1) 1985: Z-machine version 4 (A Mind Forever Voyaging) 1987: ITF (first open-source Z-interpreter) 1988: Z-machine version 6 (Zork Zero) 1989: Infocom shuts down 1993: Inform (Curses) 1994: Inform 5 1996: Inform 6 1997: Glk spec 1999: Glulx spec 2006: Inform 7 2008: Parchment (first Javascript Z-interpreter) # 4 GrueFacts™: The first grue to swim around the world was named Amelia Nosewig. Glk! A universal user interface for IF! Andrew Plotkin — BangBangCon ’17 XZip (Curses, Graham Nelson) # 5 GrueFacts™: Grues live an average of 67 years, after which they retire to Iceland.
    [Show full text]
  • List of TCP and UDP Port Numbers from Wikipedia, the Free Encyclopedia
    List of TCP and UDP port numbers From Wikipedia, the free encyclopedia This is a list of Internet socket port numbers used by protocols of the transport layer of the Internet Protocol Suite for the establishment of host-to-host connectivity. Originally, port numbers were used by the Network Control Program (NCP) in the ARPANET for which two ports were required for half- duplex transmission. Later, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) needed only one port for full- duplex, bidirectional traffic. The even-numbered ports were not used, and this resulted in some even numbers in the well-known port number /etc/services, a service name range being unassigned. The Stream Control Transmission Protocol database file on Unix-like operating (SCTP) and the Datagram Congestion Control Protocol (DCCP) also systems.[1][2][3][4] use port numbers. They usually use port numbers that match the services of the corresponding TCP or UDP implementation, if they exist. The Internet Assigned Numbers Authority (IANA) is responsible for maintaining the official assignments of port numbers for specific uses.[5] However, many unofficial uses of both well-known and registered port numbers occur in practice. Contents 1 Table legend 2 Well-known ports 3 Registered ports 4 Dynamic, private or ephemeral ports 5 See also 6 References 7 External links Table legend Official: Port is registered with IANA for the application.[5] Unofficial: Port is not registered with IANA for the application. Multiple use: Multiple applications are known to use this port. Well-known ports The port numbers in the range from 0 to 1023 are the well-known ports or system ports.[6] They are used by system processes that provide widely used types of network services.
    [Show full text]
  • Edsger Wybe Dijkstra
    In Memoriam Edsger Wybe Dijkstra (1930–2002) Contents 0 Early Years 2 1 Mathematical Center, Amsterdam 3 2 Eindhoven University of Technology 6 3 Burroughs Corporation 8 4 Austin and The University of Texas 9 5 Awards and Honors 12 6 Written Works 13 7 Prophet and Sage 14 8 Some Memorable Quotations 16 Edsger Wybe Dijkstra, Professor Emeritus in the Computer Sciences Department at the University of Texas at Austin, died of cancer on 6 August 2002 at his home in Nuenen, the Netherlands. Dijkstra was a towering figure whose scientific contributions permeate major domains of computer science. He was a thinker, scholar, and teacher in renaissance style: working alone or in a close-knit group on problems of long-term importance, writing down his thoughts with exquisite precision, educating students to appreciate the nature of scientific research, and publicly chastising powerful individuals and institutions when he felt scientific integrity was being compromised for economic or political ends. In the words of Professor Sir Tony Hoare, FRS, delivered by him at Dijkstra’s funeral: Edsger is widely recognized as a man who has thought deeply about many deep questions; and among the deepest questions is that of traditional moral philosophy: How is it that a person should live their life? Edsger found his answer to this question early in his life: He decided he would live as an academic scientist, conducting research into a new branch of science, the science of computing. He would lay the foundations that would establish computing as a rigorous scientific discipline; and in his research and in his teaching and in his writing, he would pursue perfection to the exclusion of all other concerns.
    [Show full text]