Unpredictability of execution times

I have written an article on intrinsic randomness of modern CPUs that you can fetch here. Originally, I tried to publish it in LWN, but since I haven't heard from their editors in over a week, I'm publishing it this way.

A tricky bug

Today I debugged a piece of code that looked like this:

printf("foobar\n");
if(fork() == 0)
  exit(0);

When the program is run from the terminal, the output is as expected: a single line containing "foobar". However, when the output is sent to a pipe or redirected to a file, two lines appear in the output. (Actually, the problem was a bit more complicated: there were n fork() calls and there were exactly n additional copies of the output). After a bit of digging around and not finding any obvious fault, I asked about it on IRC.

It turned out that stdout is fully buffered when it is attached to a pipe or a file. What happened is that fork() duplicated also the internal I/O buffers, which got flushed after the child process exited, thus producing extra output. I solved the problem by inserting a fflush(NULL); statement before forking, which flushes buffers of all output streams.

Foxit PDF reader -- no go

Today I tested the Foxit PDF reader, version 3.1, since many people recommend it as a faster and lighter-weight alternative to Acrobat Reader. Well, its performance is disappointing: opening a 3MB PDF with Foxit takes 2-3 seconds before the first page is displayed. Opening the same PDF with Acrobat Reader (version 9.1) displays the document with no delay at all. I attempted to open few other PDFs with Foxit, with the same result: annoying pause before I could view the document, but with Acrobat Reader showing the document immediately.

So long Foxit, Acrobat Reader is still my favorite PDF reader.

Unexpected behavior of std::bitset in visual studio 2008

I was writing code for generating prime numbers up to 10^9 (one billion) by sieve of Erathosthenes. So I created a class containing a member of type std::bitset<1000000000> and created an instance of the sieve class within the main function (i.e., allocated on the stack).

When I ran the program, it crashed with stack overflow. Since VC in debug mode implements stack overflow checking, the stack trace was not very helpful -- the program crashes within the _chkstk function. But in my simple test program, the only possible cause of stack overflow could be the instance of the sieve class which contains the bitset member. After lowering the sive's limit to 1000, the program worked fine. It was kinda surprising to learn that std::bitset, unlike std::vector, internally uses an array instead of dynamically allocated storage. (I confirmed this conjecture also by reading the source code of in the corresponding header file.)

OODraw align nonsense...

I've been drawing some diagrams and I attempted to align (center vertically) several objects using one object as the reference object that should not be moved. But OODraw does not offer such feature; what it does instead is to align the selected objects using their bounding box as the reference, which is completely useless. A workaround is to "protect" the size and position of the reference object and then invoke the align command... which are few unnecessary extra clicks here and there. Stupid, stupid, stupid program!