POV-Ray : Newsgroups : povray.general : how to prevent overlapping random objects? : Re: how to prevent overlapping random objects? Server Time
30 Jul 2024 02:21:51 EDT (-0400)
  Re: how to prevent overlapping random objects?  
From: Alain
Date: 22 Aug 2010 13:10:46
Message: <4c715a16$1@news.povray.org>

>
>> 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?
>
> FWIW, you still probably don't need the sqrt. You probably have
> something like
>
> if ( sqrt( x*x + y*y ) < radius )
>
> which can just be
>
> radiusSquared = radius * radius;
> ...
> if ( x*x + y*y < radiusSquared )
>
>>
>> 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.
>
> - Slime

Many times, assembly can be slower that compiled. The reason is that 
compiler can do optimisations based on the prehemptive nature of any 
modern CPU and the concurent nature of the FPU, taking into acount the 
effective timing of every opcode. Then, whenever you use the FPU, you 
need to take into acount it's own pipe and timing and cram operation 
that don't need the results to fill up the wait time.
To beat a decent compiler, you need to be a crack assembler. To beat a 
good compiler, you need to be a genius with an excellent understanding 
of all the subtelties of your CPU and FPU.


Alain


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.