Slime wrote:
> 
>> No, I'm setting specific radii (in pixels) and testing against a 2D
>> array using a brute-force method. In POV I was doing radius comparisons.
>> At any rate, I'm only having to do the sqrt(x*x+y*y) calculation 128*128
>> times when the program starts, to fill an array. It's like 1/4 of a
>> cylindrical pigment, and is the maximum circle radius. It's a drop in
>> the bucket, really.
> 
> Oh, OK. So you're creating an actual image and filling it with circles?

Yes, though I'm not testing the image, as that would be slow, but rather 
am only writing to it for display purposes.

> FWIW, you still probably don't need the sqrt. You probably have 
> something like
> 
> if ( sqrt( x*x + y*y ) < radius )

Actually, it's like this:

  if(circular[abs(x)][abs(y)]<csize)

Where "circular" is the precalculated array.

> which can just be
> 
> radiusSquared = radius * radius;
> ...
> if ( x*x + y*y < radiusSquared )

Ah yes, that would work, and would save a heap of unnecessary 
calculations from being performed.

>> Of course, with today's computers I can afford to be so wasteful. Not
>> that my program is running at record speeds or anything. Maybe if I knew
>> assembly language... :(
> 
> Knowing assembly language isn't really the key to making faster 
> programs. I mean, if you're an expert at assembly, then you can probably 
> push your program's speed a little bit, but modern compilers do a pretty 
> good job already. You're more likely to improve your program's speed in 
> other ways. For instance, by learning how to avoid cache misses by 
> keeping commonly accessed data close together or by changing your 
> algorithm to avoid jumping around in memory. Also, if there's any chance 
> that there's a better algorithm for what you're trying to do (and it 
> seems there always is), then it would be better to spend your time 
> finding it than rewriting the current algorithm in assembly.

Hmm, I'll have to investigate more fully what it means to keep 
commonly-accessed data "close together." I don't have many pointers, and 
my (one) vector is well-accounted for...

I guess I was thinking back to the (not so distant) past when I saw some 
incredible QBasic demos running at impossible speeds. They used ASM, of 
course, since there was no way of doing those things with normal 
interpretive language techniques.

Post a reply to this message