On Fri, 27 Apr 2001, Robin Szemeti wrote:
> On Fri, 27 Apr 2001, someone who Robin's attrib to fscked up wrote:
>
> > [side note: I did just see a bizarre thread in macosx-dev where
> > one guy claimed his FFT code was executing faster in Java than C
> > because its interpreter used runtime info to optimize it. Search on
> > 'informal benchmarks']
>
> uh huh .. but he's a Java programmer .. his C could be *REALLY* bad ;) ..
> favourite Java quote 'If javas garbage collector is damn good, how come
> the whole thing doesn't delete itself upon execution?'

Don't see why this isn't possible.  The idea is that you factor out *all*
really unlikely cases (how you know this is based on past performance) and
catch them all with some simple test.  Then you (more expensively, but who
cares since this happens only once in a blue moon) deal with it and work
out exactly what was the problem.

Another example, you could use a processor level exception to catch those
pesky divide by zero errors (which is very expensive if it fires, but much
much cheaper each time round than explictly checking it.)  The advantage is
that a compiler doesn't have this information lying around - you can't
tell from the code how often cases come up;  You need to profile at run
time as you go.

Sorry if this is all babble.  I haven't had much sleep.

Later.

Mark.

-- 
 who *still* hasn't got round to getting a new .signature

Reply via email to