It is a common belief that computer performance growth is over 50% annually, or that performance doubles every 18-20 months. By analyzing publicly available results from the SPEC integer (CINT) benchmark suites, we conclude that this was true between 1985 and 1996 -- the early years of the RISC paradigm.During the last 7.5 years (1996-2004), however, performance growth has slowed down to 41%, with signs of a continuing decline. Meanwhile, clock frequency has improved with about 29% annually. The improvement in clock frequency was enabled both by an annual device speed scaling of 20% as well as by longer pipelines with a lower gate-depth in each stage. This paper takes a fresh look at -- and tries to remove the confusion about -- performance scaling that exists in the computer architecture community.

One of the major challenges of automated driving systems (ADS) is showing that they drive safely. Key to ensuring safety is eliciting a complete set of top-level safety requirements (safety goals). This is typically done with an activity called hazard analysis and risk assessment (HARA). In this paper we argue that the HARA of ISO 26262:2018 is not directly suitable for an ADS, both because the number of relevant operational situations may be vast, and because the ability of the ADS to make decisions in order to reduce risks will affect the analysis of exposure and hazards. Instead we propose a tailoring using a quantitative risk norm (QRN) with consequence classes, where each class has a limit for the frequency within which the consequences may occur. Incident types are then defined and assigned to the consequence classes; the requirements prescribing the limits of these incident types are used as safety goals to fulfil in the implementation. The main benefits of the QRN approach are the ability to show completeness of safety goals, and make sure that the safety strategy is not limited by safety goals which are not formulated in a way suitable for an ADS.

An assurance case contains a structured argument supported by evidence, demonstrating that a system fulfils a certain quality attribute such as safety, cybersecurity or reliability. The traditional way of building assurance cases is, however, not well suited to continuous deployment, and difficult to maintain with a product structure where many variants and frequent new versions must be managed. By integrating the assurance work with product development in continuous assurance cases, which are updated and assessed iteratively, we claim continuous deployment of dependability-critical products is possible to achieve. In this paper we propose a work process combining the use of component-based design, contracts, modular assurance cases, and continuous assessment to enable continuous deployment in the context of product lines.

This paper considers program modules, e.g. procedures, functions, and methods as the basic method to exploit speculative parallelism in existing codes. We analyze how much inherent and exploitable parallelism exist in a set of C and Java programs on a set of chip-multiprocessor architecture models, and identify what inherent program features, as well as architectural deficiencies, that limit the speedup. Our data complement previous limit studies by indicating that the programming style - object-oriented versus imperative - does not seem to have any noticeable impact on the achievable speedup. Further, we show that as few as eight processors are enough to exploit all of the inherent parallelism. However, memory-level data dependence resolution and thread management mechanisms of recent CMP proposals may impose overheads that severely limit the speedup obtained.