Jim Holsenback <jho### [at] povrayorg> wrote:
> sometimes my scene would parse the just as it pops up the preview window 
> it freezes, and requires a kill -9 to get it to let go. After the kill 
> -9 and with no scene file changes and resubmit the render ... it worked 
> just fine. One time I let it keep going because I'd thought I was being 
> impatient ... next morning it was still hung and fuxtex or mutex (I 
> forget) was the process table hog ... that's boost trying to allocate 
> correct?

  That sounds to me like a livelock caused by a race condition.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Jim Holsenback <jho### [at] povrayorg> wrote:
> > On 04/11/2011 09:41 PM, Tor Olav Kristensen wrote:
> > >
> > > I get this error message:
> > > "Parse Error: bad allocation  Render failed"
> > > - after the code below has been running for about 3 seconds.
> > >
> > > // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
> > >
> > > #version 3.7;
> > >
> > > #while (true)
> > >    #local Fn = function { transform { translate<0, 0, 0>  } }
> > >    #undef Fn
> > > #end // while
>
> > where does the conditional get set to false ... don't see that here (or
> > any other bail-out mechanism) ... runaway loop?
>
>   I don't think that's the point. The above code doesn't look like it should
> give any kind of error. Instead, it should just run indefinitely.

Yes, that was my intention.

I have been running the same code (without the version directive) on POV-Ray
version 3.6.2.msvc9-sse2 for over 7 hours on another Windows XP SP3 PC.

67.801.367.203 tokens have been parsed so far without any problems.

--
Tor Olav
http://subcube.com

Post a reply to this message

Am 12.04.2011 14:21, schrieb Christian Froeschlin:
> Tor Olav Kristensen wrote:
>
>> Can anyone else see this problem ?
>
> Don't see it here with 64-bit version on Windows 7.
>
> However, memory use increases by 1.2 GB during parsing
> before going into into saturation. So whether the bad alloc
> occurs may simply be due to available memory.

I can confirm this for Win XP x64 (same 1.2 GB).

I'll have a look at it with a debugger, maybe there's something to be found.

Post a reply to this message

Am 12.04.2011 02:41, schrieb Tor Olav Kristensen:
>
> I get this error message:
> "Parse Error: bad allocation  Render failed"
> - after the code below has been running for about 3 seconds.
>
> // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
>
> #version 3.7;
>
> #while (true)
>    #local Fn = function { transform { translate<0, 0, 0>  } }
>    #undef Fn
> #end // while
>
> // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

Having had a closer look at the code, I can confirm that this problem 
indeed depends on the amount of memory installed in, and/or addressable 
by, the user's computer.

As of now, POV-Ray "only" allows a maximum of 1048575 functions per 
scene. Unfortunately, this is also the number of entries in a certain 
table of function-related data POV-Ray allows before it re-uses entries 
marked as deleted.

While this is good for parse speed in scenes using a lot of functions 
(POV-Ray doesn't have to waste time searching the table for undef'd 
entries), it's fatal for scenes re-defining functions over and over again.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 12.04.2011 02:41, schrieb Tor Olav Kristensen:
> >
> > I get this error message:
> > "Parse Error: bad allocation  Render failed"
> > - after the code below has been running for about 3 seconds.
> >
> > // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
> >
> > #version 3.7;
> >
> > #while (true)
> >    #local Fn = function { transform { translate <0, 0, 0> } }
> >    #undef Fn
> > #end // while
> >
> > // ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7
>
> Having had a closer look at the code, I can confirm that this problem
> indeed depends on the amount of memory installed in, and/or addressable
> by, the user's computer.
>
> As of now, POV-Ray "only" allows a maximum of 1048575 functions per
> scene. Unfortunately, this is also the number of entries in a certain
> table of function-related data POV-Ray allows before it re-uses entries
> marked as deleted.
>
> While this is good for parse speed in scenes using a lot of functions
> (POV-Ray doesn't have to waste time searching the table for undef'd
> entries), it's fatal for scenes re-defining functions over and over again.

I see.

