This follows on from the previous post – here are the plots.
These are based on a run of the PARSEC benchmark suite x264 program – encoding 32 frames of video using 18 threads – 16 worker threads: the plots show how often each 16 byte “line” is used – whether as an instruction is read or the memory is used for read-write storage. Sixteen bytes is both the size of a typical cache line and a read from a DDR memory.
The code plot might suggest there is some pattern – between about segments 100 (offset 0x640 inside the page) and 200 (offset 0xC80) there is an increased hit rate) but my guess is that is an artefact of the particular code being used here, rather a general issue (possible explanations would be a particular library function being very heavily used): though conceivably it could be an issue with the GCC compiler or linker.
That might be worth further exploration, but not for me. From visual inspection I am concluding that the distribution of accesses inside a 4k page doesn’t justify trying to pre-cache particular 16 byte “lines”.
It’s a long time – over a decade – since I last used a Microsoft development tool. For what it’s worth, I quite liked Visual C++ back then, but in the middle of my subscription (in 1998 if I remember correctly) Microsoft just tore up the contract and offered me something of less use. The details escape me now but it was a formative moment – I was not willing to trust them any more and suddenly the idea of using Linux had new appeal.
Today the world seems very different. But if Microsoft have taken a few knocks and people are almost as likely to think of Apple and even Google as the enemies of software diversity and freedom, we should not underestimate its raw power in the market. Most desktops in most workplaces are still Windows boxes and writing for the mass market means targeting Microsoft’s operating system.
Not surprisingly many, probably most, of the people who are doing that are using Microsoft’s tools and compilers. That gives the boys and girls in Redmond a lot of power and they don’t have to be acting in a malicious way to have an detrimental impact – as in their refusal to support the C99 language standard. The only mantra that C is a proper subset of C++ (which Microsoft fully support) has been dead for a few years now and there are features in C99, which is the standard in general use in the Unix/Linux development world not supported in C++11 (the current standard there which Microsoft are working to support). Microsoft do support the twenty year old C90 standard but have essentially said that they are not going to develop that any further – you can read more about this here.
In response to this some C++ developers have done so far as to say “C is obsolete” – perhaps reflecting a new confidence in the C++ development world, as that language has been making something of a comeback in the last couple of years (not least because Microsoft have promoted it so heavily).
That may or may not be the case – personally I doubt it very much. But since when did we allow tool manufacturers to make that decision for us?
As I did in 1998 maybe it is time for the developers to look at the alternatives. There are plenty of industrial strength compilers and editors out there that will free them from the caprice of a company which is once more demonstrating it just doesn’t get it.