Exceptional exploration (2)

Exceptional exploration (2)

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…

read more

Exceptional exploration (1)

Exceptional exploration (1)

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.

read more

In the search of CPU free lunch; a DOD perspective

In the search of CPU free lunch; a DOD perspective

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.

read more

Data-Oriented Design and efficiency

Data-Oriented Design and efficiency

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.

read more

Why do we need to go meta?

Why do we need to go meta?

This post is inspired by the blog post Why physicists need philosophy. Richard Healey, the author of the post, rightfully argues against the mainstream belief among top physicists that physics has an answer for everything. He argues that philosophy is still needed to answer some of the aspects that physicists are still unable to answer. Stephen Hawking is so wrong when he considers philosophy to be dead.

read more