![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thomas de Groot
Subject: Re: how to prevent overlapping random objects?
Date: 21 Aug 2010 03:07:53
Message: <4c6f7b49@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"stbenge" <myu### [at] hotmail com> schreef in bericht
news:4c6ee306$1@news.povray.org...
> Thomas de Groot wrote:
>> "stbenge" <myu### [at] hotmail com> schreef in bericht
>>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave
>>> it to perform, only a mere 3,065 succeeded.
>>
>> That seems indeed to be the trade-off of this method. :-(
>
> The C++ version works very well, and it's super-fast, but now I need to
> make a GUI...
Come on, Sam! You can do it! You rule! :-)
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Thomas de Groot wrote:
> "stbenge" <myu### [at] hotmail com> schreef in bericht
> news:4c6ee306$1@news.povray.org...
>> Thomas de Groot wrote:
>>> "stbenge" <myu### [at] hotmail com> schreef in bericht
>>>> It took 23 minutes, 36 seconds to parse. Out of the 50,000 tests I gave
>>>> it to perform, only a mere 3,065 succeeded.
>>> That seems indeed to be the trade-off of this method. :-(
>> The C++ version works very well, and it's super-fast, but now I need to
>> make a GUI...
>
> Come on, Sam! You can do it! You rule! :-)
It's getting close... got the (simple) GUI, now I need to tackle
vector.h, which will probably be the easy part. Thanks for the
encouragement! :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
> everything...
>
> So far, my C++ implementation is very fast, for not being coded with ASM
> and all. I was able to implement a few speedups, like not using
> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
> array and picking from that.
>
> But now I'm stuck on trying to convert an int to a char, and
> vice-versus. It always comes down to something like that with C :( To
> make a utility like this useful, the user need to be able to change
> certain settings... This one might take awhile.
What's the fastest? sqrt(x*x+y*y) or sqrt(x^2+y^2)
In POV-Ray SDL, the second, as sqrt(pow(x,2)+pow(y,2)), is faster. Don't
know how it compare in C/C++ or other compiled languages.
May be worth testing.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> So far, my C++ implementation is very fast, for not being coded with ASM
> and all. I was able to implement a few speedups, like not using
> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
> array and picking from that.
You're doing a radius comparison, right? You probably don't need to take
a square root.
- Slime
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Slime wrote:
>> So far, my C++ implementation is very fast, for not being coded with ASM
>> and all. I was able to implement a few speedups, like not using
>> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
>> array and picking from that.
>
> You're doing a radius comparison, right? You probably don't need to take
> a square root.
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.
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... :(
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Alain wrote:
>> Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
>> everything...
>>
>> So far, my C++ implementation is very fast, for not being coded with ASM
>> and all. I was able to implement a few speedups, like not using
>> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
>> array and picking from that.
>
> What's the fastest? sqrt(x*x+y*y) or sqrt(x^2+y^2)
> In POV-Ray SDL, the second, as sqrt(pow(x,2)+pow(y,2)), is faster. Don't
> know how it compare in C/C++ or other compiled languages.
>
> May be worth testing.
>
> Alain
Hmm, I was not aware that pow(n,2) was faster than n*n. I'll keep it in
mind next time the issue comes up. In my program, sqrt(x*x+y*y) is only
called at the very beginning to fill a small array.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Thomas de Groot
Subject: Re: how to prevent overlapping random objects?
Date: 22 Aug 2010 03:10:05
Message: <4c70cd4d$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"stbenge" <myu### [at] hotmail com> schreef in bericht
news:4c6ff729$1@news.povray.org...
> It's getting close... got the (simple) GUI, now I need to tackle vector.h,
> which will probably be the easy part. Thanks for the encouragement! :)
It's worth the while, isn't it?
Thomas
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Alain
Subject: Re: how to prevent overlapping random objects?
Date: 22 Aug 2010 12:59:30
Message: <4c715772@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Alain wrote:
>>> Yeah, it's really horrible. POV's SDL wasn't meant to be quick at
>>> everything...
>>>
>>> So far, my C++ implementation is very fast, for not being coded with ASM
>>> and all. I was able to implement a few speedups, like not using
>>> sqrt(x*x+y*y) for *every pixel*, but instead making a 1/4 circle 2D
>>> array and picking from that.
>>
>> What's the fastest? sqrt(x*x+y*y) or sqrt(x^2+y^2)
>> In POV-Ray SDL, the second, as sqrt(pow(x,2)+pow(y,2)), is faster.
>> Don't know how it compare in C/C++ or other compiled languages.
>>
>> May be worth testing.
>>
>> Alain
>
> Hmm, I was not aware that pow(n,2) was faster than n*n. I'll keep it in
> mind next time the issue comes up. In my program, sqrt(x*x+y*y) is only
> called at the very beginning to fill a small array.
If you only use it a few times, the speed gain is low. If you use it a
LOT, like in the function of an isosurface, then the difference get very
appreciable.
It's faster because every time you need the value of a variable, you
have to search for it and retreive it's value. Also, evaluating an
integer power is almost as quick as doing a multiplication.
Alain
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |