groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] groff performance in respect to hardware platform


From: Steffen Nurpmeso
Subject: Re: [Groff] groff performance in respect to hardware platform
Date: Fri, 25 Mar 2016 12:04:40 +0100
User-agent: s-nail v14.8.6-171-gc05ee4b

Steve Izma <address@hidden> wrote:
 |On Wed, Mar 23, 2016 at 11:21:37PM -0400, Steve Izma wrote:
 |> Subject: Re: [Groff] groff performance in respect to hardware platform
 |> 
 |>> ... But I'm wondering if anyone can tell me if groff benefits
 |>> from running on multiple CPU cores and multiple CPUs.
 |>> I assume that another way of asking this: "is groff
 |>> multithreaded?"

 |Damian's comment might be relevant to the viewing process (and
 |definitely for the other graphics-oriented concerns I have) but
 |one counter-indication is how I observe okular working. Up to
 |about 50 pages, the PostScript file is completely written before
 |okular attempts to re-read it. The screen update is very fast.
 |But if I'm viewing, say, page 90 the PS file (being written
 |apparently in chunks by grops) is noticed by okular as having
 |its timestamp changed, so it reads whatever in can get, can't
 |find page 90, so displays page 50. Strangely enough, it doesn't
 |seem to notice that the file has had more pages added to it after
 |this point, so I'm stuck looking at the wrong place in the
 |output. This implies either an I/O problem or else one part of
 |the pipeline (I don't think it's the python parsing) is lagging
 |behind.

Let groff write into fileA, move that to fileB and open your
viewer on that one?

 |> Looking at spawn-pipe.c, the only parallelization you get in groff is
 |> the pipeline of preprocessing, formatting, and rendering.  
 |> 
 |> ISTM that's all you *can* get because the formatting process --
 |> determining which words go on each line -- is necessarily sequential.
 |> The whole-paragraph formatting algorithm Doug McIllroy proposed some
 |> time back worked in parallel, but each paragraph would still be rendered
 |> serially.  
 |
 |Thanks for looking at the code, which reinforces the above
 |comments. I think you're correct about the limitation caused by
 |the serial nature of typesetting, but I wonder if the non-h&j
 |processes, like I/O and perhaps even things to do with font data,
 |could be done in parallel? E.g., if, like in a PostScript file,
 |one stated at the beginning of a tmac file all the fonts that are
 |going to be needed then having font info compilation as a
 |separate thread -- this might work? (Not that I'm volunteering; I
 |couldn't begin to understand how to code that.)

Regarding myself i think that it will take several years of basic
homework until i will be able to think about such things.  I hope
i have a compilable and usable roff at the end of this summer
(late enough it'll be), but from what i have seen yet things are
pretty complex and i for one don't like coding bypasses to achieve
a goal fast, generally speaking.  Because, if you do this for
multiple features and several then you have a dead-end codebase,
and that is something that i don't like.  Sure, what is known from
me in public is not the sunniest side of coding possible, at least
so far, but in general i try to iterate over code until it is,
yes, a kind of beauty.  I.e., something of value, like a Japanese
knife or sword that has been folded manually thousands of times.
Or real Rolls-Royce back in the day with hand fitted (the german
word is "dengeln", i can't seem to find the right english
translation) fenders - a man, some metal and three days of hard
work.  And having tea.

It has become clear, i have no idea.  But i would be surprised if
by pure design the core of troff could be parallelized that much,
because of all the traps etc.  What you say, maybe.  I think it is
easier in something like Markdown or RTF or a full Word processor
where paragraph boundaries and all attributes of a paragraph are
clear and fully specified on the input side, so then it is
thinkable that you can fully parallelize the "painting" of the
lines that make up a complete paragraph, and then simply merge
those threads of paintings together for the final target, taking
care for orphan and widow lines etc.  In reality reality may crush
this utopia forcefully, however.

--steffen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]