Light Story - Indian wedding photography

Vijesh is one of the few people in my college circle that pursue a real, creative hobby instead of just watching television, even after the marriage. He has worked as a photographer for the Indian edition of TEDx conference as well. He has decided to take up his hobby of photography into a serious second-day-job and is now a Wedding Photographer. Below are two of my favorite wedding photoes taken by him.

His service goes by the name of "Light Story" and he has a shiny wordpress website. Check his website (and also the flickr link from there) for more photoes of Indian weddings.

Personally, from a cup-is-half-empty perspective, I find Indian weddings tedious, unnecessarily expensive and as an event used by [old ] people to compare clothing, jewelry and salaries. Indian marriages bring with it, a lot of fake smiles, falling on the feet of never-seen-before relatives, exaggerated bridal-makeups, ridiculously costly dress purchases, etc.

Indian state of Kerala has the highest literacy rate of 95% and thus is the only state that remains sensible in the marriage ceremonies, by keeping them low profile and short enough to suit the attention span of the current micro-blogging generation. Weddings involve a series of complicated long events in the rest of the Indian states. However, not all is so bad and there are some bright spots among these ceremonies and thankfully not everyone thinks like me. Vijesh manages to identify some subtle beauty in these events and his photoes are a proof of his genius. So, if you know of an upcoming Indian marriage and is searching for a cameraman, I strongly recommend Vijesh.

Pre vs Post Increment & Performance Impact

While browsing across some open-source projects, I have seen code snippets of type:

for (i = 0; i < n; ++ i )

The pre-increment "++ i " confused me as to why one should use it, as post increment is most commonly used. Googling told me that pre-increment is faster than post increment as the value of i need not be stored to a temporary register before the increment operation. This sounded logical to me and I believed it and used pre-increment in all my loops. I didn't bother to measure it though.

Few days back, Kernel developer Tejun Heo complained in twitter about the usage of pre-increment in loops that it doesn't give any benefits and affects readability. This time I got around to doing some measurements with the following code:

 int main()  
 {  
      int i, j ,k;  
   
 #if 0  
      for (i = 0; i < 10000; i++)  
      for (j = 0; j < 10000; j++)  
      for (k = 0; k < 40; k++);  
 #else  
      for (i = 0; i < 10000; ++i)  
      for (j = 0; j < 10000; ++j)  
      for (k = 0; k < 40; ++k);  
 #endif  
 }  

I compiled the above code with 0 and 1 for the #if macro and found that the resultant binaries were bitwise same. So, the preVspost changes contributed nothing for performance as the resultant binaries were exactly identical in either case. So, it's irrelevant if you use post or pre increment for the "for" loop index variable.

I realized that it does not matter if the operation is pre or post increment or assignment, if the value of the expression is not stored at all. So I modified the code to store the return value of the pre/post increment operations and decided to measure the performance. So the code became:

 int main()  
 {  
      int i, j ,k, t;  
   
 #if 1  
      for (i = 0; i < 10000; t = i++)  
      for (j = 0; j < 10000; t = j++)  
      for (k = 0; k < 40; t = k++);  
 #else  
      for (i = 0; i < 10000; t = ++i)  
      for (j = 0; j < 10000; t = ++j)  
      for (k = 0; k < 40; t = ++k);  
 #endif  
 }  

This time I strongly believed that there will be a difference in performance and compiled with the values of 0 and 1 for the #if macro. I did a test run of about 10 iterations for each of post and pre increments. The result was however surprising. Post-increment consistently outperformed pre-increment and finished faster always. I was startled about this observation.

Since so many performance centric people have used pre-increment instead of post-increment in the past, I believed there must be some reason for people using pre-increment. I asked this in a SUSE mailing list for an explanation of the above observation. There are people in SUSE who are as long-experienced with computers as my age. They provided me the answer for this. Earlier, gcc used to generate sub-optimal code for post-increment and that is why pre-increment was used then. Compilers have come a long way and programmers don't need to think in weird way to outsmart the compilers anymore.

C++ and Operator-overloading

