All The Bits Are Volatile

Oct 19, 2007 at 8:45 pm (Uncategorized)
Tags: ,

In the colourful land of India, this is a week of festivals. From where I come from, we celebrate today as Saraswathi Pooja. Goddess Saraswathi is the goddess of learning.

It is a time to remind myself that I’m just one of 6,000,000,000, on a planet that is one of 9, in a solar system that is one of 200,000,000,000, in a galaxy that is one in 125,000,000,000. That in the grand scheme of things, I matter less than a single bit of my hard-drive. That while I argue and debate to establish my intellectual superiority over others, I forget that I stand on the shoulders of giants who had the humility to let me. That while I scorn others, I forget that I matter less than a single bit of my hard-drive.

It reminds me that I’m just a speck in the journey called time. That two generations hence nobody would ever know who I was. That in a few decades I’ll probably be a senile old man who keeps forgetting how to use templates in C++. That there is a time to draw ASCII-art in .nfo files, and there is a time to smile gently when the young firebrand challenges your design. That I’ll never reclaim the days and nights I burn away in front of a monitor.

May this festival bring humility and tolerance, remind us to appreciate and acknowledge, and help us remember that while we reach for the stars our feet must still remain on the ground.

4 Comments

Floating point is slow, you say?

Oct 17, 2007 at 10:37 pm (Uncategorized)
Tags: ,

And Bresenham’s algorithm is fast because it uses only integer operations?

Wake up. Modern processors crunch floating points even faster than integers. Don’t believe me? Read on.

Here’s a small test application, in good ol’ C:

void f1()
{
    double d = 0;
    int i;

    for (i=0; i<10000; ++i)
        d = d * i + 1;
}

void f2()
{
    int d = 0;
    int i;

    for (i=0; i<10000; ++i)
        d = d * i + 1;
}

int main()
{
    f1();
    f2();

    return 0;
}

Let’s compile this with a Microsoft VC 7.1 compiler with this command line:

cl -Zi tm.c

The -Zi is so that .pdb (program database) files are generated, that contain symbol information and is used by the profiler to instrument the binaries. My profiler of choice is AQTime. Rather cool one, that. So anyway, let’s run this in AQTime and see what it reports:

f1: 6639.89 μs, 18545395 machine cycles
f2: 196.82 μs, 549727 machine cycles

[The machine is a 2.8GHz Intel Pentium with HT.]

Hrmph. Nowhere near. Let’s try again with a different compiler option.

cl -Zi -arch:SSE2 tm.c

The “-arch:SSE2″ instructs the compiler to generate SSE2 instructions. (Note sure what is SSE2? Read the Intel developer’s manual, over here.)

OK, what does the profiler say now?

f1: 224.12 μs, 625973 machine cycles
f2: 278.28 μs, 777237 machine cycles

Hah! Surprised? Well don’t be. These are the new rules of the old game.

Let’s try again, with one more option:

cl -Zi -G7 -arch:SSE2 tm.c

The “-G7″ is to “optimize for Pentium 4 or Athlon”. The results:

f1: 159.31 μs, 444965 machine cycles
f2: 265.11 μs, 740473 machine cycles

Suprised? Sweating? There’s-something-wrong-with-his-profiler?

Know your hardware. It pays.

3 Comments

Three Steps To Becoming a Better Programmer

Oct 12, 2007 at 8:21 pm (Uncategorized)
Tags: ,

There are people who love programming. Who enjoy the challenge and pleasure of creating something. Of watching it grow and flourish. Of seeing it do what it was destined to. Such people start off with a spark in them. When the spark is fanned into a flame, they become creators of software that makes a difference in our lives.

I’m asked, once in a while, by promising coders, about how to become better at the job they love. This is my advice to them:

  1. Code. If you’re a painter, and you want to better yourself, what would you do? Paint more? Paint things you haven’t painted before? Use painting techniques that you haven’t used before? Surely yes. And why should these steps not be applicable to our profession? To become a better programmer, program. Write programs. Complete ones, that work. Not one, not two. Just keep doing it. The more you do, the better you become. Rewrite it in Haskell. Port it to Solaris. Add a garbage collector. Support another user-interface language. Publish your work as open source. Write a patch for gcc.
  2. Look around you. Things happen. Things change. It’s always exciting out there. So many things to learn. So many things you never knew existed. Read about elegant solutions to challenging problems. See how people create, use, misuse and abuse technologies. Find out what Brainf*ck is. What IOCCC is. Why Ariane 5 failed. Why jwz started a nightclub. Why Python has a GIL. Why VirtualAlloc returns 64k-aligned pointers.
  3. Reflect. Connect your input and output. Think about what you read. What you learned. How you can apply it to your work. Reflect and ruminate. Why did your code work the very first time with Python? Why is it faster to iterate through std::vector than std::list? How should duck-typed languages handle primitive types? When is it best to use frameworks and when libraries? Why should this routine here create so many page faults? Shall I build a generic backend for duck-typed languages?

If you’re reading this, you’re probably one of the gifted few. You are one among a rare and endangered species. Keep the spark, the flame, the passion alive. May the force be with you.

16 Comments

42! 42!!

Oct 3, 2007 at 8:30 pm (Uncategorized)
Tags: ,

No, it’s not. Calm down. You haven’t found the The Answer. What you claim as the best thing that can happen to software development isn’t.

Over the rather few years that (software) programming has ventured out of universities and military establishments and into the hands of the average denizen, more and more people claim to have found the elixir to the woes of developing perfect programs, on time and under budget. Day in day out, blogs proclaim and expound the virtues of the latest solutions — and they sound not quite unlike this. Someday it is a new programming language, someday it is a new development methodology. Oh and new versions of IDEs too.

Don’t get me wrong. I like that IDE too. Well, sort of. And also ruby and agile and scrumm and whatever. Just don’t tell me that your programming language is the best because everything is an object. Or even because it is not, for that matter. You see, creating great software is rarely a result of the development methodology your team adopts, the programming language they choose. Or even the size of offices they sit in (with apologies to Joel). Or because they used Ruby on Rails. Or Glassfish. Or Flex. Or Spring. Or whatever.

No, there is no 42. Every software is a solution to a problem. Each problem is different. The constraints they pose are different. A good designer is one who makes the best trade off, the best compromise between two orthogonal qualities. Tools, libraries, frameworks, IDEs are all tools of the trade — like jackhammers and chainsaws. What makes or breaks a software are the skill and discipline of the people who use it.

Good software is a skillful blend of creativity and engineering. It requires people who have a passion for programming, a desperation to improve their skills, a sharp and intutive mind to analyze problems, and the creativity and innovation to go with it. It’s what is between your ears that matter, not what is in your hands.

You want to create software that people would remember you for? Then learn, and apply. Write code, read about everything related to creating software, and reflect upon them. Repeat. Ad nauseum. Until you get calluses on the balls of your wrist.

If you’re a good programmer, you’ll be one whether you use NetBeans or Notepad. Whether you use GTK+ or MFC. Whether you are married or a geek.

There is no 42. There’s just you.

7 Comments

Newer entries »