POV-Ray : Newsgroups : povray.beta-test : Code gets the processor too hot? Server Time
31 Oct 2024 19:50:07 EDT (-0400)
  Code gets the processor too hot? (Message 1 to 10 of 21)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Ger
Subject: Code gets the processor too hot?
Date: 1 Apr 2013 18:38:45
Message: <515a0c75@news.povray.org>
Consider the following code;

// A first try at a "Simple eroder"

#version 3.7;
   global_settings {
		    ambient_light 0
		    adc_bailout 0.09 
		    max_trace_level 200 
		    noise_generator 3
		    assumed_gamma 1.0
		  }
		  
		  
#include "shapes.inc"


#declare WindDirection = -1;
#declare Particles = frame_number*50;
#declare ParticleRandom = seed(1); 
#declare ParticleSize = seed(1);



// A simple column object
#declare Object = union {
  cone {<0, 12, 0>, 6, <0, 50, 0>, 3}
  #for (CC, 0, 8)
    cylinder {<-6, 12, 0>, <-3, 50, 0>, 0.5 rotate y * CC * 45}
  #end
  torus {6, 1 translate y * 12}
  torus {7, 1 translate y * 11}
  torus {8, 1 translate y * 10}
  Round_Box_Union(<-10,-10,-10>, < 10, 10, 10>, 1)
  }

#declare Max = max_extent(Object);
#declare Min = min_extent(Object);

#macro Damage()
  #local Hit = false;
  #while (Hit = false)
//    #local ParticleOrigin = <0, 0, 0>;
    #local ParticleOriginX = -WindDirection * 1000;
    #local ParticleOriginY = Min.y + (Max.y - Min.y) * rand(ParticleRandom);
    #local ParticleOriginZ = Min.z + (Max.z - Min.z) * rand(ParticleRandom);
    #local ParticleOrigin = < ParticleOriginX, ParticleOriginY,  
ParticleOriginZ>;
    #local PointOfImpact = trace(Object, ParticleOrigin, <-1,0,0>);
    #if (vlength(PointOfImpact) > 0)
      #local Hit = true;
    #end
  #end
  sphere{PointOfImpact, (1 + rand(ParticleSize))/10}
#end

#macro Erode(ObjectToErode)
  #for (ParticleCount, 0, Particles, 1)
    #declare ObjectToErode =
      difference {
	object { ObjectToErode }
	Damage()
	}
  #end
  ObjectToErode
#end


#macro Erode1(ObjectToErode)
  #declare ObjectToErode =
    difference {
      object { ObjectToErode }
      #for (ParticleCount, 0, Particles, 1)
	Damage()
      #end
      }
  ObjectToErode
#end



object {Erode(Object) pigment {rgb 1}}


camera {
  location < 100,  60,  100>
  look_at <0,20, 0>
  direction z *   2.0
  right image_width / image_height * x
}

light_source {<  400, 1000, 500>*10, color 1.0 }
light_source {< -400, 1000, 500>*10, color 0.125 rotate y * 120 shadowless}
light_source {< -400, 1000, 500>*10, color 0.125 rotate y * -120 shadowless}

// End code

If I use the first Erode macro, the proc runs nicely with all cores at 100% 
and at normal work temp. When I otoh the Erode1 macro use, the parse times 
are obviously much shorter but the processor get way too hot when tracing 
the image.
-- 
Ger


Post a reply to this message

From: clipka
Subject: Re: Code gets the processor too hot?
Date: 1 Apr 2013 21:38:52
Message: <515a36ac$1@news.povray.org>
Am 02.04.2013 00:38, schrieb Ger:
>
> If I use the first Erode macro, the proc runs nicely with all cores at 100%
> and at normal work temp. When I otoh the Erode1 macro use, the parse times
> are obviously much shorter but the processor get way too hot when tracing
> the image.

"100% CPU load" does not mean that the CPU actually runs at its full 
potential - it only means that the CPU is constantly busy in /some/ way, 
whether it is actually computing stuff or just waiting for the main 
memory to deliver data.

The simpler your scene is, the less memory it takes as a whole, and 
therefore the more of it can be kept in the CPU caches; as a result, the 
CPU spends more time doing actual work than waiting for main memory 
operations to complete.

A well-designed computer should be ok even at full throttle. However, 
not all computers are well-designed with respect to thermal management, 
and POV-Ray has a habit of making the CPU sweat like no other application.

If you are worried that your CPU might overheat, the most obvious 
solution is to reduce the number of work threads.

Note that the maximum thermal limit varies between different CPUs. There 
are also huge differences in what happens when the limit is exceeded: 
Current Intel CPUs are known to handle thermal issues very graciously, 
being designed to automatically throttle their performance (or in the 
worst case simply halt themselves entirely) before reaching fatal core 
temperatures. In contrast, AMD CPUs have a reputation for failing 
catastrophically and suffering permanent damage.