With C++, one can overload the increment operator for our own classes. Even though, post outperformed pre marginally, for basic datatypes in C, with the higher-order C++ Classes, it is a different story. I recommend you read this article if you want to know more.

Iterators and modern programming languages

Modern programming languages provide iterators for easier and more effective looping, like foreach in C#. It is always best to use those iterators instead of a traditional for loop and an index variable, to iterate through a collection.

For the sake of curiosity, I tried comparing the post vs pre increment performance in a C# code (just the same above snippet modified to have a public static void Main() etc). I expected that the post will outperform the pre operations and I was right. However, the difference between post and pre increment with the mono C# compiler is substantially high. Post outperformed pre consistently by as high as 2-3 seconds, for the above 3-level nested loop.

Theoretical Micro-Benchmarking & Confirmation of a Tautology

The for loop I used in my example is to highlight the performance difference of pre and post increments. However such micro-benchmarks are theoretical and cannot be extrapolated to match real world scenarios. They are far from it.

It is safe to assume that your application will not become faster by tweaking post or pre increments. So, you can continue to write for loops with post increment which are easier to read and don't appear strange on a contributor/maintenance-engineer's eyes. Most of the slowness in applications are attributed to poor algorithms, bad I/O patterns and doing unnecessary things. Focusing on increment/decrement operators will not give any performance benefits and if you want speed up your applications, begin at Profiling, not at optimizing. As one distinguished engineer once told me, "Optimization without profiling is a waste of life".

Tools Used

• openSUSE 11.4
• GCC Version 4.5.1
• Mono 2.8
• Thinkpad T400 running Intel Core2 Dual CPU

TODO

Understand how to use objdump to look at the assembly instructions baked in the binary and try to figure out why post operations are faster by understanding the assembly code.

Please let me know if you have anything to add for the discussion. 

GNOME vs Canonical, Freedesktop.org - A Neutral Observation & Summary

Few sensational things happened last week in one of the oldest debates of the Linux community, GNOME vs KDE, touching on the topic of freedesktop.org and joined this time by the new hot topic, "GNOME vs Canonical". The bulk of the actions happened in the comments section of two blog posts, one by Dave Neary (1) , well-known GNOME advocate and another post by Aaron Seigo (2) , well-known KDE Developer. I want to improve my writing skills and the ability to get information from a community discussion. So, below is a step in that direction.

Disclaimer: All opinions are personal and none of the views expressed represent my employer, NASA, WHO or anyone else for that matter. The following is the juice of the events of last week written from a (as honest as possible) neutral perspective. Read through this post if you don't want to read through all the comments in the mentioned blog posts.

GNOME 3 release is just days away. Canonical and the GNOME community have taken different routes with Unity and gnome-shell respectively. Dave Neary wrote(1) a blog post with an analytic title "Has GNOME rejected Canonical's Help ? " . Neary cited instances of Canonical exhibiting behavior that shows discomfort in the Canonical-GNOME relationship.

The main point of contention was: rejection of libappindicator (3) by the GNOME release team roughly an year ago. appindicator is an implementation by Canonical for the management of system tray icons. It was brought under a specification titled "status notifier" to the freedesktop.org. Dan Winship and Matthias Clasen from GNOME have faced some severe issues with the specification and deemed (4) it unfit. The rejection reasons cited by the GNOME release team for appindicator were:

• it doesn’t integrate with gnome-shell
•  probably depends on GtkApplication, and would need integration in GTK+ itself
• we wished there was some constructive discussion around it, pushed by the libappindicator developers; but it didn’t happen
• there’s nothing in GNOME needing it

Neary asked for proofs of libappindicator proposal for gnome-shell and any convincing/rejection discussions following the proposal, if any. The openness and accountability of the gnome-shell development process can be known by such proofs.

Aaron Seigo of KDE blogged(2) about the controversy and used the opportunity to vent out his frustrations with GNOME. His post with an inflammatory title of "Collaboration's Demise" seem to indicate that the KDE project has faced severe pushbacks from GNOME for the ideas/standards proposed by KDE. Seigo feels in the last 5-6 years of freedesktop.org operations, GNOME seem to reject ideas based on a (Not Invented Here) NIH syndrome.

