Hi, I'm Tomasz

Recently, while exploring Python’s code base I stumbled upon these cryptic lines in its build system. I’ve never used profile guided optimisations before so, that led me into a goose chase to learn more about them. This post is about how to use clang to employ these optimisation techniques in practice and how much performance gains can be achieved (if any).

What’s profile guided optimisations (PGO)?

The main principles behind PGO can be described as:

I’ve recently watched a video from TheCherno about visual benchmarking.

In short, he’s using a simple timer class in C++ to collect execution timings of his code and then generate a json file containing profiling data which can be visualised using chrome tracing.

He’s using a set of macros to automatically get function names when instrumenting the code.

This gave me an idea to actually use gcc instrumentation to inject the timers globally into the entire program and collect the data without having to manually instrument the code. Additionally, I’m gonna experiment with LLVM Xray instrumentation which makes the whole process even more simpler.

I’ve recently stumbled upon an article about a “modern” C development environment. It caught my attention; sounds like a good read and potentially a way to learn something new and refresh the good old rusty C skills, so I thought. Unfortunately, it was quite to the contrary, leaving a bitter taste at the end. There’s a lot of stuff I disagree with and frankly some that should be killed with a shovel and buried deep in the ground before it spreads like a disease and make C development even more miserable than it already is.

As it’s probably obvious by now, I’m not a fan of CMake. I don’t like the weird syntax, the verbosity of the language, the flawed concept of multistage build system generation and external dependency management which seems like an after thought.

I can’t deny though, that CMake is very popular and has a lot of traction so, it’s the necessary evil until we all, as an industry, decide on some other solution.

Some time ago, I wrote a piece about CMake. It was more of a rant, written in the heat of the moment, after being frustrated by some of CMake’s idiosyncrasies. Ironically, it has become one of the most read posts on this blog, which is a bit disappointing. I would like to believe that there are far more interesting and useful posts available here but it is what it is.

My concluding issue in that post was related to dependency management between a set of CMake projects which comprised a “stack”. Recently, having to work with cmake once again, I’ve discovered CMake’s ExternalProject - which mitigates that problem significantly.

This post is part of a WebAssembly series focused on WASM and C++. The goal is to gain a thorough understanding of how WebAssembly works, how to use it as a compilation target for C++ code and hopefully have fun along the way. So, stick with me for this exciting journey.

Recap

In the previous post, I’ve compiled Lua interpreter to WASM using emscripten and successfully run it using node. There was a problem running the same code in the browser as blocking IO is not possible. Today I’m gonna try to address this issue and run Lua interpreter in the browser.

This post is part of a WebAssembly series focused on WASM and C++. The goal is to gain a thorough understanding of how WebAssembly works, how to use it as a compilation target for C++ code and hopefully have fun along the way. So, stick with me for this exciting journey.

Recap

In the previous instalment of this series, we’ve learned that WASI is an interface enabling exposure of system APIs to WASM modules. WASI is implemented by all relevant WASM runtimes; I’ve also provided an example of what needs to be done to implement WASI polyfills by hand and how to use more mature and complete implementation of WASI polyfills in the browser.