TensorFlow Serving

“Machine learning powers many Google product features, from speech recognition in the Google app to Smart Reply in Inbox to search in Google Photos. While decades of experience have enabled the software industry to establish best practices for building and supporting products, doing so for services based upon machine learning introduces new and interesting challenges.

Today, we announce the release of TensorFlow Serving, designed to address some of these challenges. TensorFlow Serving is a high performance, open source serving system for machine learning models, designed for production environments and optimized for TensorFlow…”


The missing bridge between Java and native C++

“JavaCPP provides efficient access to native C++ inside Java, not unlike the way some C/C++ compilers interact with assembly language. No need to invent new languages such as with SWIG, SIP, C++/CLI, Cython, or RPython as required by cppyy. Instead, it exploits the syntactic and semantic similarities between Java and C++. Under the hood, it uses JNI, so it works with all implementations of Java SE, in addition to Android, Avian, and RoboVM (instructions)…”


Introduction to the Autotools (autoconf, automake, and libtool)

“This page has information on the “autotools”, a set of tools for software developers that include at least autoconf, automake, and libtool. The autotools make it easier to distribute source code that (1) portably and automatically builds, (2) follows common build conventions (such as DESTDIR), and (3) provides automated dependency generation if you’re using C or C++. They’re primarily intended for Unix-like systems, but they can be used to build programs for Microsoft Windows (this requires some additional facilities, e.g., MSYS, Cygwin, or cross-compilation libraries). The autotools are not the only way to create source code releases that are easily built and packaged. But they’re one of the most widely-used, especially for programs that use C or C++ (though they’re not limited to that)…”


A Probing Hash Table Framework

“Data locality is very important. Keeping data close together in memory is a huge win on basically every modern computing device due to our systems’ inherently multi-level memory hierarchy. Contiguous data leads to speed, and even some perhaps counter-intuitive results (like insert-and-shift into the middle of a dynamic array actually being faster than the equivalent linked list insertion1).

Despite these facts, interestingly enough the C++11 (and beyond) standard library provides a hash table implementation in std::unordered_map that is a separate chaining hash table, with linked list buckets. This implementation implies a strong trade-off: while elements inserted into the map are guaranteed to be stable in memory (never needing to be moved or copied), we now must chase pointers when walking through the buckets in the hash table.

What if we allow for keys to be moved/copied around as the hash table grows? If we relax the requirement that we never move key/value pairs after insertion, we now open the door for implementing a hash table using open addressing. Here, the table is stored as a single huge array containing either a key/value pair or nothing. On an insertion where a collision occurs, an empty slot is located by “probing” through the array looking for an empty slot, following some probing strategy. The most well known is linear probing, which has developed a bit of a bad reputation. But is the disdain deserved?

In this post, I’m going to walk you through some results that motivated the development of an open source (insertion-only) probing hash table framework that’s distributed as part of the MeTA toolkit, and attempt to prove to you that naive, linear probing (or, at least, blocked probing) strategies are not nearly so bad as you might initially think. In particular, we’ll be benchmarking hash tables with both integer and string keys, taking a look at how they perform in terms of building time, memory consumption, and query throughput…”


A Book about Qt5

“Welcome to the online book of Qt5 Cadaques! Why Qt5? Because Qt5 is awesome! Why cadaques? Because one of the authors had a great holiday in this rocky coast line in the north-east of spain.

The entire collection of chapters covering Qt5 programming, written by Juergen Bocklage-Ryannel and Johan Thelin, is available here. All book content is licensed under the Creative Commons Attribution Non Commercial Share Alike 4.0 license and examples are licensed under the BSD license.

We are heavily working on this book and that means several things:

  1. It’s not done. We will be releasing new chapters from time to time and updating existing chapters on the go.
  2. We love your support. If you find any errors or have suggestions, please use our feedback system (the issueslinks). It will create a new ticket-entry in our ticket system and help us to keep track.
  3. Be patient. We are working in our spare time on the book and we depend on the support of our companies and family.



C++11 threads, affinity and hyperthreading

“For decades, the C and C++ standards treated multi-threading and concurrency as something existing outside the standard sphere – in that “target-dependent” world of shades which the “abstract machine” targeted by the standards doesn’t cover. The immediate, cold-blooded replies of “C++ doesn’t know what a thread is” in mountains of mailing list and newsgroup questions dealing with parallelism will forever serve as a reminder of this past.

But all of that came to an end with C++11. The C++ standards commitee realized the language won’t be able to stay relevant for much longer unless it aligns itself with the times and finally recognizes the existence of threads, synchronization mechanisms, atomic operations and memory models – right there in the standard, forcing C++ compiler and library vendors to implement these for all supported platforms. This is, IMHO, one of the biggest positive changes in the avalanche of improvements delivered by the C++11 edition of the language.

This post is not a tutorial on C++11 threads, but it uses them as the main threading mechanism to demonstrate its points. It starts with a basic example but then quickly veers off into the specialized area of thread affinities, hardware topologies and performance implications of hyperthreading. It does as much as feasible in portable C++, clearly marking the deviations into platform-specific calls for the really specialized stuff…”


Reflection in C++14

“A few months ago, I was developing an MVC web framework in C++, mostly inspired by the Ruby on Rails framework. Apart the fact that, like most of the side projects, it’s been a while I haven’t coded any line for this project, it leads me to some interesting problematics.

The problematic that is interesting here and that can introduce this article concerns the configuration of the routes. Indeed, one of the most important feature of an MVC web framework is to configure some routes that the client can request. Each route forward the request to a specific action of a controller.

For example, we can have a /articles route which is linked to the index action of the articles controller. When the client requests this path, articles_controller::index is called and returns a list of the articles.

For my MVC project, I wanted it to be easy to configure the routes and to hide this part from the user. I didn’t want the developer to declare his routes by writing C++ code: it would have been less convenient, less readable and maybe less maintainable…”


Covariance and Contravariance in C++ Standard Library

Covariance and Contravariance are concepts that come up often as you go deeper into generic programming. While designing a language that supports parametric polymorphism (e.g., templates in C++, generics in Java, C#), the language designer has a choice between Invariance, Covariance, and Contravariance when dealing with generic types. C++’s choice is “invariance”. Let’s look at an example.