Utilizing Intel® AVX with Cakewalk SONAR X1

This is a whitepaper which I co-authored with Intel engineer Rajshree Chabukswar, highlighting the advantages of optimizing for the Intel AVX chipset, with a focus on digital audio processing in a modern DAW like SONAR X1.

We’re excited with our synergetic relationship with Intel, which allows us to take  advantage of their bleeding edge technology in ways that directly beneft our users, allowing them to squeeze the most power out of their systems. While the paper is technical and requires an understanding of some low level programming, it also offers insight into the nuts and bolts of whats involved in optimizations for Intel CPU architectures in a modern DAW.

The paper features a real world case study of SONAR X1 code that was optimized in to take advantage of the benefits of the 256 bit AVX instruction set. If you have an Intel CPU from the Sandy Bridge processor family, it supports AVX and SONAR X1 will take advantage of it.
(While AVX is an Intel instruction set, it has also been adopted by AMD will be available in their upcoming Bulldozer processors. )

Code which is optimized for AVX  vectorization capabilities can work with 256-bit vectors, allowing working on 8 32-bit floating point values per iteration. In other words, this is twice the data throughput of earlier SSE instruction set! While this doesn’t necessarily translate to twice as fast, it is a huge step up in performance in many cases as the white paper illustrates.

The first step in any optimization task is what is referred to as “hotspot analysis”. In this phase you identify the bottlenecks in the code or that would benefit most from AVX optimization. We did analysis running through stress test projects and workflows that showed some classic hotspots. Once these were identified, the code was AVX optimized using the new AVX intrinsics available in Visual Studio 2010.

Click below to read the paper or download the PDF from Intel’s site:
Utilizing Intel® AVX with Cakewalk SONAR X1

[ Additional credits to Keith Albright and Bob Currie from Cakewalk, for hotspot analysis, development, and troubleshooting ]

OK that sounds like an oxymoron. A crash, good? Thats crazy talk!
Well maybe not quite that crazy – read on to find out why…

Why would anyone actually want their app to crash you may ask? To answer that question lets cover some background about why applications crash on Windows (or any OS).
An application crashes when it performs an unexpected operation or encounters what is called an “exception condition”. Exceptions include unwanted operations like writing to invalid memory locations, divide by zero errors, page faults, etc. Programs can end up with exceptions like this for a variety of reasons:

•  bugs in the progam code 
•  bugs in loaded DLL’s which share the same memory and address space as the host application. You frequently encounter dll’s via plug-in’s in applications (eg. loading a VST in an audio application or a imaging plug-in in Photoshop)
• bugs in the operating system

Normally when an error like this occurs, Windows will display the familiar error message “This Program Has Performed an Illegal Operation and Will Be Shut Down” and the program will close. Some applications like SONAR handle such errors more gracefully and will even try and intercept these exception and attempt to allow the user to save their work before exiting the program. Additionally on Windows you can choose to save what is called a Minidump containing “post mortem” debugging info that is very useful to developers to find out why the program crashed.

How to make your application crash gracefully on 64-bit Windows

Recently we began noticing a pattern where we were receiving Minidump’s from crashes on from 64 bit Windows systems X64 where the dumps contained useless or apparently invalid information about the crash. This made it very hard for us to diagnose such issues. I was even able to reproduce this by writing a simple test application that forced a crash. In one case I found that the crash was reported in a completely different location and in another the application behaved as if the exception didn’t occur!

The scenario above is is actually very bad from both a users and the developers point of view,  since when damage is done to a running application the best scenario is to actually shut it down or risk data corruption or worse damage. So you really WANT your app to crash when something like this happens. I logged a bug with Microsoft about this issue using a test application. I recently heard back from their developer support about this issue. It turns out to be an interesting problem that Microsoft is aware of and have issued a hotfix for.

Here is a link to a Microsoft blog post describing this problem in gory detail if you want to read more about it.
And here is the link to the hotfix  if you want it now. This hotfix will also be rolled into Windows 7 SP1. I hope that this is not required in the final version but currently the fix requires you to set a value in the registry to enable it.