Post a reply to this message

From: Ger
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 02:45:10
Message: <515a7e76$1@news.povray.org>
clipka wrote:

> Am 02.04.2013 00:38, schrieb Ger:
>>
>> If I use the first Erode macro, the proc runs nicely with all cores at
>> 100% and at normal work temp. When I otoh the Erode1 macro use, the parse
>> times are obviously much shorter but the processor get way too hot when
>> tracing the image.
> 
> "100% CPU load" does not mean that the CPU actually runs at its full
> potential - it only means that the CPU is constantly busy in /some/ way,
> whether it is actually computing stuff or just waiting for the main
> memory to deliver data.

If you look at the code then you'll see that in both cases the object in 
view is something like

difference {
  union {
    box {}
    cone {}
    torus{}
    }
  50 x frame_number // for each iteration the same
  sphere{}
  }

The big difference is how the placement of the little spheres is calculated 
during parse time. And as povray only uses 1 core when parsing a piece of 
code it won't overheat the processor.

> 
> The simpler your scene is, the less memory it takes as a whole, and
> therefore the more of it can be kept in the CPU caches; as a result, the
> CPU spends more time doing actual work than waiting for main memory
> operations to complete.

Shouldn't matter here because in both cases the object data is the same.

> 
> A well-designed computer should be ok even at full throttle. However,
> not all computers are well-designed with respect to thermal management,
> and POV-Ray has a habit of making the CPU sweat like no other application.

True, but beside the point. 

> 
> If you are worried that your CPU might overheat, the most obvious
> solution is to reduce the number of work threads.

Obvious, but not true. Even running on only 2 cores the processor gets 
significantly hotter when using the Erode1 macro

> 
> Note that the maximum thermal limit varies between different CPUs. There
> are also huge differences in what happens when the limit is exceeded:
> Current Intel CPUs are known to handle thermal issues very graciously,
> being designed to automatically throttle their performance (or in the
> worst case simply halt themselves entirely) before reaching fatal core
> temperatures. In contrast, AMD CPUs have a reputation for failing
> catastrophically and suffering permanent damage.

Also very true, but equally beside the point.
I'm not worried that my processor will overheat, it won't. What I'm trying 
to find out how that little change in the code can make such a large 
difference in core temperature. iow, processor load.

The main difference between the 2 code segments is that in the first I 
difference 1 sphere from an object and declare that as the new object and do 
the next difference and so on until I have differenced 1000's of spheres 
from the original object. In the second code segment I difference 1000's of 
spheres from the original object in one big swoop

Btw, I forgot to mention;
Povray 3.7 RC7 running on an AMD FX8-core with Opensuse 12.3

And as an added test I ran the same code on
AMD X64 dual core and an Intel Quad core with the same results. Both with 
the same OS and Povray version.

-- 
Ger


Post a reply to this message

From: scott
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 05:30:13
Message: <515aa525$1@news.povray.org>
>> The simpler your scene is, the less memory it takes as a whole, and
>> therefore the more of it can be kept in the CPU caches; as a result, the
>> CPU spends more time doing actual work than waiting for main memory
>> operations to complete.
>
> Shouldn't matter here because in both cases the object data is the same.

I don't think the object data is the same, in one case you have a 
difference object with N+1 child objects, in the other one you have N 
nested difference objects, each with 2 objects.

My suspicion is the nested objects cause a lot more "memory" type work 
for the processor during rendering (reading pointers, transform data 
etc) and as such even though the CPU is at "100%" it's having an easy 
time waiting for slow memory operations to complete.

How do the CPU temperatures vary as you change the number of particles - 
are they much closer with just 1 or 2 particles?


Post a reply to this message

From: clipka
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 07:38:52
Message: <515ac34c@news.povray.org>
Am 02.04.2013 08:45, schrieb Ger:
>
> If you look at the code then you'll see that in both cases the object in
> view is something like
>
> difference {
>    union {
>      box {}
>      cone {}
>      torus{}
>      }
>    50 x frame_number // for each iteration the same
>    sphere{}
>    }
>

Nope; the code the Erode macro generates is

difference {
   difference {
     difference {
       object { ObjectToErode }
       sphere {}
     }
     sphere {}
   }
   sphere {}
}

whereas the code the Erode1 macro generates is

difference {
   object { ObjectToErode }
   sphere {}
   sphere {}
   sphere {}
}

Note that POV-Ray doesn't collapse nested differences into a single one 
(although it would probably be a good idea).


Post a reply to this message

From: Stephen
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 07:58:02
Message: <515ac7ca$1@news.povray.org>
On 02/04/2013 7:45 AM, Ger wrote:
> I'm not worried that my processor will overheat, it won't.

