Home » Blog » Tags » advanced

advanced

Monads in Chains - Ivan Cukic @meetingcpp 2014

By Meeting C++ | Jan 1, 2015 06:28 AM | Tags: performance intermediate functional programming functional experimental efficiency c++14 c++11 advanced

Ivan Cukic gave a very good talk on monads at Meeting C++ 2014:

Monads in Chains

by Ivan Cukic

From the talk description:

Monads are scary, and monads are evil. But they are still useful.

In the recent years, the abuse of multi-threading has become apparent and more and more systems started being developed in the reactive, or event-processing style. It allows lowering the number of threads to match the system cores instead of items that are being processed by using non-blocking asynchronous APIs.

Tutorial on Tag Dispatching -- Crazy Eddie

By Blog Staff | Dec 16, 2014 08:24 AM | Tags: metaprogramming advanced

Fresh on Crazy Eddie's Crazy C++ (fortunately not entirely true...):

Tutorial on tag dispatching

by Crazy Eddie

From the article:

... There’s been some confused notions passed around recently that lead me to think there needs to be more information about probably one of the simplest, most powerful metaprogramming techniques that exist in C++: tag dispatching. The reason tag dispatching is powerful is that it leverages the language and the compiler to do work for you so that you don’t have to. It’s a technique whereby you use overload resolution rules to decide between otherwise ambiguous functions.

Concepts and tags

The first part to understand with regard to tag dispatching is the idea of “concepts”...

A Tiny Metaprogramming Library -- Manu Sánchez

By Jordi Mon Companys | Dec 16, 2014 04:53 AM | Tags: template metaprogramming metaprogramming community advanced

Manu Sánchez is proposing a little-big collaborative challenge to the C++ community. Learning how to build:

A Tiny Metaprogramming Library

by Manu Sánchez

The proposal:

I hope you like this idea. It’s not only me writing crazy meta-stuff, but everybody developing their own metaprogramming library, learning something new each week, and comparing the different approaches each one is taking. I’m the guy who writes this posts, but I can learn a lot with your Tiny Metaprogramming Libraries and your feedback.

 

Bring named parameters in modern C++ -- Marco Arena

By Marco Arena | Dec 16, 2014 01:06 AM | Tags: c++14 advanced

I’m going to explore some of the classical ways to emulate named parameters in C++ as well as mention new approaches. Part of this work would not have been possible without Davide Di Gennaro's help and suggestions. An entire paragraph was written by Davide.

Bring named parameters in modern C++

by Marco Arena

From the article:

In programming, named parameters refer to a computer language’s support for function calls that clearly state the name of each parameter within the function call itself.[...]Several languages support named parameters (e.g. C#, Objective-C, …). C++ does not.[...]In this post, I’m going to explore some of the classical ways to emulate named parameters in C++ as well as mention new approaches.

Continuation Passing Style -- whanhee

By ltorje | Dec 8, 2014 10:40 AM | Tags: advanced

In case you missed it, from Functional C++:

Continuation Passing Style

by whanhee

From the article:

Continuation passing style (CPS) is a method of programming which allows for intricate manipulation of control flow while still maintaining functional purity.

Continuations can be used to implement a whole range of things from exceptions to coroutines, but today we’ll just introduce them and a few interesting and useful concepts...

As summarized in Wikipedia: "continuation-passing style (CPS) is a style of programming in which control is passed explicitly in the form of a continuation."

 

 

Quick Q: Is an acquire_release fence enough for Dekker synchronization?--StackOverflow

By Jared Mulconry | Dec 2, 2014 11:25 PM | Tags: c++11 advanced

Quick A: No, because acq_rel doesn't prevent reordering a store to x followed by a load from y... seq_cst does.

Recently on SO:

Why isn't a C++11 acquire_release fence enough for Dekker synchronization?

The failure of Dekker-style synchronization is typically explained with reordering of instructions. I.e., if we write

atomic_int X;
atomic_int Y;
int r1, r2;
static void t1() {
    X.store(1, std::memory_order_relaxed)
    r1 = Y.load(std::memory_order_relaxed);
}
static void t2() {
    Y.store(1, std::memory_order_relaxed)
    r2 = X.load(std::memory_order_relaxed);
}

Then the loads can be reordered with the stores, leading to r1==r2==0.

I was expecting an acquire_release fence to prevent this kind of reordering:

static void t1() {
    X.store(1, std::memory_order_relaxed);
    atomic_thread_fence(std::memory_order_acq_rel);
    r1 = Y.load(std::memory_order_relaxed);
}
static void t2() {
    Y.store(1, std::memory_order_relaxed);
    atomic_thread_fence(std::memory_order_acq_rel);
    r2 = X.load(std::memory_order_relaxed);
}

The load cannot be moved above the fence and the store cannot be moved below the fence, and so the bad result should be prevented.

However, experiments show r1==r2==0 can still occur. Is there a reordering-based explanation for this? Where's the flaw in my reasoning?

New optimizations for X86 in upcoming GCC 5.0 -- Evgeny Stupachenko

By Razvan Pascalau | Dec 1, 2014 07:11 AM | Tags: performance gcc efficiency compiler advanced

Fresh on the Intel Developer Zone blog:

New optimizations for X86 in upcoming GCC 5.0

by Evgeny Stupachenko

From the article:

Part 1. Vectorization of loads/stores group.

GCC 5.0 significantly improves vector code quality for load groups and store groups. By loads/stores group I mean iterated consecutive sequence of loads/stores. For example:

x = a[i], y = a[i + 1], z = a[i + 2] iterated by “i” is loads group of size 3

...

The most frequent case where loads/stores groups are applicable is array of structures.
  1. Image conversion (RGB structure to some other) ...
  2. N-dimentional coordinates. (Normalize array of XYZ points) ...
  3. Multiplication of vectors by constant matrix: ...

... GCC 5.0:

  1. Introduces vectorization of load/store groups of size 3
  2. Improves load groups vectorization for all supported sizes
  3. Maximizes load/store groups performance by generating code that is more optimal for particular x86 CPU...