There are several users of the Vc library who are interested in writing their code in such a way that it can be compiled with and without Vc.
Consequently, all the application logic must be stated in generic terms, which can work equally well with
T as with
Vc::Vector<T>. This works pretty well, since
Vc::Vector<T> implements the same operators with the same semantics as
T. However, there are consequences for how you state masked assignments and mask reductions.
Loads and stores are the main bridge between the vector and scalar worlds. (Gather, scatter, and subscripting are the small and slow bridges.) Using a load instruction you can efficiently copy WT scalar objects (stored contiguously in memory) to one vector register. Store instructions do the reverse. This is a really simple concept, so why bother a discussion?
Yesterday I finalized the 1.2.0 release of the Vc library. I recommend everyone on Vc 1.1 (or earlier) to update. The operator semantics are stricter, i.e. more correct, in the new release. So you'll catch bugs in your code earlier. Also, I worked a bit on the reference documentation for
SimdArray, so if you ever wondered about that new class or were actually still searching for a type with user-defined element count, now you have reference documentation.
Today, the Green IT Cube at GSI Darmstadt was inaugurated. This building has six floors, each of them designed for housing server racks with up to 2 MW (that's roughly 1000-2000 GPU compute nodes) of power usage. That's a total of 12 MW on a surface area of only 900m². The energy overhead for the cooling systems in the commissioning tests were only 2%, with a theoretical maximum overhead of 7%.
Since my last papers were all discussed in SG1 (the study group on concurrency) of WG21 (the C++ committee), the focus was on the concepts and overall direction of data-parallel programming with C++. After SG1 gave its go-ahead for expressing data parallel execution via the type system, the proposal needs to go to LEWG (library evolution working group) next. They will look at the API details and focus much more on getting wording ready for a TS (technical specification - experimental release of things that might go into the next standard).
Travis, the popular CI tool for C++ projects on GitHub, enables continuous builds with nice integration to GitHub. But it lacks a good look into the build and test logs. Especially if you run tests with ctest, the default output of tests will not show the executables output in the Travis logs. On the other hand, running everything with full verbosity makes finding the interesting information on Travis logs tedious.
At work I recently got a new notebook for working remotely (e.g. business trips). At FIAS I had to choose a single machine for all purposes, so I chose a portable workstation (HP EliteBook). That thing was heavy, loud and not as stable to use as a dev machine with Linux as I had hoped. Now I finally have a desktop system for the day to day work, and a light notebook for remote work.
Just a quick post to let you know that I have a blog again. After my last blog died with the server move to Darmstadt and the blog software was discontinued, I have not found the time and energy to set up a new blog. One major obstacle was my wish to recover the old blog posts with the new setup. I dropped that request for now and just want to get going again. Maybe I'll "reblog" some of the old content, but no promises at this point. The web archive can be at least a good start if you're still looking for something I posted back in my KDE days.