In case anyone else sees the subject and thinks that it might be 
relevant to them as their processor overheats when rendering.
My laptop was shutting itself down when I was using SSL as it was 
overheating. (The problem was a broken fan blade trapped inside the fan.)
I found an application called TThrottle which throttles the CPU when a 
set CPU or GPU temperature is reached.

http://efmer.eu/boinc/

-- 
Regards
     Stephen


Post a reply to this message

From: Warp
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 10:43:09
Message: <515aee7d@news.povray.org>
Ger <ger### [at] gmailcom> wrote:
> When I otoh the Erode1 macro use, the parse times 
> are obviously much shorter but the processor get way too hot when tracing 
> the image.

Yes, there's a super-secret function in povray that instructs the CPU to
raise its temperature.

Seriously though, CPU temperatures are really not a problem of applications
(especially not compute-intensive ones.) If your CPU gets too hot, it's a
problem with your hardware. There may be several causes for that, such as:

- The CPU is not getting enough ventilation. This may be caused by poor
  chasis design, or not having enough fans (or them having been installed
  in the wrong places.)

- The CPU might not be getting enough ventilation because of too much dust
  on its heatsink. You should check that.

- Wrong BIOS settings can cause the CPU fan to either spin too slowly
  (causing overheat) or too fast (causing fan noise that's way louder
  than it has to be.)

-- 
                                                          - Warp


Post a reply to this message

From: Paolo Gibellini
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 12:18:19
Message: <515b04cb$1@news.povray.org>
>Warp  on date 02/04/2013 16.43 wrote:
> Ger <ger### [at] gmailcom> wrote:
>> When I otoh the Erode1 macro use, the parse times
>> are obviously much shorter but the processor get way too hot when tracing
>> the image.
>
> Yes, there's a super-secret function in povray that instructs the CPU to
> raise its temperature.
>
> Seriously though, CPU temperatures are really not a problem of applications
> (especially not compute-intensive ones.) If your CPU gets too hot, it's a
> problem with your hardware. There may be several causes for that, such as:
>
> - The CPU is not getting enough ventilation. This may be caused by poor
>    chasis design, or not having enough fans (or them having been installed
>    in the wrong places.)
>
> - The CPU might not be getting enough ventilation because of too much dust
>    on its heatsink. You should check that.
>
> - Wrong BIOS settings can cause the CPU fan to either spin too slowly
>    (causing overheat) or too fast (causing fan noise that's way louder
>    than it has to be.)
>
Even a power supply not enough accurate in current erogation can cause a 
raise of processor temperature.
Paolo


Post a reply to this message

From: Ger
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 13:13:50
Message: <515b11ce$1@news.povray.org>
Warp wrote:

> Ger <ger### [at] gmailcom> wrote:
>> When I otoh the Erode1 macro use, the parse times
>> are obviously much shorter but the processor get way too hot when tracing
>> the image.
> 
> Yes, there's a super-secret function in povray that instructs the CPU to
> raise its temperature.

I knew it :)

> 
> Seriously though, CPU temperatures are really not a problem of
> applications (especially not compute-intensive ones.) If your CPU gets too
> hot, it's a problem with your hardware. There may be several causes for
> that, such as:
> 
> - The CPU is not getting enough ventilation. This may be caused by poor
>   chasis design, or not having enough fans (or them having been installed
>   in the wrong places.)
> 
> - The CPU might not be getting enough ventilation because of too much dust
>   on its heatsink. You should check that.
> 
> - Wrong BIOS settings can cause the CPU fan to either spin too slowly
>   (causing overheat) or too fast (causing fan noise that's way louder
>   than it has to be.)
> 

All true and all known to me (I have build and sold computers for ~15 
years). But this still leaves the question why a small change in code can 
raise the temperature of the cpu

-- 
Ger


Post a reply to this message

From: Ger
Subject: Re: Code gets the processor too hot?
Date: 2 Apr 2013 13:20:50
Message: <515b1372@news.povray.org>
clipka wrote:

> Am 02.04.2013 08:45, schrieb Ger:
>>
>> If you look at the code then you'll see that in both cases the object in
>> view is something like
>>
>> difference {
>>    union {
>>      box {}
>>      cone {}
>>      torus{}
>>      }
>>    50 x frame_number // for each iteration the same
>>    sphere{}
>>    }
>>
> 
> Nope; the code the Erode macro generates is
> 
> difference {
>    difference {
>      difference {
>        object { ObjectToErode }
>        sphere {}
>      }
>      sphere {}
>    }
>    sphere {}
> }
> 
> whereas the code the Erode1 macro generates is
> 
> difference {
>    object { ObjectToErode }
>    sphere {}
>    sphere {}
>    sphere {}
> }
> 

True, I stand corrected.

> Note that POV-Ray doesn't collapse nested differences into a single one
> (although it would probably be a good idea).

I have looked at the source code to find out as to what might possibly cause 
this, but it's several miles beyond my knowledge of code. (I don't go much 
further then "hello world")

-- 
Ger


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

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