How do they do it in the real world? (programming performance)

DevilWAH

I am sure there are a number or people here like me that have dipped there toes in scripting/programming, using it for automating simple tasks and automating repetive management jobs. But thats really as far as I have taken it, never needing to go deeper or really worry about optimizing code.

But a few days ago I sat down and put together the few lines of code below.

What this is doing is creating 500 ellipse's, and calculating the points on the circumference for each at a given degree. Then incrementing the value for the degrees and recalculating.

On a 800Mhz CPU this runs at about 80 cycles per second. Which although is quick, moving up to 2000 ellipses's and it drops to 25 per second.

So how do the likes of Games manage to get such performance out of a system. Enemy AI, Player input, Environmental interaction. All must require much more complex processing than this, but frame rates of 80+ are not uncommon. And even with the off loading of the Graphics and physics to the GPU, the core of the application must still be run on the CPU.

I am starting to think that far from being poorly coded and bloated which I felt games had become since the good old days of the Atara and Amiga with there 2K footprints. The Guys out there today are still managing to squease a lot of game out off the resources the have at there disposal.

#!/usr/bin/perl

use strict;
use warnings;


use Benchmark;
use Math::Trig;


my $i = 0;
my $x = 0;




my @Degre = map {rand(360)} (0..499);
my @step= map {rand(.5)} (0..499);
my @aa = map {rand(2000)} (0..499);
my @bb = map {rand(2000)} (0..499);


timethis(100,'


$xx[$_] = $aa[$_]*(cos($Degre[$_])*(pi/180)) for (0..499);
$yy[$_] = $bb[$_]*(cos($Degre[$_])*(pi/180)) for (0..499);


$Degre[$_] += $step[$_] for (0..499);


#print "$bb[1]  $aa[1]  $Degre[1] $step[1] \n";


');

nhpr

Here's a few examples of things that could be done:

1. Calculate pi/180 and place that in a variable. That way it isn't recomputed a couple of times every iteration.
2. Set up cosine tables. If you create an array with various cosine values (and then just grab the nearest value when iterating), you'll save a lot of time -- though at a cost of memory.
3. Compile the code. Perl is a scripting language, so it runs on top of an application. If you were to write this in C, for example, and compile it, there wouldn't be as much overhead. If you're feeling way over-achieve-y you could always try to do it in assembly.
4. Make sure the script isn't causing your machine to swap when it's running at higher levels. That may account for degredation when running more iterations.

Code optimization requires looking at the algorithm(s) and the way the code executes at every level. Less is more. It's not something that can be learned very quickly and requires some experience. As you pointed out, 80s and 90s coders were much better at this because they had to be. Now, sloppiness is much more tolerable since we don't run on 486s anymore.

paul78

DevilWAH wrote: »

So how do the likes of Games manage to get such performance out of a system.

It's not usually the code, it's the algorithm that are used. In your example, you use trigonometry to plot where to draw. In actual game programming, programmers typically use pre-optimized graphics libraries for drawing. And the graphics libraries themselves actually use vector calculations.

Drawing circles and lines can be done using an algorithm known as Bresenham's algorithm. There is no trig involved.

Usually, when graphics programming for speed, the goal is avoid floating point numbers, any complex math and stick to simple vector manipulation.

DevilWAH

I have a friend who does Disease Modeling and its the same, all about cutting down on repetition and finding simple algorithm that match real world data.

I would have though Graphic Programming is a little different as it has its own set of restrictions due to dedicated hardware, massive parallel pipe lines but reduced flexibility in what can be done.

The original question was meant semi rhetorically, although I have to say I do wish I had the time to really get in to programming, alas I chose a different path. But it does make you think that 4Ghz quad core seems a little slow and limiting now

paul78

DevilWAH wrote: »

But it does make you think that 4Ghz quad core seems a little slow and limiting now

Very true... But a 4Ghz core is blazing compared to 10 years ago. Remember when Doom first came out, it's 3D engine ran quite well on an Pentium I clocked at 66 Mhz.