Disclosure: On this site you won’t find specific advice on “how to call function xyz()”. Interpreting C++ ARM and #pragma dwim is also out of scope.

We’re treating our readers as intelligent beings who can use Google and/or StackOverflow, where all such specific questions were answered more than once.

What you will find is opinions, more opinions, and even more opinions on all the aspects of software development - and with a large chunk of them based on real-world experience too.

Your mileage may vary. Batteries not included.

 

‘Speedy Gonzales’ Serializing (Re)Actors via Allocators

Quote: “Allocator-based serialization for (Re)Actors is extremely fast (for x64 – around tens of ms per 100MB of state)”
Another Quote: “Per-(Re)Actor allocators can be implemented without any changes within (Re)Actor itself (i.e. all the necessary changes can be confined to Infrastructure Code).”
[]

Parallel STL for Newbies: Reduce and Independent Modifications

Quote: “with std::reduce() such code, while it compiles at least under MSVC, MAY occasionally provide wrong results”
Another Quote: “if you happen to need something beyond that – take a deep breath and allocate at least several months to understand how does parallelism really work under the hood.”
[]

#ACCU2018. Day 2. Threads and Locks ARE a Dead End, Period!

As the Day 2 of ACCU2018 is over, here is my report about it. Kotlin ~= Java with a Better Syntax Keynote of Day 2 was about Kotlin (titled “Kotlin/Native – Embracing existing ecosystems”), delivered by Hadi Hariri. While the talk as such was pretty good, I wasn’t convinced that Kotlin is worth the trouble. My takeouts from […]

#ACCU2018 Day 1. From Gender Equality to (kinda-)Quantum Computing, with Threads and C++ copy/move in between

As #ACCU2018 is underway, and as I am here, it would be strange if I wouldn’t use the opportunity to tell about what I like (and don’t like ;-)) here. Diversity in Tech – What Can We Do? Gen Ashley was opening the conference with a keynote speech on “Diversity & Inclusivity in Tech”. Main point: […]

Parallel Coding: From 90x Performance Loss To 2x Improvement

Quote: “as long as serial code provides good-enough response times from end-user perspective – DON’T PARALLELIZE”
Another Quote: “out of all the premature optimizations, premature parallelization is the most premature one”
[]

Using Parallel <algorithm> Without a Clue: 90x Performance Loss Instead of 8x Gain

Abstract: “I made an experiment which demonstrates Big Fat Dangers(tm) of implying that parallelization can be made as simple as just adding a policy parameter to your std:: call.”
Quote: “it is still necessary to understand what we’re doing”
[]