From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5cbfcb03a9d3d935
X-Google-Attributes: gid103376,public
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: Help B* and B+ Trees
Date: 1998/05/17
Message-ID: <dewar.895441116@merv>#1/1
X-Deja-AN: 354114814
References: <6je5il$ecf$1@news.iinet.net.au> <355B0B39.7A3673D5@earthling.net>
 <dewar.895192005@merv> <355D5DF7.1451@online.no> <dewar.895324206@merv>
 <355DAD67.50A5@online.no>
X-Complaints-To: usenet@news.nyu.edu
X-Trace: news.nyu.edu 895441131 17254 (None) 128.122.140.58
Organization: New York University
Newsgroups: comp.lang.ada
Date: 1998-05-17T00:00:00+00:00
List-Id: <comp.lang.ada>


Tarjei said

<<And how do you propose to get cache hit and misses into this? It is a
  time since I read about the implementation of Mix. I doubt that the
  implementation takes into account internal pipelining and the effect of
  cache hits and misses which we would normally have in a real system.>>

Slight historical mismatch here. KV3 was written around 1970, when
memories were as fast as processors, and cache hit and miss times
were irrelevant since machines were typically uncached. I agree it
is FAR harder to get accurate timings these days. You did not even
mention TLB misses.

The point is that you still come much closer to the real world at this
level than at the O(N**2) comparisons counted level!

<<I don't see how this reflects the real world where a compiler writer may
  want to keep jumps within the instruction pipeline or obtain a cache
  hit.
  I still want to time the algorithm and then explain the time differences
  with references to the source code. I see no point in complicating
  matters by decoding compiler output (unless the result is confusing).>>

Fine: you are actually strongly agreeing with me, so if you don't see this,
you did not quite understand my suggestion. 

Obviously you can't explain all timing differences at the high level
language level, because of the factors you mention, still you can
indeed come pretty close PROVIDING, and this is a very important PROVIDING,
you have a computational model of the language you are using. That is what
I meant by "adopting a very high level machine with known complexities ..
based on a subset of Ada or Pascal or C or whatever). The point is that
if you want to reference source code in understanding complexity, then
you must restrict the source code to operations for which you have some
reasonable understanding of their computational complexity (e.g. we 
do NOT want to include propagation of exceptions in the mix).

<<Then one can relate the time to the number of statements executed>>

Only if you have some idea of what it means to execute a statement in
terms of computational complexity!