How Multithreading Addresses the Memory Wall

The memory wall is the predicted situation where improvements to processor speed will be masked by the much slower improvement in dynamic random access (DRAM) memory speed. Since the prediction was made in 1995, considerable progress has been made in addressing the memory wall. There have been advances in DRAM organization, improved approaches to memory hierarchy have been proposed, integrating DRAM onto the processor chip has been investigated and alternative approaches to organizing the instruction stream have been researched. All of these approaches contribute to reducing the predicted memory wall effect; some can potentially be combined. This paper reviews several approaches with a view to assessing the most promising option. Given the growing CPU-DRAM speed gap, any strategy which finds alternative work while waiting for DRAM is likely to be a win

How general-purpose can a GPU be?

The use of graphics processing units (GPUs) in general-purpose computation (GPGPU) is a growing field. GPU instruction sets, while implementing a graphics pipeline, draw from a range of single instruction multiple datastream (SIMD) architectures characteristic of the heyday of supercomputers. Yet only one of these SIMD instruction sets has been of application on a wide enough range of problems to survive the era when the full range of supercomputer design variants was being explored: vector instructions. Supercomputers covered a range of exotic designs such as hypercubes and the Connection Machine (Fox, 1989). The latter is likely the source of the snide comment by Cray: it had thousands of relatively low-speed CPUs (Tucker & Robertson, 1988). Since Cray won, why are we not basing our ideas on his designs (Cray Inc., 2004), rather than those of the losers? The Top 500 supercomputer list is dominated by general-purpose CPUs, and nothing like the Connection Machine that headed the list in 1993 still exists

Mips2C: programming from the machine up

WHY THIS BOOK? Some years ago I took part in a panel discussion titled “Programming Early Considered Harmful” at the SIGCSE 2001 conference [Hitchner et al. 2001]. Once of those present was Yale Patt, whom I had met briefly on a sabbatical at University of Michigan, where he was at the time a professor working in computer architecture. His role on the panel was to proselytise his book, Introduction to Computing Systems: From bits and gates to C and beyond [Patt and Patel 2013], which introduced programming from the low level up. I found the idea intriguing particularly as I also was concerned with the problem that students tend to stick with the first thing they learn. If my concern was correct, it should be better to start with the programming model you want them to internalize, rather than start with machine level programming. Nonenetheless, I am always open to new ideas, and when the opportunity presented itself to run a computer organization course followed by a C course, I decided to try the idea for myself

Back to good health

From introduction: We have a bumper issue, with eleven research papers and one letter to the editor. 2016 was a difficult year for academia in South Africa with highly disruptive protests. 2017 was mostly better from that point of view, though the protest movement has not completely gone away. This issue contains some papers that were submissions to special issues that were not ready in time and hence to some extent is a catch-up issue. In previous issues this year, 29(1), published in July, contained nine research papers, of which five were extended papers from the 2016 SAICSIT annual conference. There was also a special issue on ICT in Education published in October, 29(2), which had five research papers. Two papers from the ICT in Education special issue spilled over to this issue. Overall, we have published 25 research papers this year, compared with four in 2016, fourteen in 2015 and nineteen in 2014. Numbers are therefore looking healthy again; I hope the underlying causes of protest are addressed so we do not have to endure another year like 2016. In the remainder of this editorial, I give an update on the effects of indexing in Scopus, list papers in this issue and end with changes in the editorial team

Project CrayOn: Back to the future for a more General-Purpose GPU

General purpose of use graphics processing units (GPGPU) recapitulates many of the lessons of the early generations of supercomputers. To what extent have we learnt those lessons, rather than repeating the mistakes? To answer that question, I review why the Cray-1 design ushered in a succession of successful supercomputer designs, while more exotic modes of parallelism failed to gain traction. In the light of this review, I propose that new packaging breakthroughs create an opening for revisiting our approach to GPUs and hence GPGPU. If we do not do so now, the GPU endpoint–when no GPU enhancement will be perceptible to human senses–will in any case remove the economic incentive to build ever-faster GPUs and hence the economy of scale incentive for GPGPU. Anticipating this change now makes sense when new 3D packaging options are opening up; I propose one such option inspired by packaging of the Cray-1

Data structures and algorithms for bioinformatics

WHY THIS MATERIAL? Bioinformatics is a difficult subject because it integrates so much from multiple disciplines. The emphasis here is on algorithmic thinking–working from a problem to an implementation while thinking analytically about efficiency concerns. The picture illustrates a general plan for algorithmic thinking. Anything that can be classed as an algorithm can be analysed and your design choices are not always to find the most efficient algorithm possible. The aim is to solve a problem as efficiently as possible; if it is something you do only once, that results in a rather different set of choices than if you are going to do it many times. And–of course–size counts. That is what this course is am I doing this onc

Principles of Computer Architecture

Last week, Control Data ... announced the 6600 system. I understand that in the laboratory developing the system there are only 34 people including the janitor. Of these, 14 are engineers and 4 are programmers... Contrasting this modest effort with our vast development activities, I fail to understand why we have lost our industry leadership position by letting someone else offer the world’s most powerful computer – Thomas Watson Jr., IBM CEO, August 1963 It seems like Mr. Watson has answered his own question – Seymour Cra

2OS

In this book I approach the problem of understanding an OS from the point of view of a C programmer who needs to understand enough of how an OS works to program efficiently and avoid traps and pitfalls arising from not understanding what is happening underneath you. If you have a deep understanding of the memory system, you will not program in a style that loses significant performance by breaking the assumptions of the OS designer. If you have an understanding of how IO works, you can make good use of OS services. As you work through this book you will see other examples

Teaching Without Technology

Technology is touted as a solution to problems in education. But is it? I report here on experiences with dropping use of slides in lectures and returning to working on the board. The apparent result is more interactive, engaged classes. Unfortunately there are too many other variables to make the experiences here definitive. The purpose of this paper is to provoke discussion on whether technology is overused in teaching when the goals of improving student engagement and general effectiveness of learning can be met many ways. Technology is not necessarily bad, but making it the starting point risks locking out nontechnological options