 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> On 6/19/2011 2:00, Chambers wrote:
> > 40pps :(
>
> The biggest (to me) unexpected slow-down was when I had something casting
> shadows that had a much-too-large bounding box, so every pixel was testing
> every light source for every shadow.
Well, I left it running overnight, and it hasn't finished the second radiosity
pass yet, so it's time to do some major optimizing - splitting the isosurfaces
into sections, tightening the bounding boxes, etc. Unfortunately, I can't do
much with the functions - in fact, one of the functions is already a
simplification, and needs to be a bit more complex to get the surface I want.
If I come up with something specific I need help with I'll post in the general
group for some ideas :)
On another note, remember what an annoyingly faithful proselytizer I used to be?
I'm now atheist. It took me a long time to admit it, but what people were
saying they believed didn't line up with what I actually saw happening in life.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19/06/2011 06:42 PM, Darren New wrote:
> On 6/19/2011 2:00, Chambers wrote:
>> 40pps :(
>
> The biggest (to me) unexpected slow-down was when I had something
> casting shadows that had a much-too-large bounding box, so every pixel
> was testing every light source for every shadow.
For me, it was when I tried to build a volumetric photon map.
I had a render which took 20 minutes or so. Turned on scattering media
and volumetric photon maps, and now the photon map alone takes 45
minutes to build. The actual render slowed to something absurd like 2
pixels per minute.
At that point, I concluded that volumetric photon mapping was just too
absurdly slow to ever use for anything.
Ten years later, I realise what the problem was. The photon map exceeded
my computer's memory capacity, causing the puny laptop harddrive to swap
like crazy for every individual pixel.
Perhaps if I get time, I'll go see if media sampling works now, ten
years after I first tried it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <bdc### [at] yahoocom> wrote:
> 40pps :(
This comment at the beginning of scenes/advanced/piece3/piece3.pov still
amuses me:
// Due to the large number of objects, you will probably have to
// have a lot of memory to render this scene.
// Rendering time using a 25Mhz 386 w/Cyrix fpu is approximately 60 hours.
It doesn't mention the resolution, but with a modern PC you can render
that scene in almost real-time even at a fair resolution (eg. 640x480).
Even a high resolution render (such as 1024x768) with antialiasing will
take less than 10 seconds.
(Btw, that comment in that scene file should never be removed or modified.
It's an outstanding testament of how much both PCs and POV-Ray itself have
advanced during the decades.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 21/06/2011 06:48 PM, Warp wrote:
> This comment at the beginning of scenes/advanced/piece3/piece3.pov still
> amuses me:
>
> // Due to the large number of objects, you will probably have to
> // have a lot of memory to render this scene.
> // Rendering time using a 25Mhz 386 w/Cyrix fpu is approximately 60 hours.
>
> It doesn't mention the resolution, but with a modern PC you can render
> that scene in almost real-time even at a fair resolution (eg. 640x480).
> Even a high resolution render (such as 1024x768) with antialiasing will
> take less than 10 seconds.
>
> (Btw, that comment in that scene file should never be removed or modified.
> It's an outstanding testament of how much both PCs and POV-Ray itself have
> advanced during the decades.)
Not just PCs. Take a look at this:
http://new.haveland.com/povbench/graphsky.php
At the bottom, we see that an Amiga powered by various flavours of
Motorola 68000 CPUs (with and without FPU) takes 8 hours to render the
same scene that a modern Intel Core 2 Duo or whatever can do in under 5
seconds.
That's a crapload of speed, right there.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Not just PCs. Take a look at this:
> http://new.haveland.com/povbench/graphsky.php
The official benchmark results are also interesting. It's incredible how
much faster a Xeon W3580 is than a Pentium 4 (which is what I have) at the
same clockrate, even when using just one core. While the latter takes about
25 minutes to render the benchmark, the former takes only a bit over 1 minute.
That's some *serious* speedup considering that they are running at the
same clock rate.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22/06/2011 06:40 PM, Warp wrote:
> The official benchmark results are also interesting. It's incredible how
> much faster a Xeon W3580 is than a Pentium 4 (which is what I have) at the
> same clockrate, even when using just one core. While the latter takes about
> 25 minutes to render the benchmark, the former takes only a bit over 1 minute.
>
> That's some *serious* speedup considering that they are running at the
> same clock rate.
It puzzles me how this is possible.
Sure, the Xeon probably has a much bigger cache and a slightly faster
bus to the RAM chips. But is that *all* that makes it faster? Or is
there more to it than that? I have no idea.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 22/06/2011 06:40 PM, Warp wrote:
>
>> The official benchmark results are also interesting. It's incredible how
>> much faster a Xeon W3580 is than a Pentium 4 (which is what I have) at
>> the
>> same clockrate, even when using just one core. While the latter takes
>> about
>> 25 minutes to render the benchmark, the former takes only a bit over 1
>> minute.
>>
>> That's some *serious* speedup considering that they are running at the
>> same clock rate.
>
> It puzzles me how this is possible.
>
> Sure, the Xeon probably has a much bigger cache and a slightly faster
> bus to the RAM chips. But is that *all* that makes it faster? Or is
> there more to it than that? I have no idea.
>
The Pentium 4 line is notorious ineffecient in it's use of the clock
cycles, and each of it's generations just got worst of than the previous
one. The problem was coined to an excessively long instruction pipe,
that got longer with each sub versions. It topped at over 200 steps...
It also greatly increased it's power requirments.
With the new core2, they chopped that down around 30~40 steps with the
performance boost, and power consumption decrease, we can now experiment.
A Xeon system use a more advanced I/O architecture and beter memory
management. It's instruction pipe is relatively short. It probably have
beter cache management as well as larger cache, both L1 and L2. It's L1
cache is probably distinct to the L2 cache, while the pentiums L1 cache
address space was included in the L2 address space.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> It puzzles me how this is possible.
>>
>> Sure, the Xeon probably has a much bigger cache and a slightly faster
>> bus to the RAM chips. But is that *all* that makes it faster? Or is
>> there more to it than that? I have no idea.
>
> The Pentium 4 line is notorious ineffecient in it's use of the clock
> cycles, and each of it's generations just got worst of than the previous
> one.
Isn't this roughly the timeframe when AMD, Cyrix and half a dozen others
suddenly popped up with compatible chips running at the same clock speed
yet delivering massively increased performance, and Intel were all like
"oh crap!"?
> The problem was coined to an excessively long instruction pipe,
> that got longer with each sub versions. It topped at over 200 steps...
> It also greatly increased it's power requirments.
>
> With the new core2, they chopped that down around 30~40 steps with the
> performance boost, and power consumption decrease, we can now experiment.
Why would you build something that's vastly harder to design yet
delivers awful performance? That doesn't make any sense. (I also don't
see how it's *possible* to have a 200-step instruction pipeline, unless
you were deliberately trying to be silly.)
> A Xeon system use a more advanced I/O architecture and beter memory
> management. It's instruction pipe is relatively short. It probably have
> beter cache management as well as larger cache, both L1 and L2. It's L1
> cache is probably distinct to the L2 cache, while the pentiums L1 cache
> address space was included in the L2 address space.
Can we really attribute all the performance advantages of 10 years of
R&D to a bigger cache and an on-board SDRAM controller?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> >> It puzzles me how this is possible.
> >>
> >> Sure, the Xeon probably has a much bigger cache and a slightly faster
> >> bus to the RAM chips. But is that *all* that makes it faster? Or is
> >> there more to it than that? I have no idea.
> >
> > The Pentium 4 line is notorious ineffecient in it's use of the clock
> > cycles, and each of it's generations just got worst of than the previous
> > one.
> Isn't this roughly the timeframe when AMD, Cyrix and half a dozen others
> suddenly popped up with compatible chips running at the same clock speed
> yet delivering massively increased performance, and Intel were all like
> "oh crap!"?
You are probably confusing it with the original Pentium. Cyrix and other
competitors were pretty much dead (or at least heavily struggling) by the
time of the P4. The only real competitor left was AMD.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> It puzzles me how this is possible.
>>>
>>> Sure, the Xeon probably has a much bigger cache and a slightly faster
>>> bus to the RAM chips. But is that *all* that makes it faster? Or is
>>> there more to it than that? I have no idea.
>>
>> The Pentium 4 line is notorious ineffecient in it's use of the clock
>> cycles, and each of it's generations just got worst of than the previous
>> one.
>
> Isn't this roughly the timeframe when AMD, Cyrix and half a dozen others
> suddenly popped up with compatible chips running at the same clock speed
> yet delivering massively increased performance, and Intel were all like
> "oh crap!"?
>
>> The problem was coined to an excessively long instruction pipe,
>> that got longer with each sub versions. It topped at over 200 steps...
>> It also greatly increased it's power requirments.
>>
>> With the new core2, they chopped that down around 30~40 steps with the
>> performance boost, and power consumption decrease, we can now experiment.
>
> Why would you build something that's vastly harder to design yet
> delivers awful performance? That doesn't make any sense. (I also don't
> see how it's *possible* to have a 200-step instruction pipeline, unless
> you were deliberately trying to be silly.)
Some high up conceptors and chief designers kept on increasing the pipe
to get "beter prehemptive computation and branching choices
optimisation". They saw improvements going from the pentium pro to the
pentium II, and then from the pentium II to the pentium III using that
strategy. They blinded themself to the fact that with the pentium III
they had gotten slightly past the point of diminishing improvement to
the point of NO improvement, and to the point of negative "improvement"
with the pentium 4 family.
They where also blinded by a clock speed race that they started. The
constant clock speed increace greatly contributed in hiding the decline
in efficiency.
And, yes, the instruction pipe if the pentium 4's was sily, and kept on
getting silyer over time. On the first P4, is was only about 120
instructions long, on the last P4 generation, is was well over 200.
>
>> A Xeon system use a more advanced I/O architecture and beter memory
>> management. It's instruction pipe is relatively short. It probably have
>> beter cache management as well as larger cache, both L1 and L2. It's L1
>> cache is probably distinct to the L2 cache, while the pentiums L1 cache
>> address space was included in the L2 address space.
>
> Can we really attribute all the performance advantages of 10 years of
> R&D to a bigger cache and an on-board SDRAM controller?
Not ALL of it, but a good part of it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
