On Apr 28, 3:13 am, Tony Delroy <tony_in_da...@[EMAIL PROTECTED]
> wrote:
> On Apr 27, 10:29 pm, Le Chaud Lapin <jaibudu...@[EMAIL PROTECTED]
> wrote:
>
> > "Premature optimization is the root of all evil."
> > So I waited until my (big) Integer class was sufficiently mature
> > before optimizing it.
>
> That may still be premature. Profiling should generally be the
> trigger for optimising, though of course if your responsibility ends
> at delivering a "big int" library, it's reasonable to go that bit
> further and benchmark alternative implementations before waiting for
> customer complaints....
True, but there are some situations where one knows well in advance,
even before the project begins, that small pieces of the code will
need to be optimized manually. This is one such situation.
In fact, I will probably not use a profiler to profile my code,
because I already know where the bottlenecks are.
Not suprisingly, every fast Big Integer implementation I have seen
follows the same pattern: they write most of the code in ****table C++,
then replace a few critical operations in with assembly. The
difference in speed can be dramatic because there of the very nature
of the operations.
Take the simple operation of computing [unsigned int] + [unsigned int]
on a 32-bit machine with carry-detection. There is no trickery in C++
that can be done to achieve the efficiency of hand-crafted inline
__asm.
Normally, this would not be an issue, but in the case of Big Integer,
it matters greatly, especially for divide-with-remainder and multiply
operations.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm
for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
