From: Jim Peters (jim_at_uazu.net)
Date: 2002-01-23 14:20:57
Rob Sacks wrote:
> We learned yesterday that the programmer needs the option
> of building either integer or floating point versions
We didn't learn that -- rather, you suggested it. I would say it's a
bad idea, because there is no way you can write code for both int and
double at the same time without #ifdef'ing every other line.
For instance, I've converted my filter-bank to FP to test it, and I
could straight away eliminate loads of bit-shifts and rounding code
that were necessary for integers, but useless for FP.
[ By the way, the results of my test is that the FP version takes
roughly twice as long on my Celeron 900, but only 20% longer on my
P133 (strangely). If I completely reconsider my algorithm, then I can
probably squeeze more out of each filter by using FP, and perhaps get
away with less filters, and so maybe I could get the time down to
integer levels or faster if I go with FP.
A question: would integer filters be useful for embedded stuff
(e.g. Doug's wearable computing), or it is okay to use floating point
on these processors too ? ]
> > BTW I'm talking about a multi-treaded program here.
> > So stages can work independently!
>
> I wouldn't do that. I think it will make the program
> unmanageably complex and buggy. Especially
> considering that most people here are probably working
> on single-processor machines, so they won't see bugs
> that we are creating.
Multiple processes or multi-threading is really useful if there is
something you *have* to keep up with, whilst there is something else
which might get behind. For instance, if we are doing sound-output,
this *has* to keep up, or else there will be a gap. You can't have
the sound stop just because there is a big redraw going on on the
screen.
I'm not in favour of lots of unnecessary extra threads, though. Just
ones that are vital for timing.
Jim
-- Jim Peters (_)/=\~/_(_) Uazú (_) /=\ ~/_ (_) jim@ (_) /=\ ~/_ (_) www. uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:37 BST