Explore chapters and articles related to this topic
Advanced Microprocessor Architectures
Published in David R. Martinez, Robert A. Bond, Vai M. Michael, High Performance Embedded Computing Handbook, 2018
Janice McMahon, Stephen Crago, Donald Yeung
Commercial general-purpose microprocessors of the past are all based on a sequential execution model. The highly successful microprocessor industry has succeeded by doubling performance every 18–24 months while only making gradual changes to a sequential execution model. The execution model says that a microprocessor executes one instruction at a time in the order that the programmer (or compiler) specifies. The execution model is specified in the form of an instruction set architecture (ISA). The ISA defines the software’s view of the architecture, including machine state (registers and memory), instruction format, supported data types, and interrupt semantics. For example, the x86 instruction set architecture defines an execution model that has survived for decades. The x86 execution model has been extended, but the fundamental execution model has remained unchanged (Oklobdzija 2002).
Implementation of serverless cloud GIS platform for land valuation
Published in International Journal of Digital Earth, 2021
Muhammed Oguzhan Mete, Tahsin Yomralioglu
Except from three main service models, there is Everything as a Service (XaaS) which means all possible services and applications that can be provided over the internet on demand (Duan et al. 2015). Among these, one of the most used models is Function as a Service (FaaS). It is an alternative for deploying applications in the cloud. FaaS runs the function on demand so that users can execute the backend code without provisioning or maintaining servers. FaaS is generally used for building microservices, processing HTTP requests, message queue, or task scheduling purposes (Goebelbecker 2020). AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, IBM/Apache's OpenWhisk, and Oracle Cloud Fn are some of the FaaS examples in the cloud market. FaaS is the core concept of the serverless computing architecture which is an execution model where infrastructure management operations like server or cluster provisioning, capacity provisioning, and maintenance are handled by the cloud provider. Serverless architecture enables building and running services and applications without thinking about servers. On the other hand, users only pay when a serverless application is used, which means that the cloud provider does not charge you any fees other than data storage when the system is not operating.
Torino: A Tangible Programming Language Inclusive of Children with Visual Disabilities
Published in Human–Computer Interaction, 2020
Cecily Morrison, Nicolas Villar, Anja Thieme, Zahra Ashktorab, Eloise Taysom, Oscar Salandin, Daniel Cletheroe, Greg Saul, Alan F Blackwell, Darren Edge, Martin Grayson, Haiyan Zhang
Torino is composed of a central hub and a suite of beads (play, pause, loop, and variable) shown in Figure 4. The hub is the central component of the program to which multiple bead ‘threads’ can be attached. Threads are a series of connected beads which, following the conventional metaphorical terminology of computing, represent a concurrent execution model in terms of threads in the program. The Sonic Pi execution model that underlies Torino is an inherently concurrent language, in which simultaneous musical parts or voices are expressed as concurrent threads. The hub houses a Raspberry Pi, which powers all of the beads and carries out the computation to identify the topology of the beads and translate the physical program into Sonic Pi code. It also houses the speaker, which plays the resulting audio program. The start button allows the child to control initiation of the program.
Neural adaptive admission control framework: SLA-driven action termination for real-time application service management
Published in Enterprise Information Systems, 2021
Tomasz D. Sikora, George D. Magoulas
The benefits of the weaved-in termination control approach for enterprise systems in real-world applications can be substantial: (i) when it is preferable to return error before the maximum contracted execution time is reached than to calculate a response that takes much longer than normally expected. In such cases, the control framework enables termination errors to be handled on the client side for the price of maintaining a tighter conversation (of more frequent responses on requests) with the client systems supporting in this way a higher availability. This strategy may be very effective especially in micro-services architectures where many weakly coupled components are present. In this context, instabilities caused by network issues or over-utilised services must be considered by design in the handling frameworks. Thus, the costs of extending the error management with termination mechanisms should be fairly low. Effectively, the action termination control swaps risks of execution time unpredictability on response type uncertainty but in a precisely defined time frame set in the SLA function definition. This can be applied to cloud service provider systems managing PaaS, FaaS and SaaS, but also to client systems deployed on IaaS where the control framework is weaved-into the application. (ii) When a service provider or client changes/renegotiates the SLA in run time, this can be supported by the framework’s adaptive nature. (iii) When SLA functions per action are not defined explicitly, but the cloud service provider desires to secure the operation of the more important functions, the controller can be used internally by the cloud management framework. This could be useful, for example, in a cloud-computing execution model like serverless computing that requires running an application integrated with the framework. (iv) When it is important to secure productivity or mitigate the risks of over-spending on less essential computation, action termination can be exposed to cloud clients directly on a Software as a Service basis in a form of an API.