As expected, there were comments from GNOME people on Seigo's blogpost, though with a disclaimer that they don't officially respond on behalf of GNOME and are personal opinions. The main counterpoints by GNOME people that I could catch are:

• The idea of appindicators was proposed sometime in 2008. But was not discussed in open after that for a long time.
•  Roughly 2 years after that initial proposal and without any open-discussions on the design, a big code drop was requested for libappindicator and proposing it as a external dependency. 
• The libappindicator also needed copyright reassignments to Canonical for any contributions. A practice that is being widely frowned upon in GNOME and FOSS projects in the recent times. 

The main complaint from Seigo on his blog is that GNOME is deviating from freedesktop.org standards consistently in the last few years and this is unhealthy for cross desktop applications. He feels that appindicators is yet another symptom of this problem. It remains to be seen if this is the personal opinion of Seigo or if the KDE Board/Project too feels the same.

In addressing the events of the past week, Mark Shuttleworth has posted a blog (5) and accused the GNOME leadership (probably referring to the release team and Board, which is unclear from his blog) that the environment in GNOME is not conducive for internal competition. He believes that internal groupism in GNOME is killing baby ideas from anyone outside the group. The tone of the post is harsh towards the GNOME leadership and is filled with advice. Towards the end of his post, Shuttleworth notes that strengthening the partnership with KDE and freedesktop.org is the way forward and is more fruitful than convincing GNOME.

It may be an eventful time in the next few days to see how the GNOME community reacts to this. There will be a blog post by Jeff Waugh for sure, atleast, it seems. As of now, RedHat the biggest investor in GNOME and we expect no change in their stance. Novell seem to be happy with the way things are going in upstream and will stay close to it, it seems. Canonical is toying around with the idea of creating new cross-desktop standards and make Unity more popular. They seem to have appealed to some people in the KDE camp atleast (like Seigo). But it remains to be seen if this newly forged friendship is exposing real problems with GNOME or it is just a temporary sensationalism that will subside soon.

During the next Desktop summit, the GNOME and KDE boards have a huge task of ironing out the difference of opinions between GNOME and KDE people regarding the freedesktop.org processes. I don't know if everyone in KDE camp feel that GNOME is blocking changes in fdo or it is a perception of a few people like Seigo only.

My Take:

+ Most of these problems could've been minimized if Canonical have done their work in GNOME git repositories instead of doing it in their own private space. Nobody likes huge code drops. Doing things in private and opening up later is not a correct behavior in any open source community. They should have learned from the past mistakes like: Novell's gnome-main-menu, Android's Wakelocks etc.

+ Involvement with the community should begin as early as possible. It is not okay to assume, "We are special and we will get our way through even if we involve community in the end."

+ As is said in every GUADEC, GNOME is People. If Shuttleworth is unhappy with the leadership of GNOME, the way to fix it is not by doing things in private or by working with KDE/freedesktop.org (which is good but won't solve perceived problems with GNOME), the right way is to get involved with GNOME. How many Canonical employees are part of the GNOME Release team ? How many Canonical employees have ever been part of the release team ? Employ more people to work in upstream so that you can influence GNOME decisions. Grab the steering if you want to drive, don't be a back-seat driver.

+ There may be serious problems with the way freedesktop.org is managed if the complaints by Seigo are shared by many people in the KDE community.

Links:
1 - http://blogs.gnome.org/bolsh/2011/03/07/has-gnome-rejected-canonical-help/
2 - http://aseigo.blogspot.com/2011/03/collaborations-demise.html
3 - http://mail.gnome.org/archives/devel-announce-list/2010-June/msg00001.html
4 - http://aseigo.blogspot.com/2011/03/collaborations-demise.html?showComment=1299623993569#c1004728938259200386
5 - http://www.markshuttleworth.com/archives/654

Some of my observations have been wrong. If so, it is just because of mistake and not because of bad intent. Please let me know and I will correct myself. Thanks.