programming – Page 2 – Observations from Uppsala

SystemC Evolution Fika: Parallel SystemC

The SystemC Evolution Fika on April 7 had threading/parallelism as its theme. There were four speakers who presented various angles on how to parallelize SystemC models. The presentations and following discussion provided a variety of perspectives on threading as it can be applied in virtual platforms and other computer architecture simulations. It was pretty clear that the presenters and audience had quite different ideas about just what the target domain looks like and the best way to introduce parallelism to SystemC. Here is my take on what was said.

Don’t Look behind the Curtain! (Please)

In a previous blog, I talked a bit about the hazards of coding to an implementation and not a specification, based on 1980s home computers. While the specifics and peculiarities of that case is hopefully confined to old hardware, the lessons are still worth contemplating. There is a modern variant of this phenomenon that is based on open-source software, and that I must admit to feeling a bit annoyed by. Fundamentally, the question is this: when figuring out how to use an API – should you look at the documentation or the implementation?

Easy to Assemble, just like Lego – Right…

When discussing the design and integration of systems on chip and models of systems on chip, the Lego analogy is often brought up. The idea being that with Lego, anyone can put together anything and every component can be combined with all other components. Right. My recent building of Lego set 21327, Typewriter, makes me wonder if the people who talk about Lego-like construction have actually built anything from Legos in the past few decades.

Blog – Damn the Torpedoes, Full Code Ahead!

I have recently got back to developing training labs for the Simics simulator (and related technologies). During the process of developing a new accelerator model using as many of the latest frameworks and APIs as possible, it was basically guaranteed that I would hit some bugs and unexpected behaviors. That is a natural part of and benefit from creating training materials in the first place. It also provides a good illustration of two fundamentally different ways to look at software development. One is to play it safe and get things done in known ways, and the other is charge ahead, try the unknown, and see what happens. Damn the torpedoes, bugs are a benefit. No bug reports, no glory. In this post, I will share some recent examples of just coding ahead and breaking thing.

DVCon Europe 2021 – Testbenches, AI, and Open Source

Just like in 2020, the Design and Verification Conference (DVCon) Europe 2021 was a virtual conference. It took place from October 26 to 27, with the SystemC Evolution day on October 28 (as usual). As has been the case in recent years, the verification side of the conference is significantly larger than the design side. This is common with the other DVCon conferences in the world. In this blog, I will go through my main observations from DVCon Europe, and share some notes from some of the presentations.

Microsoft Windows memset Optimization – Stores are Free

I recently stumbled on a blog post called Building Faster AMD64 Memset Routines, written by Joe Bialek of the Microsoft Security Response Center (MSRC). The blog describes his efforts to improve the performance of the Windows kernel memset() function, across all sizes of memory to set. The reported optimizations are quite fascinating, and could be summed by avoiding branches even at the cost of doing redundant stores. Basically, stores are free while branches are expensive.

Jerry Fiddler on the Early Days of Wind River and Building a Product

Wind River is celebrating their 40^th anniversary as a company with a series of historical look-backs posted on the Wind River channel on YouTube. One of the videos is an interview with Jerry Fiddler who founded Wind River back in 1981, by Wind River current CEO Kevin Dallas. Jerry Fiddler talks about how he got started in computers, and especially about how Wind River got started and grew. It is both a fantastic set of historical anecdotes and some solid product management and strategy insights.

Professor Reinhard Wilhelm on the History of WCET Analysis

Back when I was a PhD student working on worst-case execution-time (WCET) analysis, one of the leading groups researching the topic was the “Saarbrücken gang” led by Professor Reinhard Wilhelm. Last year, Professor Wilhelm published a retrospective look on their work on WCET in the Communications of the ACM. It is a really interesting history write-up from the perspective of the Saarbrücken group.

Renovations and Software

Last year, we spent a significant part of the fall and early winter renovating some aspects of our apartment*. Things like (finally) updating the flooring in the living room, updating the wallpapers, painting the interior staircase white, and changing out all doors. The renovation process provides some interesting analogies to the process or updating an existing software code base – especially in discovering the design decisions of the past and unearthing the layers of legacy that underlies why things look like they do today.

DVCon Europe 2020 – Developing Hardware like Software?

The Design and Verification Conference Europe (DVCon Europe) took place back in late October 2020. In a normal year, we would add “in München, Germany” to the end of that sentence. But that is not how things were done in 2020. Instead, it was a virtual conference with world-wide attendance. Here are my notes on what I found the most interesting from the conference (for various reasons, this text did come out with a bit of delay).

CACM on DSAs

The July 2020 edition of the Communications of the ACM (CACM) had a front-page theme of “Domains-Specific Hardware Accelerators”, or DSAs. It contained two articles about the subject, one about an academic genomics accelerator, and one about the Google TPU. Hardware accelerators dedicated to particular types of computation are basically everywhere today, and an accepted part of the evolution of computers. The CACM articles have some good tidbits and points about how accelerators are designed and used today. At the same time, I also found a youtube talk about the first hardware accelerator, the IBM Stretch HARVEST, showing both contrasts with today as well as a remarkable continuity in concept.

Intel Blog Post: “Quit Thinking and Look” – Mea Culpa Chasing a Performance Bug

I have written before about the debug advice to “Quit thinking and look.” It means that you should not form conclusions prematurely. Stop and look at what is going on instead of guessing and cooking up theoretical scenarios. Sound advice that I completely failed to follow in the case that I just chronicled on my Intel Blog: https://software.intel.com/en-us/blogs/2020/03/18/quit-thinking-and-look-chasing-simics-performance

“Studying the Advancement in Debugging Practice” / 2016 Paper

I find debugging a very interesting topic of study, so when I stumbled on the paper “Studying the advancement in debugging practice of professional software developers”, I had to do a blog on its contents.

More on Programming

My blog post from last week, “Programming for Everyone, Everyone’s a Programmer?,” gave rise to some good comments from friends and colleagues on the matter of programming. Some of the points are worth addressing in a continuation of the discussion. To get the starting point, please read the previous post first.

Programming for Everyone, Everyone’s a Programmer?

Recently, I have read some articles and seen product announcements based on the idea that we need to make programming easier. Making it easier is supposed to make more people program, and the underlying assumption is that programming can be easy enough that everyone can do it. I have also talked computer science undergraduate students who kind of asked me just how many years at the university you should do, and what do you actually in practice gain from a university degree in computer science? When I think about it, these two discussions really come down to the same question: Should everyone be a programmer? Can everyone be a programmer? What does it mean to be a programmer? How do you best learn to program?