DOCSLIB.ORG

A Generalized Streaming Model for Concurrent Computing

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Generalized Streaming Model for Concurrent Computing A Generalized Streaming Model For Concurrent Computing∗ Yibing Wang† Abstract- Multicore parallel programming has some Information processing on modern computers has very difficult problems such as deadlocks during synchro- never followed a monotonous path, but the main- nizations and race conditions brought by concurrency. stream has come along a relatively unified way due Added to the difficulty is the lack of a simple, well- to the Turing machine abstraction in theory [26] and accepted computing model for multicore architectures— von Neumann model [3] in design. The adoption because of that it is hard to develop powerful program- of multicore architectures, however, brings the in- ming environments and debugging tools. To tackle the dustry into a new chaos at various computing levels challenges, we promote a generalized stream comput- ranging from programming language designs to op- ing model, inspired by previous researches on stream erating system designs. Not only are programmers computing, that unifies parallelization strategies for pro- often frustrated with primitive solutions or the lack gramming language design, compiler design and operat- of ideal software tools (e.g. programming languages ing system design. Our model provides a high-level ab- and debuggers), but also are chip makers facing chal- straction in designing language constructs to convey con- lenges in delivering new designs [34, 48]; whereas cepts of concurrent operations, in organizing a program’s tools’ builders are constrained by the multithread- runtime layout for parallel execution, and in scheduling ing model, such as in the cases of OpenMP [52] and concurrent instruction blocks through runtime and/or C++-0x thread library extension [68], or by impera- operating systems. In this paper, we give a high-level tive languages, such as in the cases of CUDA [49, 51] description of the proposed model: we define the founda- and OpenCL [31]. To change the impasse situa- tion of the model, show its simplicity through algebraic/- tion where researchers and developers at different computational operation analysis, illustrate a program- computing levels have uncertain expectations from ming framework enabled by the model, and demonstrate each other, first a well-accepted computing model is its potential through powerful design options for pro- needed, i.e. we need a model that can guide designs gramming languages, compilers and operating systems. at different computing levels. PRAM [19] has often been used as a conceptual parallel computing model in demonstrating synchro- 1 Introduction nized executions such as concurrent read concurrent write and concurrent read exclusive write. We ar- 1.1 Motivation gue that PRAM captures certain essences such as parallelism in concurrent computing1 but not other When searching for a general approach to the chal- arXiv:1012.1641v1 [cs.PL] 7 Dec 2010 substances such as precedence constraints in opera- lenges [2] faced by multicore programming, partic- tion; and the very nature of its dependence on shared ularly deadlocks during synchronizations and race memory limits PRAM’s power in design. Therefore, conditions [47] introduced by concurrency, which if PRAM is only a generalization (or parallelization) render solutions built on conventional multithread- of the RAM [26] model (Turing machine equivalent) ing models [13, 52, 68] unappealing to programmers, for abstract analysis, what is the parallel-formed gen- we found that there was a need for a unified com- eralization of the von Neumann model and its al- puting model on which computer professionals at ternatives for design? Conventional threads and programming language design level, compiler design transactional memory [11, 24, 35] are not the an- level, and operating system design level could bene- swer; they are implementation details with little ex- fit from each others’ works; and a generalization of tension to the von Neumann model. Many people the stream computing model [12] seemed to have the potential to serve as such a design model for future 1In this paper, concurrent and parallel are interchange- generation computing. Some reasons are explained able in most cases, though we tend to regard concurrent as follows. as having broader meaning in computing than parallel does. The authors of [16] think parallel systems are mostly syn- ∗First draft: Jan. 31, 2010; this draft: Dec. 07, 2010. chronous, whereas concurrent systems also include distributed †Author contact: [email protected]. cases that are mostly asynchronous. 1 agree that threads are low-level programming util- or functional; and the re-use of existing (modi- ities and should remain so; transactional memory fied when necessary) library routines. may not be computationally productive nor energy- • efficient when transactions are large in size or long It can be reduced to sequential case for debug- in time [24]. ging purpose or when used for single core archi- Stream computing [12, 17, 33, 44] has been around tectures. for more than a decade. Perhaps due to their hum- Furthermore, we regard algorithm design as an in- ble origin (i.e. graphics processors; not their noble separable part of achieving high-performance in mul- originators) in the computer industry, technologies ticore parallel computing. We believe that, due to based on stream computing were often used only as different algorithmic thinking, solutions to an ap- performance accelerators. While surveying the land- plication problem may show different concurrency scape of multicore parallel computing, we realized structures, which have different levels of difficulty that, maybe, the application of stream computing when mapped to the underlying runtime environ- model should go beyond even GPGPU computing, ment and hardware. By supplying an expressive and a generalization of the model could be applied to computing model, we give programmers the needed general purpose software designs and programming power in defining the lest convoluted concurrency as well. Note our pursuit of a general design model structures in their solutions. We use the following was not to find a killer solution (i.e. the implementa- example to further justify our motivation. tion of a certain method) for all applications, but to find a design principle in handling some of the most 1.2 Example difficult yet fundamental problems, such as paral- lelization and nondeterminism. A naive solution to the N-body problem [5, 66] has To serve our purpose, we recommends the separa- the computation complexity of O(N 2). Figure 1 tion of computing models for abstract analysis from shows such an algorithm, where gforce() is a function computing models for generalized design. In [57], for calculating gravitational forces from the other Snyder expressed similar idea but from a different N − 1 objects to the jth object, following the New- angle; he emphasized that a useful parallel machine tonian laws of physics. To parallelize this algorithm, model should be able to capture key features that we often rely on loop nest parallelization by hand or have impact on performance, which to us is a de- through compilers [1, 18]. sign (model) issue. Based on such understanding, plus other people’s publications [10, 11, 20, 25, 35, 2 1 /∗ calculate gravitational forces in time 36, 37, 40] and our own experiences , we propose 2 sequence from zero to tmax ∗/ a generalized stream computing (hereinafter known 3 for (ti = 0; ti < tmax; ti++) as GeneSC, pronounced “g-e-n-e-s-i-s”) model as a 4 { 5 for (j=0; j<N; j++) guideline for multicore computing. Our expectations 6 { of the model can be summarized as follows. 7 f=gforce(j); 8 vnew[j]=v[j]+f ∗ dt; • It will help with defining language constructs for 9 xnew[j] =x[j] +vnew[j] ∗ dt; expressing concurrency structures in programs 10 } and algorithms, but leaving parallelization and 11 for (j=0; j<N; j++) 12 { synchronization controls to compilers, runtimes 13 v[j]=vnew[j]; and/or operating systems. 14 x[j]=xnew[j]; 15 } • It will bring parallelizing compilers out of the 16 } confinement of sequential execution constructs such as loop nests. Figure 1: The N-body algorithm of complexity O(N 2). • It will bring in operating system designs for O N 2 tractable, reliable and concurrent instruction Instead of doing ( ) direct force integrations, sets executions. an improved design [5] recursively divides the space into smaller cubic cells until each cubic cell contains • It will support backward compatible program- no or only one of the N objects, then builds a tree ming schemes, be it structured, object-oriented, with cubic cells that have more than one objects as 2 the intermediate nodes and cells with only one object For example, the author wrote his first multithreaded server in 1997. Part of that early experience was published as the leaves. Gravitational forces among the N ob- in [64]. jects are calculated in a way where far away objects 2 are approximated by their conglomeration masses at bounded program behaviors, with non-determinism their geometry centers. Figure 2 shows the stream- refers to program behaviors that are different (but like skeleton of such an algorithm with complexity well-defined) from run to run even for the same O(NlogN ), where each inner-loop function consists given inputs; and indeterminacy for unbounded, data parallelism. i.e. unpredictable program behaviors. Synchronous operations without randomized functions normally 1 for (ti = 0; ti < tmax; ti++) yield deterministic results; asynchronous operations 2 { may yield either deterministic (when no ordering 3 space_subdivision(); is needed) or non-deterministic (when ordering is 4 tree_construction(); required but, by mistake, not enforced) results. 5 mass_center_calc(); 6 approximate_force(); Shared memory could add more complexities, e.g. 7 position_update(); when supposedly deterministic operations show non- 8 } deterministic or even indeterminacy behaviors, or when non-deterministic operations show indetermi- Figure 2: An improved N-body algorithm of complexity nacy behaviors, due to race conditions. N O(Nlog ). Deadlocks and race conditions are notorious be- cause they bring indeterminacy.
Load more

