Monday, April 4, 2016

Resolution of historic photographs in examples, part 2

In my previous post I explored one of the smallest and oldest glass plate negatives in our archive to show it has resolution at least 2000PPI (or 40 line pairs per millimeter, lp/mm) which correspond to 80-90 megapixel photograph. This noticeably exceeds the published estimates of resolution of historic film.

This time I take a detailed look on one of largest negatives in our collection - a monster plate 30x40cm. The photograph was taken by my great-great-grandfather and/or great-grandfather in 1903 documenting the construction of the first electric railway in the Austro-Hungarian empire by František Křižík ("Czech Edison"). This unique event was recorded in a series of photographs prepared by the best technology available to a photographer of Czech countryside. While the glass plate I am going to speak about may be considered one of the more boring in the series it shows some extra-ordinary detail.

Sunday, March 27, 2016

Resolution of historic photographs in examples, part 1

As everyone knows, historic photographs are full of lovely and important details. Well, at least everyone who had paid enough attention to explore an original or had chance to see a quality scan. In 19th century photographs was not enlarged and the prints matched the size of negatives. Even small CDVs was intended to be viewed with care under a magnifying glass.

Friday, March 25, 2016

Lost notebook

My lovely notebook Lenovo X240 Serial Number PF0088FT was lost in Prague, Mar 24 2016. If you find it and contact me at, I would be extremely grateful.

Friday, March 18, 2016

Building libreoffice with GCC 6 and LTO

New GCC is just around the corner. For me, as a GCC developer, this means a period of bugfixing, benchmarking and fine-tuning. Two years ago I wrote about my experiment  of building libreoffice with link time optimization (LTO). At that time LTO just got into shape of being able to build such large applications. Since that I am keeping my eye on this and try to be sure LTO keeps improving. I did not have time to publish any tests for GCC 5. Here is update for current trunk of GCC 6 compared to GCC 4.9.0, GCC 5.3, LLVM 3.5 and trunk.

Sunday, April 12, 2015

Link time and inter-procedural optimization improvements in GCC 5

GCC-5.1 release candidate 1 just branched. Lets take a look what changed in the inter-procedural optimization (IPA) and link-time optimization (LTO) frameworks.

Thursday, September 18, 2014

Devirtualization in C++, part 7 (Enforcing One Definition Rule)

This time I am going to write about a feature that I implemented as a side effect of the devirtualization machinery: the verification of One Definition Rule on types.

One Definition Rule (ODR) is one of more interesting cases where C and C++ differs in very subtle way. Wikipedia describes it as follows:
In short, the ODR states that:
  1. In any translation unit, a template, type, function, or object can have no more than one definition. Some of these can have any number of declarations. A definition provides an instance.
  2. In the entire program, an object or non-inline function cannot have more than one definition; if an object or function is used, it must have exactly one definition. You can declare an object or function that is never used, in which case you don't have to provide a definition. In no event can there be more than one definition.
  3. Some things, like types, templates, and extern inline functions, can be defined in more than one translation unit. For a given entity, each definition must be the same. Non-extern objects and functions in different translation units are different entities, even if their names and types are the same.
Some violations of the ODR must be diagnosed by the compiler. Other violations, particularly those that span translation units, are not required to be diagnosed.[1]
This means that C++ type names are global and should not be re-used in different ways in different source files. (In C doing so is perfectly valid and common, types across units are considered equivalent if their structure is.)

One of motivations for ODR is to make name mangling possible. Type names are used, for example, as program wide identifiers to distinguish functions and methods of same name but taking different types of arguments (function overloading):
struct A {int a;};
int getval (struct A a) {return a.a;}
struct B {char a;};
int getval (struct B a) { return a.a;}
This compilation unit will result in exporting two function symbols:  _Z6getval1A and _Z6getval1B. A and B comes from name of the argument's type.

Now, obviously, if another unit defines completely different structure A and completely different getval taking it as argument, the function will also be called _Z6getval1A and things will fail miserably. General violations of ODR can not be diagnosed by compiler working on single translation unit in isolation. If one is lucky, ODR violation turns into linker error about duplicated symbol name. With presence of inline functions however this will not happen and one of the two functions will be eliminated from program. This may result in invocation of a function on wrong data crashing program in random ways.

Tuesday, September 9, 2014

Linktime optimization in GCC, part 3 - LibreOffice

After Firefox, I decided to look into LibreOffice performance with link time optimizations (LTO) and profile feedback (FDO). This post was in works since April, so my setup is not exactly bleeding edge - GCC 4.9.1 prerelease, LLVM 3.5 and LibreOffice checkout from April. Some real world issues (like a wedding) interrupted my work, however the data presented should be still relevant and interesting.