# Fw: uptime

## stevan apter — 2000-06-15 01:50:00

    i thought you folks might enjoy reading this message from dick dunbar

    at the ibm aix research lab to the k list.  dick has been experimenting

    with kdb, the k database product, on some of the big iron at the lab.

    kdb is an rdbms written in 100% pure k.  the source is probably five

    or six pages, the executable around 150k.  we expect the 64 bit version

    to be quite a bit smaller (around 30k).  a size-limited time-limited

    free version can be downloaded from the kx website.

     ----- Original Message -----

    From: Dick Dunbar <dick_dunbar@...>

    To: <kdb@...>

    Sent: Wednesday, June 07, 2000 3:11 PM

    Subject: Re: uptime

    > If I could be permitted to expand on that a little ... the mass is

    > certainly important on disks, but it is even more important in the machine.

    > Like real estate, it's "location, location, location".

    >

    > It's not only the physics (locality) of the data, it's also about the

    > locality of the code, and is the primary reason I believe that the

    > competitors don't stand a chance in a shootout with kdb.

    >

    > Just look at the size of the executable, and it will explain a lot ...

    > the whole code fits in the instruction cache line of a modern machine.

    >

    > By contrast, most commercial database products take an icache instruction

    > fault for every 9 instructions executed.  Like the old golf joke, it's:

    >

    >    "hit the ball, and drag george".

    >

    > The kdb code is so tight (and I've given kdb some suggestions on making

    > it even tighter on AIX) that it never faults and you get super-scalar

    > instruction execution (more than one instruction per cycle) on these

    > machines.

    >

    > It's also about the physics of thought ... the kdb code is so tight,

    > that a human ... ok, a super-human ... can keep the whole scheme

    > in their mind and optimize the algorithms without entering a 6 month

    > development cycle.  The other guys don't stand a chance to keep up

    > with this.

    >

    > The final point is about roots;  kdb has long, well established roots

    > from earlier developments.  How did kdb get to be so fast?

    > With 20 years of expert experience on world-class problems, that's how.

    >

    > arthur whitney wrote:

    >

    > > > It's all about physics ... the more mass, the longer it takes.

    > >

    > > i like that.

    >

    > ---

    > The KDB list is managed by majordomo@...

    > Send a message there, containing the word 'help', for assistance, e.g. unsubscribing.

    >