I was just playing around with the new mesh_camera feature. For each triangle in
a mesh for a camera, I did a couple of vtransform() calls. (And if I have
understood things right, a mesh camera needs a lot of triangles...)

Perhaps it would be a good thing to make the vtransform() internal to POV-Ray
instead of just a macro (?)

--
Tor Olav
http://subcube.com

Post a reply to this message

> ... (And if I have understood things right, a mesh camera needs a lot
> of triangles...)

   Not necessarily: you can use an uv-mapped mesh with distribution #3
and the smooth option. But I don't know if this is convenient in your
case...

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Am 13.04.2011 00:27, schrieb Tor Olav Kristensen:

> Perhaps it would be a good thing to make the vtransform() internal to POV-Ray
> instead of just a macro (?)

It is quite an important macro, so as long as macros in .inc files are 
the performance killers they currently are, it might indeed be a good 
idea. Then again, maybe it would be better to put some effort into 
speeding up .inc file macros in the first place.

As for the runaway memory consumption you discovered, that's obviously 
not limited to vtransform(), so a fix is needed anyway (and is actually 
already implemented by now, waiting to be released).

Post a reply to this message

Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:

> > ... (And if I have understood things right, a mesh camera needs a lot
> > of triangles...)
>
>    Not necessarily: you can use an uv-mapped mesh with distribution #3
> and the smooth option. But I don't know if this is convenient in your
> case...

Thank you for the tip Jaime.

I hadn't got around to experiment with that distribution type yet.
(Mostly because I find their descriptions a bit difficult to understand.)

But now I have just tried it with just 2 triangles in a mesh.
- and it works fine =)

If anybody else is interested, here's how I did it:

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

#include "colors.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare H = 2;
#declare W = H*image_width/image_height;

#declare SimpleMesh =
  mesh2 {
    vertex_vectors {
      4,
      <-W, -H, 0>,
      <+W, -H, 0>,
      <+W, +H, 0>,
      <-W, +H, 0>
    }
    uv_vectors {
      4,
      <0, 0>,
      <1, 0>,
      <1, 1>,
      <0, 1>
    }
    face_indices {
      2,
      <0, 1, 2>,
      <2, 3, 0>
    }
  }

camera {
  mesh_camera {
    1
    3
    mesh2 { SimpleMesh }
  }
}

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

sphere {
  -10*z, 1
  pigment { color Cyan }
}

light_source {
  <1, 1, 0>*10
  color White
}

background { color (Gray + Blue)/4 }

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

--
Tor Olav
http://subcube.com

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.04.2011 00:27, schrieb Tor Olav Kristensen:
>
> > Perhaps it would be a good thing to make the vtransform() internal to POV-Ray
> > instead of just a macro (?)
>
> It is quite an important macro, so as long as macros in .inc files are
> the performance killers they currently are, it might indeed be a good
> idea. Then again, maybe it would be better to put some effort into
> speeding up .inc file macros in the first place.

Yes, I agree.
But the vtransform() macro is a bit difficult to speed up ;)

> As for the runaway memory consumption you discovered, that's obviously
> not limited to vtransform(), so a fix is needed anyway (and is actually
> already implemented by now, waiting to be released).

That's good to hear.

--
Tor Olav
http://subcube.com

Post a reply to this message

Am 15.04.2011 23:37, schrieb Tor Olav Kristensen:
> clipka<ano### [at] anonymousorg>  wrote:
>> Am 13.04.2011 00:27, schrieb Tor Olav Kristensen:
>>
>>> Perhaps it would be a good thing to make the vtransform() internal to POV-Ray
>>> instead of just a macro (?)
>>
>> It is quite an important macro, so as long as macros in .inc files are
>> the performance killers they currently are, it might indeed be a good
>> idea. Then again, maybe it would be better to put some effort into
>> speeding up .inc file macros in the first place.
>
> Yes, I agree.
> But the vtransform() macro is a bit difficult to speed up ;)

Like any macro that resides in an .inc file, you /can/ speed up its 
execution by copying it into your .pov file instead.

Post a reply to this message