thoughts on Computing and Truthing
Often when we consider a type system we think about a complex formalism to denote the semantics of a language. Languages typically add features by increasing the complexity of the type system.
But there is also another perspective on the type system: how does the generated code look like? what is the ABI for the code that uses different features of the type system? We’ll try to explore this perspective in this blog post.
To use or not to use exceptions? That is the question. Asked again.
In the previous post we explored the performance implications of various error handling mechanisms. Here we continue our exploration of error handling mechanisms but focusing on modifiability – i.e., the ability of the code to be easy to write and be modified in the future.
We argue that exceptions are both a good thing and a bad thing. We attempt to divide the scenarios into multiple categories, and we provide reasons pro and con for each category. The goal is to find the contexts in which it’s better to use exceptions. The answer may be surprising: there are more cases in which manual error handling is better than using exceptions. If only standard library would support non-exception policies…
To use or not to use exceptions? That is the question.
And if you have hoped for a simple answer, this is not the right blog to read. On this blog, finding the truth is always a complex endeavor, it involves a complex mix of perspectives and a variety of interpretations. If you are into truthing, read on.
In this post we would only cover the performance aspects of it. A follow up post should discuss aspects like modifiability (how easy is to write error handling) and appropriateness of using exceptions.
In the last post we shown how important data manipulation can be in the efficiency of programs. More specifically, we shown that in some cases, the data access is much slower than the instructions we run on the CPU side. The last post was a show-case for data-oriented design (DOD).
But we can turn the problem upside down, and ask ourselves: assuming data layout is optimal, can we add more CPU instructions to be used while waiting for memory? The answer appears to be yes, within some limits.
This is not a show-case of data-oriented design; rather it’s an exploration inside the realm of DOD, to investigate some finer points of DOD. And, compared to last post, we venture outside of game industry to emphasize the point that DOD techniques can be applied in other industries as well.
Data-Oriented Design (DOD) is an approach of solving computing problems that require efficiency with an emphasis on the data. It was made popular by Mike Acton with his highly acclaimed talk Data-Oriented Design and C++ at CppCon2014. If you are a programmer and you haven’t seen the video yet, please do yourself a service and watch it (embedded below).
Over the course of time, I started to believe more and more in this approach. But a belief is just a belief, so in accordance with the goals of this blog, I need to move it towards true-belief and then to truth. This post is about adding evidence to support Data-Oriented Design.
