Tie Knot -- A Statistician's Marvel

Men of all ages knot their tie. The resultant bow of the knot looks pretty on its wearer and enhances there look as well. Getting that knot the way we want is not that easy after all. I would say it is an art. It’s a sad fact, but there are grown men who don’t know how to knot a tie. If they have a big interview that afternoon, they’ll go shopping for a clip-on. Even if a man does know how to tie a tie, their knowledge is often limited to just one necktie knot. But there are several ways to tie a tie. Certain necktie knots should be used with certain shirt collars and tie fabric materials to get the best results for your appearance. Some popular and important variations are described in the figure below.

How simple or complex is this art of knotting a tie? J.D.Lenzen is an artist who specializes in tie knots. He considers knot tying a creative practice rather than an unchanging discipline. Knots, he believes, are like paintings. Twists, coils and weaves replace the pigments and the length of the tie becomes the canvas. J.D. Lenzen is the creator of the highly acclaimed YouTube channel "Tying It All Together", and the producer of nearly 300 instructional videos. He's been formally recognized by the International Guild of Knot Tyers (IGKT) for his contributions to knotting, and is the originator of Fusion Knotting—the creation of innovative knots and ties through the merging of different knot elements or knotting techniques.

His published instructional books include Paracord Fusion Ties - Volume 2 (2013), Paracord Fusion Ties - Volume 1 (2012) and Decorative Fusion Knots (2011). His fourth instructional book, Paracord Project Inspirations will be available online and in stores, later this year (2014).

Recently, mathematician Mikael Vejdemo-Johansson, at the KTH Royal Institute of Technology in Stockholm, and colleagues have come up with a mind boggling 177,147 variations of knotting a tie. The inspiration for the work apparently came from the fiendishly complex knot sported by the “Merovingian” villain from the Matrix films. The number Vejdemo-Johansson and pals came up with is a vast increase on the 85 ways that physicists Thomas Fink and Yong Mao from the Cavendish Laboratory in Cambridge found in 2000. According to Vejdemo-Johansson, their number is much larger because Fink and Mao made various assumptions about tie knots that drastically reduced the number available, including that tie-wearers would only make a “tuck” – pushing the tie into the knot to lock it in place – at the end of a given tying sequence.

Next time you lay hand on your tie, try out a different knot and remember you have several more to attempt. It is an art and not just a step in decoration. :)

Microbenchmarks -- A step to avoid towards Software Performance Tuning

Performance Improvements in a large-scale software application is often taken right at the end or when a critical issue is reported by customers or other stakeholders. The more the age and adoption of the product, the more is the expectation that the product will run slower than before. The key is always in writing code with good and time-tested algorithms. And when you still have to undertake performance tuning, a meticulous approach is what is required. One of them is called Microbenchmarking.

A microbenchmark is a test designed to measure a very small unit of performance e.g. the time to call a synchronized method versus a nonsynchronized method, the overhead in creating a thread vs. using a thread pool, the time taken to execute one algorithm against another etc. Doesn't this sound interesting? Yes, they are the basic building blocks of the whole exercise of bettering Software application performance.

Unfortunately, it is often very difficult to write a correct microbenchmark. Consider the following code.

public void doTest()
{
     // Main Loop
     double l;
     long then = System.currentTimeMillis();
     
     for (int i = 0; i < nLoops; i++)
         l = generateFibonacci(50);
     long now = System.currentTimeMillis();
     System.out.println("Elapsed time: " + (now - then));
}
 
...
 
private double generateFibonacci (int n)
{
    if (n < 0) throw new IllegalArgumentException("Must be > 0");
    if (n == 0) return 0d;
    if (n == 1) return 1d;
    double d = fibImpl1(n - 2) + fibImpl(n - 1);
    return d;
}


The calculated Fibonacci numbers in the function generateFibonacci are never read. This gives a freehand to the compilers in JVM 7 and 8 to discard the calculations. All smart compilers will end up in executing the following code and skip the function altogether.


public void doTest()
{
     // Main Loop
     double l;
     long then = System.currentTimeMillis();
     long now = System.currentTimeMillis();
     System.out.println("Elapsed time: " + (now - then));
}

The program will always print the elapsed time as a few milliseconds irrespective of the implementation of the Fibonacci method or the number of times the loop is supposed to be executed. This defeats the very purpose of the test. So, what can we do to get around this problem?

Make sure that each and every computed value is read in some way or the other. One easy way to do that is to make sure that the computations are read into an instance field which is preferably a volatile. The need to use a volatile variable in this example applies even when the microbenchmark is single-threaded.

Be especially wary when thinking of writing a threaded microbenchmark. When several threads are executing small bits of code, the potential for synchronization bottlenecks (and other thread artifacts) is quite large. Results from threaded microbenchmarks often lead to spending a lot of time optimizing away synchronization bottlenecks that will rarely appear in real code—at a cost of addressing more pressing performance needs.

Consider the case of two threads calling a synchronized method in a microbenchmark. Because the benchmark code is small, most of it will execute within that synchronized method. Even if only 50% of the total microbenchmark is within the synchronized method, the odds that as few as two threads will attempt to execute the synchronized method at the same time is quite high. The benchmark will run quite slowly as a result, and as additional threads are added, the performance issues caused by the increased contention will get even worse. The net is that the test ends up measuring how the JVM handles contention rather than the goal of the microbenchmark.

In a microbenchmark, the inputs must be precalculated. The test must not spend time in finalizing the inputs. One of the performance characteristics of Java is that code performs better the more it is executed, a topic that is covered in Chapter 4. For that reason, microbenchmarks must include a warm-up period, which gives the compiler a chance to produce optimal code. The advantages and disadvantages of a warm-up period are discussed in depth later in this chapter. For microbenchmarks, a warm-up period is required; otherwise, the microbenchmark is measuring the performance of compilation rather than the code it is attempting to measure.

Writing a microbenchmark is hard. There are very limited times when it can be useful. Be aware of the pitfalls involved, and make the determination if the work involved in getting a reasonable microbenchmark is worthwhile for the benefit—or if it would be better to concentrate on more macro-level tests.

 

References

Java Performance : The Definitive Guide

JVM Specifications

Happy Birthday!!! Subscriber Trunk Dialling

On a fine afternoon of 5 December, 1958, Her Majesty, Queen of UK, took a revolutionary step towards making a trunk call without the involvement of an operator. She phoned 031 CAL 3636, the Lord Provost of Edinburgh from the central telephone exchange in Bristol, more than 300 miles (482km) away. It also marked the birth of Subscriber Trunk Dialling (STD). Till that day, all long distance calls were made with the help of a human operator.

The Queen dialling what came to be known as the first STD call

18,000 subscribers in Bristol were given the first opportunity to make trunk calls. All the calls were charged based on distance and time both. It was big day in the history of communications and the staff at Bristol Telephone Exchange was very excited. Brian Fox, a fresh faced engineer who had only finished his apprenticeship three months before, stood only feet from the Queen when she made that historic call.

It was one of the most important days ever in telecommunications history and a huge amount of work went into making sure the day went without a hitch. The walkway from Telephone Avenue was tented and full of flowers and a powder room for the Queen was hastily provided in a converted control room.

We stood between rows of equipment as close as we could get and watched Her Majesty dial the number. When it was all over and the Queen was leaving the Duke of Edinburgh remarked, 'you can relax now chaps, it all works'!

International subscriber dialling (ISD) was introduced on 8 March 1963, when London subscribers were able to dial Paris numbers directly.