[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Pierre Phaneuf wrote:
> Steve Baker wrote:
> > I think that in a large, commercial programming house, you can afford to
> > have a couple of assembler Guru's on the team who look for the slowest
> > parts of the code that their colleagues put together and clobber it
> > with assembler. In a small team - or a solo effort, you are much better
> > off spending your time looking for better algorithms and sticking to
> > working in C or C++.
> Ah yes. The profiler is your friend. Not enough people take the time to
> profile their code. Many of them could be surprised! I knew I was when
> we started doing profiling on Quadra! (what is this *network* code doing
> so high in the time chart???) ;-)
>From my experience ; I once wrote a computer game when I was learning basic
programming with a friend. It was on a 286, laced with assembler. Everytime I
wanted a new feature it took ages of picking through convoluted code. About 6
months after I had stopped mucking around with it, I decided I wanted to
release it as freeware on the net, so I went back, armed with more programming
experience, and tried to speed up the slow code and add a few little features.
On profiling, I found most of the time (80%) was spent in the collision
detection routines (written in assembler). I converted them all back to pascal
(yes pascal) along with rewriting most of the rest of the program to make
sense of it. I found the algorithm I used for collision detection was
rather...well...ridiculous, so I rewrote it (in pascal), and immediately the
collision detection went down to around 1% of the CPU time. It now ran so fast
I had to put in a proper timer loop so I could play it ! Needless to say, the
last thing I do these days is turn to assembler. I believe Abrash also said in
one of his Dr Dobbs articles something about always trying to find the best
algorithm first before resorting to assembler to speed it up.
Bye - Joel.