POV-Ray : Newsgroups : povray.unix : Slow parsing from networked drives : Re: Slow parsing from networked drives Server Time
24 Apr 2024 07:25:25 EDT (-0400)
  Re: Slow parsing from networked drives  
From: clipka
Date: 11 Jun 2016 04:21:25
Message: <575bca05@news.povray.org>
Am 11.06.2016 um 01:36 schrieb mcanance:
> Friends, I'm trying to use a cluster at my university to speed up my renders.
> The rendering parallelizes well (+SR and +ER in a job array), but for some
> reason the parsing stage is just horribly slow when I'm using networked storage.
> I believe the connection to the storage is over gigabit ethernet.
> If I have povray read from the networked storage, it takes 4 minutes to parse
> 22M tokens, and 34 seconds to render.

The parser is an interpreter which reads directly from whatever files
your scene is comprised of, and unfortunately it does so over and over
again for any loops or macro invocations.

The worst performance hogs are macros invoked repeatedly from a
different file than where they're defined, as it will cause the
macro-containing file to be opened and closed over and over again.

The current plan is to clean up POV-Ray's internal architecture, then
throw away the interpreting parser and replace it with a LLVM-based
embedded compiler, which would only read each file once, compile it into
bytecode, maybe even storing it for later re-runs, and ultimately run as
native machine code using JIT-compilation. The scene description
language would also be redesigned along the way.

Obviously it'll take a while to get there.


A short-term solution would be to let the parser buffer macros in
memory-backed pseudo-files, but the parser is a crooked old thing that
we prefer to touch as little as possible. It's like a Jenga tower late
in the game. So nobody has explored this possibility far enough to
result in a viable implementation.

Your post may serve to trigger a re-evaluation of this route, but no
promise there.


> I tried looking at the source, but I didn't see the culprit. I did see that
> there's an IMemStream in fileinputoutput.h that looks like it would do the
> trick, but I haven't been able to figure out how it works.

At present, the IMemStream is just a hack to allow for running the
benchmark from the binary alone, without having to properly install
POV-Ray; to this end, the TTF files that are installed by POV-Ray are
also embedded in the binary itself, and the IMemStream allows the
TrueType geometric primitive code to access these embedded copies as if
they were proper files. That's all the IMemStream is currently capable of.


Post a reply to this message

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