Recommended publications
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • Glossary of Technical and Scientific Terms (French / English
    Glossary of Technical and Scientific Terms (French / English) Version 11 (Alphabetical sorting) Jean-Luc JOULIN October 12, 2015 Foreword Aim of this handbook This glossary is made to help for translation of technical words english-french. This document is not made to be exhaustive but aim to understand and remember the translation of some words used in various technical domains. Words are sorted alphabetically. This glossary is distributed under the licence Creative Common (BY NC ND) and can be freely redistributed. For further informations about the licence Creative Com- mon (BY NC ND), browse the site: http://creativecommons.org If you are interested by updates of this glossary, send me an email to be on my diffusion list : • [email protected] • [email protected] Warning Translations given in this glossary are for information only and their use is under the responsability of the reader. If you see a mistake in this document, thank in advance to report it to me so i can correct it in further versions of this document. Notes Sorting of words Words are sorted by alphabetical order and are associated to their main category. Difference of terms Some words are different between the "British" and the "American" english. This glossary show the most used terms and are generally coming from the "British" english Words coming from the "American" english are indicated with the suffix : US . Difference of spelling There are some difference of spelling in accordance to the country, companies, universities, ... Words finishing by -ise, -isation and -yse can also be written with -ize, Jean-Luc JOULIN1 Glossary of Technical and Scientific Terms -ization and -yze.
    [Show full text]
  • Lecture 10: Fault Tolerance Fault Tolerant Concurrent Computing
    02/12/2014 Lecture 10: Fault Tolerance Fault Tolerant Concurrent Computing • The main principles of fault tolerant programming are: – Fault Detection - Knowing that a fault exists – Fault Recovery - having atomic instructions that can be rolled back in the event of a failure being detected. • System’s viewpoint it is quite possible that the fault is in the program that is attempting the recovery. • Attempting to recover from a non-existent fault can be as disastrous as a fault occurring. CA463 Lecture Notes (Martin Crane 2014) 26 1 02/12/2014 Fault Tolerant Concurrent Computing (cont’d) • Have seen replication used for tasks to allow a program to recover from a fault causing a task to abruptly terminate. • The same principle is also used at the system level to build fault tolerant systems. • Critical systems are replicated, and system action is based on a majority vote of the replicated sub systems. • This redundancy allows the system to successfully continue operating when several sub systems develop faults. CA463 Lecture Notes (Martin Crane 2014) 27 Types of Failures in Concurrent Systems • Initially dead processes ( benign fault ) – A subset of the processes never even start • Crash model ( benign fault ) – Process executes as per its local algorithm until a certain point where it stops indefinitely – Never restarts • Byzantine behaviour (malign fault ) – Algorithm may execute any possible local algorithm – May arbitrarily send/receive messages CA463 Lecture Notes (Martin Crane 2014) 28 2 02/12/2014 A Hierarchy of Failure Types • Dead process – This is a special case of crashed process – Case when the crashed process crashes before it starts executing • Crashed process – This is a special case of Byzantine process – Case when the Byzantine process crashes, and then keeps staying in that state for all future transitions CA463 Lecture Notes (Martin Crane 2014) 29 Types of Fault Tolerance Algorithms • Robust algorithms – Correct processes should continue behaving thus, despite failures.
    [Show full text]
  • Actor-Based Concurrency by Srinivas Panchapakesan
    Concurrency in Java and Actor- based concurrency using Scala By, Srinivas Panchapakesan Concurrency Concurrent computing is a form of computing in which programs are designed as collections of interacting computational processes that may be executed in parallel. Concurrent programs can be executed sequentially on a single processor by interleaving the execution steps of each computational process, or executed in parallel by assigning each computational process to one of a set of processors that may be close or distributed across a network. The main challenges in designing concurrent programs are ensuring the correct sequencing of the interactions or communications between different computational processes, and coordinating access to resources that are shared among processes. Advantages of Concurrency Almost every computer nowadays has several CPU's or several cores within one CPU. The ability to leverage theses multi-cores can be the key for a successful high-volume application. Increased application throughput - parallel execution of a concurrent program allows the number of tasks completed in certain time period to increase. High responsiveness for input/output-intensive applications mostly wait for input or output operations to complete. Concurrent programming allows the time that would be spent waiting to be used for another task. More appropriate program structure - some problems and problem domains are well-suited to representation as concurrent tasks or processes. Process vs Threads Process: A process runs independently and isolated of other processes. It cannot directly access shared data in other processes. The resources of the process are allocated to it via the operating system, e.g. memory and CPU time. Threads: Threads are so called lightweight processes which have their own call stack but an access shared data.
    [Show full text]
  • Mastering Concurrent Computing Through Sequential Thinking
    review articles DOI:10.1145/3363823 we do not have good tools to build ef- A 50-year history of concurrency. ficient, scalable, and reliable concur- rent systems. BY SERGIO RAJSBAUM AND MICHEL RAYNAL Concurrency was once a specialized discipline for experts, but today the chal- lenge is for the entire information tech- nology community because of two dis- ruptive phenomena: the development of Mastering networking communications, and the end of the ability to increase processors speed at an exponential rate. Increases in performance come through concur- Concurrent rency, as in multicore architectures. Concurrency is also critical to achieve fault-tolerant, distributed services, as in global databases, cloud computing, and Computing blockchain applications. Concurrent computing through sequen- tial thinking. Right from the start in the 1960s, the main way of dealing with con- through currency has been by reduction to se- quential reasoning. Transforming problems in the concurrent domain into simpler problems in the sequential Sequential domain, yields benefits for specifying, implementing, and verifying concur- rent programs. It is a two-sided strategy, together with a bridge connecting the Thinking two sides. First, a sequential specificationof an object (or service) that can be ac- key insights ˽ A main way of dealing with the enormous challenges of building concurrent systems is by reduction to sequential I must appeal to the patience of the wondering readers, thinking. Over more than 50 years, more sophisticated techniques have been suffering as I am from the sequential nature of human developed to build complex systems in communication. this way. 12 ˽ The strategy starts by designing —E.W.
    [Show full text]
  • Concurrent Computing
    Concurrent Computing CSCI 201 Principles of Software Development Jeffrey Miller, Ph.D. [email protected] Outline • Threads • Multi-Threaded Code • CPU Scheduling • Program USC CSCI 201L Thread Overview ▪ Looking at the Windows taskbar, you will notice more than one process running concurrently ▪ Looking at the Windows task manager, you’ll see a number of additional processes running ▪ But how many processes are actually running at any one time? • Multiple processors, multiple cores, and hyper-threading will determine the actual number of processes running • Threads USC CSCI 201L 3/22 Redundant Hardware Multiple Processors Single-Core CPU ALU Cache Registers Multiple Cores ALU 1 Registers 1 Cache Hyper-threading has firmware logic that appears to the OS ALU 2 to contain more than one core when in fact only one physical core exists Registers 2 4/22 Programs vs Processes vs Threads ▪ Programs › An executable file residing in memory, typically in secondary storage ▪ Processes › An executing instance of a program › Sometimes this is referred to as a Task ▪ Threads › Any section of code within a process that can execute at what appears to be simultaneously › Shares the same resources allotted to the process by the OS kernel USC CSCI 201L 5/22 Concurrent Programming ▪ Multi-Threaded Programming › Multiple sections of a process or multiple processes executing at what appears to be simultaneously in a single core › The purpose of multi-threaded programming is to add functionality to your program ▪ Parallel Programming › Multiple sections of
    [Show full text]
  • Download Distributed Systems Free Ebook
    DISTRIBUTED SYSTEMS DOWNLOAD FREE BOOK Maarten van Steen, Andrew S Tanenbaum | 596 pages | 01 Feb 2017 | Createspace Independent Publishing Platform | 9781543057386 | English | United States Distributed Systems - The Complete Guide The hope is that together, the system can maximize resources and information while preventing failures, as if one system fails, it won't affect the availability of the service. Banker's algorithm Dijkstra's algorithm DJP algorithm Prim's algorithm Dijkstra-Scholten algorithm Dekker's algorithm generalization Smoothsort Shunting-yard algorithm Distributed Systems marking algorithm Concurrent algorithms Distributed Systems algorithms Deadlock prevention algorithms Mutual exclusion algorithms Self-stabilizing Distributed Systems. Learn to code for free. For the first time computers would be able to send messages to other systems with a local IP address. The messages passed between machines contain forms of data that the systems want to share like databases, objects, and Distributed Systems. Also known as distributed computing and distributed databases, a distributed system is a collection of independent components located on different machines that share messages with each other in order to achieve common goals. To prevent infinite loops, running the code requires some amount of Ether. As mentioned in many places, one of which this great articleyou cannot have consistency and availability without partition tolerance. Because it works in batches jobs a problem arises where if your job fails — Distributed Systems need to restart the whole thing. While in a voting system an attacker need only add nodes to the network which is Distributed Systems, as free access to the network is a design targetin a CPU power based scheme an attacker faces a physical limitation: getting access to more and more powerful hardware.
    [Show full text]
  • Automated Distributed Implementation of Component-Based Models with Priorities Borzoo Bonakdarpour, Marius Bozga, Jean Quilbeuf
    Automated Distributed Implementation of Component-Based Models with Priorities Borzoo Bonakdarpour, Marius Bozga, Jean Quilbeuf To cite this version: Borzoo Bonakdarpour, Marius Bozga, Jean Quilbeuf. Automated Distributed Implementation of Component-Based Models with Priorities. 1th International Conference on Embedded Software, EM- SOFT 2011, Oct 2011, Taipei, Taiwan. pp.59-68, 10.1145/2038642.2038654. hal-00722405 HAL Id: hal-00722405 https://hal.archives-ouvertes.fr/hal-00722405 Submitted on 1 Aug 2012 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Automated Distributed Implementation of Component-based Models with Priorities∗ Borzoo Bonakdarpour Marius Bozga Jean Quilbeuf School of Computer Science VERIMAG, Centre Équation VERIMAG, Centre Équation University of Waterloo 2 avenue de Vignate 2 avenue de Vignate 200 University Avenue West 38610, GIÈRES, France 38610, GIÈRES, France Waterloo, Canada, N2L3G1 [email protected] [email protected] [email protected] ABSTRACT and Meanings of Programs]: Specifying and Verifying In this paper, we introduce a novel model-based approach for and Reasoning about Programs—Logic of programs; I.2.2 constructing correct distributed implementation of [Artificial Intelligence ]: Automatic Programming—Pro- component-based models constrained by priorities.
    [Show full text]
  • Empirical Study of Concurrent Programming Paradigms
    UNLV Theses, Dissertations, Professional Papers, and Capstones May 2016 Empirical Study of Concurrent Programming Paradigms Patrick M. Daleiden University of Nevada, Las Vegas Follow this and additional works at: https://digitalscholarship.unlv.edu/thesesdissertations Part of the Computer Sciences Commons Repository Citation Daleiden, Patrick M., "Empirical Study of Concurrent Programming Paradigms" (2016). UNLV Theses, Dissertations, Professional Papers, and Capstones. 2660. http://dx.doi.org/10.34917/9112055 This Thesis is protected by copyright and/or related rights. It has been brought to you by Digital Scholarship@UNLV with permission from the rights-holder(s). You are free to use this Thesis in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses you need to obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/ or on the work itself. This Thesis has been accepted for inclusion in UNLV Theses, Dissertations, Professional Papers, and Capstones by an authorized administrator of Digital Scholarship@UNLV. For more information, please contact [email protected]. EMPIRICAL STUDY OF CONCURRENT PROGRAMMING PARADIGMS By Patrick M. Daleiden Bachelor of Arts (B.A.) in Economics University of Notre Dame, Notre Dame, IN 1990 Master of Business Administration (M.B.A.) University of Chicago, Chicago, IL 1993 A thesis submitted in partial fulfillment of the requirements for the Master of Science in Computer Science Department of Computer Science Howard R. Hughes College of Engineering The Graduate College University of Nevada, Las Vegas May 2016 c Patrick M.
    [Show full text]
  • 60 Years of Mastering Concurrent Computing Through Sequential Thinking Sergio Rajsbaum, Michel Raynal
    60 Years of Mastering Concurrent Computing through Sequential Thinking Sergio Rajsbaum, Michel Raynal To cite this version: Sergio Rajsbaum, Michel Raynal. 60 Years of Mastering Concurrent Computing through Sequential Thinking. ACM SIGACT News, Association for Computing Machinery (ACM), 2020, 51 (2), pp.59-88. 10.1145/3406678.3406690. hal-03162635 HAL Id: hal-03162635 https://hal.archives-ouvertes.fr/hal-03162635 Submitted on 17 Jun 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 60 Years of Mastering Concurrent Computing through Sequential Thinking ∗ Sergio Rajsbaumy, Michel Raynal?;◦ yInstituto de Matemáticas, UNAM, Mexico ?Univ Rennes IRISA, 35042 Rennes, France ◦Department of Computing, Hong Kong Polytechnic University [email protected] [email protected] Abstract Modern computing systems are highly concurrent. Threads run concurrently in shared-memory multi-core systems, and programs run in different servers communicating by sending messages to each other. Concurrent programming is hard because it requires to cope with many possible, unpre- dictable behaviors of the processes, and the communication media. The article argues that right from the start in 1960’s, the main way of dealing with concurrency has been by reduction to sequential reasoning.
    [Show full text]
  • List of Lectures Lecture Content Concurrent Computing
    List of lectures 1Introduction and Functional Programming 2Imperative Programming and Data Structures 3Parsing TDDA69 Data and Program Structure 4Evaluation 5Object Oriented Programming Concurrent Computing 6Macros and decorators Cyrille Berger 7Virtual Machines and Bytecode 8Garbage Collection and Native Code 9Concurrent Computing 10Declarative Programming 11Logic Programming 12Summary 2 / 65 Lecture content Concurrent computing Parallel Programming In concurrent computing several Multithreaded Programming computations are executed at the same The States Problems and Solutions time Atomic actions Language and Interpreter Design Considerations In parallel computing all computations units Single Instruction, Multiple Threads Programming have access to shared memory (for instance Distributed programming in a single process) Message Passing In distributed computing computations units MapReduce communicate through messages passing 3 / 65 4 / 65 Benefits of concurrent computing Disadvantages of concurrent computing Faster computation Concurrency is hard to implement Responsiveness properly Interactive applications can be performing two Safety tasks at the same time: rendering, spell checking... Easy to corrupt memory Availability of services Deadlock Load balancing between servers Tasks can wait indefinitely for each other Controllability Non-deterministic Tasks can be suspended, resumed and stopped. Not always faster! The memory bandwidth and CPU cache is limited 5 / 65 6 / 65 Concurrent computing programming Stream Programming in Functional
    [Show full text]
  • Jezyki I Paradygmaty Programowania
    Języki i paradygmaty programowania Marek Góźdź 31 maja 2021 Marek Góźdź (31 maja 2021) Języki i paradygmaty programowania 1 / 331 Literatura podstawowa Aut J.E. Hopcroft, R. Motwani, J.D. Ullman, Wprowadzenie do teorii automatów, języków i obliczeń, wyd. 2, PWN, W-wa 2012 7J B.A. Tate, Siedem języków w siedem tygodni. Praktyczny przewodnik nauki języków programowania, Helion 2011 Literatura dodatkowa J. Bylina, B. Bylina, Przegląd języków i paradygmatów programowania, skrypt UMCS, Lublin 2011 M. Lipovaˇca, Learn You a Haskell for Great Good! A Beginner’s Guide, No Starch Press 2011 (dostępny również on-line: learnyouahaskell.com) W.F. Clocksin, C.S. Mellish, Prolog. Programowanie, Helion 2003 (druk na żądanie) dokumentacja i samouczki do języków: Ruby, Haskell i Prolog Marek Góźdź (31 maja 2021) Języki i paradygmaty programowania 2 / 331 Uwaga 1 Warunki zaliczenia: 1 zaliczone ćwiczenia 2 zdany egzamin Uwaga 2 5 ECTS = 125-150 godzin, czyli po 7-10 godzin pracy tygodniowo! Uwaga 3 Wykład dostępny jest na kft.umcs.lublin.pl/mgozdz/ Marek Góźdź (31 maja 2021) Języki i paradygmaty programowania 3 / 331 Dlaczego „Języki i paradygmaty programowania”, a nie „Paradygmaty i języki programowania”? O jakie języki chodzi? Marek Góźdź (31 maja 2021) Języki i paradygmaty programowania 4 / 331 Proces tworzenia programu: 1 cel – co program ma robić 2 projekt – dobór algorytmu 3 opis – dobór głównego paradygmatu 4 technika – dobór technik programowania 5 narzędzia – wybór języka programowania 6 wykonanie – napisanie kodu, sprawdzenie, uruchomienie Punkty 1–5 to praca koncepcyjna, dopiero ostatni punkt to klepanie w klawiaturę. Marek Góźdź (31 maja 2021) Języki i paradygmaty programowania 5 / 331 Paradygmat określa ogólny sposób podejścia do opisu problemu.
    [Show full text]