The purpose of this site is solely shameless self-promotion. The author acknowledge this and, also, promise to learn better English.

I do reference Microsoft systems or environments a lot because I work with them. Please, understand that (most of the) concepts are not the sole property of Microsoft, they are universal and you will surely find equivalent technology on "other implementations and platforms". If not, you can always start your own implementation and share it to the world…

Adopt it !

I write this text during a long and tedious full recompilation. I work on a mid-sized project in c++, it uses a lot of libraries. It was developed by a team of 10-15 programmers for about 3 years now.

So, recompiling the BIG thing would take half an hour. Recompiling the biggest project takes about 8 minutes. So we tried Incredibuild but somehow we had an incompatibility with a set of libraries. In theory, Incredibuild should speed up compilation by a big factor but in practice, it was more 20 or 30% improvement.

People really loved it in the beginning and then hated it in the end. Some person were talking as if it was the new messiah, other person would argue he would never need it, ever.

In the beginning: I have seen too fast adoption for a technology that might not suite us and too fast rejection without even giving it a chance.
In the end: From the non-skeptical, some would reject it without even identifying the cause of their problem…

But only few really considered what technology could bring to them…

The theory of cool

Some think I am a fool but I find programming amusing. I even enjoy it.

So, today I was thinking, when I start on a project, what should be the priorities ? a) Do it reliable, quick and clean b) Do it under the constraint c) if time, optimize it

But if I think about the cool factor, then it goes the other way around : a) Do it the optimized way b) do it reliable c) the constraints d) clean

Do you see the issue ? good code != cool code

STL is thread-safe; but thread-efficient ?

I will never repeat it enough: In today's world: only hard parallelism and strong concurrency count. Get it? And if you ever doubt about it, just repeat it 10 times it will help to understand.

For the concurrency dreamer, splitting K operations relatively independent operation over N process unit would take the same time than K / N operations.

But in the real world, sometimes, concurrency can fuck up badly can be a problem… I got across a beautiful case of K * N operations; but why ?

The enemy

As a programmer, I often thought my enemy number one was "clumsy dirty complex code". Complex code is fragile and capricious. It takes long time to understand what is explicit, and even more time to figure out what is not.

But I was wrong, the real enemy is the twisted mind over abusing the wide creativity offered to them. While most human will make their path in a decent way, some always try the alternative path.

They always have good reason to do so… For this reason, when a programmer design a system he should take care of restricting the scope of possibilities. When you think a system, you think of a single possible way to do it.

Ninja programming

You surely know about cow-boy programming, solitary programmers making his own path and following his own rules… The lonesome programmer could communicate with the world, but the world would not understand why, exactly, his ideas are from superior beings. A true cow-boy programmer brings along attitude: never be nice… never be kind… This is the far west you know…

This week I met, against his will, a 'ninja programmer'. Ninjas operate by night, covered in black, do their assassination task and then escape like magic. A ninja programmer is sent in mission (it means deep in the code) for some special action (read hacks).

The problem with code is that it does not work that well

The always 100% complex

Since you recently became a true master in the Mighty Art of Parallelism, you are not afraid to work with multicores-multiprocessors-multithreaded-massively-parallelized-distributed systems. All your applications are bug free; optimized and lets say it frankly: DAMN FAST!

Looking at your operating system task manager, you see, with horror, that your application is NOT using 100% of CPU… How come? How come? Agony… your specialized -state of the art- algorithm is being sub-optimal…

Wait a minute, welcome to the tedious task of (why not) 100% CPU usage


You want performances. We want performances. They want performances… More more more…

For this reason, god sends us multithreading. The problem is: it is easy to implement; it is hard to get right, it is hard to debug; it is hard to prove your program is correct…

So here is my 2 cents over multithreading

Very first entry

Warm welcome !

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License