Franz's blog

Franz's picture

Workaround for Visual Studio's infamous error C2719

In Visual Studio 2005, 2010 and possibly many other versions, whenever you try to store aligned data structures into a std::vector you'll get the following error:

error C2719: '_Val': formal parameter with __declspec(align('16')) won't be aligned

Here's a code snippet that triggers this error:

#include <vector>

struct __declspec(align(16)) S
{
    int x;
};

int main()
{
    std::vector<S> v;
    return 0;
}

This is a well known and well documented issue in Visual Studio's implementation of the STL library.

The common workaround seems to revolve around dropping std::vector in favor of some kind of custom container that doesn't have this problem.

I found another workaround that I didn't see mentioned elsewhere: templatize the data structure that requires alignment. Here is an example that compiles and appears to work correctly:

#include <vector>

template <typename>
struct __declspec(align(16)) S
{
    int x;
};

int main()
{
    std::vector<S<void>> v;
    return 0;
}

Obviously the template parameter isn't used and can be set to anything.

Update Feb. 22, 2012: It's not so simple. The dreaded C2719 error may appear again if the type (S<void>) was instantiated earlier in the translation unit, but this will also depend on the bitness (32-bit vs. 64-bit), the alignment value and probably the size of S<void>. To summarize:

Type instantiated earlier? Bitness Alignment Result
No Any Any OK
Yes 32-bit 16 bytes C2719
Yes 32-bit 32 bytes C2719
Yes 32-bit 64 bytes C2719
Yes 64-bit 16 bytes OK
Yes 64-bit 32 bytes OK
Yes 64-bit 64 bytes C2719

Yuck.

Update Feb. 23, 2012: I outlined a more robust solution in this post on StackOverflow.

Franz's picture

DTrace in Rendering

I've grown to really enjoy Bryan Cantrill's way of doing talks and presentations. He's got an incredibly lively way of speaking and demoing stuff which invariably makes for an interesting show, pretty much regardless of the topic.

Most of Bryan's talks are about DTrace since it's what he spent most of his career building. DTrace is a very impressive tool that allows live introspection of software systems. Basically, the operating system (or any piece of software running on it, really) can be instrumented beforehand with so-called DTrace probes. These probes can be activated and queried at runtime in various ways using short programs called D scripts.

A key idea in DTrace's design is that these probes don't incur any performance penalty when they're not used (technically a probe is just a few bytes of no-ops that allow live-patching of the code later). So a software product can be built and shipped with a ton of probes: in normal production time they won't impact the performance of the system, but they'll allow debugging and deep introspection if the system starts to behave incorrectly or if performances drop, all this without having to take the system down.

Clearly this kind of deep performance introspection facility would be a great tool to form a precise idea of what is really going on under the hood of a renderer. For instance, it would allow querying the performances of the texture or geometry cache, measure the ray throughput, etc. It would be a fantastic tool to understand the complex behavior of the renderer, discover bottlenecks and debug performance problems.

How naive of me was it to think this was a novel idea! I quickly discovered that PBRT, the renderer described in Matt Pharr and Greg Humphreys' Physically Based Rendering book, already ships with several DTrace scripts.

I wish we had that in appleseed. Maybe an interesting project for someone whose interests are at the confluence of system programming and rendering performance!

Franz's picture

Welcome to the arena, Mitsuba!

I learnt yesterday (in a post on the ompf forum) that Wenzel Jacob has just released Mitsuba, an impressive, feature-packed physically-based renderer. The full C++ source code is available.

Obviously Mitsuba has many more features than appleseed and, I believe, is generally more advanced. What strikes me though is the similarity, both in the philosophy and in the realization, between Mitsuba and appleseed. From what I could gather:

  • Both are large, platform-independent C++ frameworks aiming at supporting a variety of rendering algorithms (called "integrators" in Mitsuba, inheriting the term from PBRT).
  • Both are aiming at generality and robustness.
  • Both provide a Qt-based graphical user interface and a command line tool.
  • Both feature a scene description language based on XML (and Mitsuba also seems to use the heavy-duty Xerces-C XML parser that's also used in appleseed).

Massive congrats to Wenzel for pulling this off. I'm definitely looking forward to see where Mitsuba will be going in the future.

Franz's picture

How Much Code Coverage?

A short and sweet tale about code coverage in unit testing, published yesterday on Google Testing Blog.

Generally speaking, this blog is worth following.

Franz's picture

Acquia Drupal Modules

The open source software company Acquia provides a nice, coherent Drupal distribution called Acquia Drupal. I didn't start off with their distribution, but it turns out I installed the same modules, effectively making the Drupal installation on appleseedhq.net a subset of Acquia Drupal.