origin of endian

While reading about Endian-ness with microprocessor I became curious about how this term came into existence. The terms Big-Endian and Little-Endian come from Part I, Chapter 4, of Jonathan Swift’s Gulliver’s Travels. Here is some background what Big and Little mean in here:

The novel further describes an intra-Lilliputian quarrel over the practice of breaking eggs. Traditionally, Lilliputians broke boiled eggs on the larger end; a few generations ago, an Emperor of Lilliput, the Present Emperor’s great-grandfather, had decreed that all eggs be broken on the smaller end after he cut himself breaking the egg on the larger end. The differences between Big-Endians (those who broke their eggs at the larger end) and Little-Endians had given rise to “six rebellions… wherein one Emperor lost his life, and another his crown”. The Lilliputian religion says an egg should be broken on the convenient end, which is now interpreted by the Lilliputians as the smaller end. The Big-Endians gained favour in Blefuscu..

Related articles

Sharing Options:

boost with XCode

Sometime ago I was trying to port one of my experiments on Mac OS X. The application relies on boost library, so there was need to get started with boost on Mac. And I wanted to use XCode all the way along. Coming from Windows meant browsing thru XCode build settings to figure out what goes where. Visual Studio Property Pages and XCode Settings don’t match really well, from UI point of view.

XCode puts the compiler application somewhere in deep guts of \Developer directory, so copying the boost libraries was not really an option. Mac OS X being UNIX underneath meant I had a global include/lib/bin directory where I can put boost libraries once built. What follows next is visual summary of building and installing boost on Mac OS X.

It starts with boot-strapping boost build engine:

Continue reading

Sharing Options:

C++ Template Metaprogramming Part 2 of n

Series:
1. C++ Template Metaprogramming
2. C++ Template Metaprogramming Part 2 of n

This is second in series and I would like to expand on thinking recursively in this part, before than introducing other concepts. For this post lets create a template metaprogram to check if given number is prime or not.

This a standard iterative implementation of checking whether the number is prime:

bool isPrime(int number)
{
    if(number < 3)
        throw std::invalid_argument("numbers less than 3 cannot be primes");

    //  any even number cannot be a prime
    bool result = number % 2 != 0;

    for(int divisor = 2; result && divisor < number/2; ++divisor)
    {
        result = number % divisor != 0;
    }

    return result;
}

All highlighted lines have one or more terminating conditions for computation. Line 4 checks for valid input, 7 filters out all even numbers. Line 9 ensures we terminate if have tried a lot of divisors (number/2 is the last thing we want to try) and 11 checks whether number is a multiple of divisor.

Given this it is implement a recursive equivalent with said terminating conditions:

bool isPrime_rimpl(int number, int divisor)
{
    return  number == divisor ? true :
            number % divisor == 0 ? false : isPrime_rimpl(number, ++divisor);
}

bool isPrime_r(int number)
{
    if(number < 3)
        throw std::invalid_argument("numbers less than 3 cannot be primes");

    return isPrime_rimpl(number, 2);
}

Continue reading

Sharing Options:

Visual Studio Run Time Error Checks /RTC & Performance

Recently I was analyzing some very computation intensive code. The code was operating on an image and was fiddling with each pixel. For image of size 4000×4000 my function was called ~5 billion times. Since most of the computation depends only on the pixel attributes – so this problem tended itself very well for data parallel computation, but I was more interested in eliminating bottlenecks in serial code first than running un-optimized code in parallel.

I started on Mac, compiled with Clang-3.5 and observed that computation on 20 images take somewhere around ~8 seconds on my 3 year old MacBook Pro. But the moment I compiled with Visual Studio 2013 and ran the same code on Windows 8.1 desktop with shiny new Haswell Processor it took whopping ~24 seconds to run!! I was astonished and was looking for what really went wrong. How could Visual Studio 2013 generate such slow code?

To tackle this head on I compiled the same code on windows using clang-cl and Visual Studio 2013 and dumped the generated assembly (/Fa option to compiler). Looking at assembly it was quite clear what caused the slowdown. The extra checking windows added in debug builds with Run Time Error Checks did add quite a bit of code, but above all it was thrashing cache badly. Later on I compiled my code with /RTC set to default and could see comparable timings with what clang generated.

It was quite an interesting exercise investigating and analyzing various CPU performance counters on Mac and Windows, perhaps I will write more about it some time later.

Sharing Options:

PrintScreen on Windows running on MacBook Pro

I haven’t been very successful in capturing screen shots efficiently on Windows running on my MacBookPro, however found a convenient way to get PrintScreen button going. It’s by using on screen keyboard.

The idea is to launch On-Screen Keyboard application in Windows and press PrintScreen button – not optimal (you can anyway trim the image later on) but better than nothing and installing some utility program from internet. I wanted to capture some tool-tips which won’t go very well with Snip – else I would have preferred it over anything else on Windows.

Continue reading

Sharing Options: