Lars Huttar wrote:
Hello,

We've been using TeX to typeset a 1200-page book, and at that size, the
time it takes to run becomes a big issue (especially with multiple
passes... about 8 on average). It takes us anywhere from 80 minutes on
our fastest machine, to 9 hours on our slowest laptop.

often there are ways to optimize the document style

btw, in my laptop mk.tex which loads a bunch of real big fonts (esp punk slows down) does 10 pages/second (242 pages currently) so your setu opif probably not that efficient

So the question comes up, can TeX runs take advantage of parallelized or
distributed processing? As many in the computer industries are aware,
processor speed (clock rate) has plateaued; it is not going to continue
rising at the rate it had been. Hence the common move to dual-core,
quad-core, etc. machines. But applications in general cannot take
advantage of multiple cores to speed their work unless they are
architected to take advantage of them.

We googled around a bit but were surprised not to find any real
references to efforts at running TeX in parallel or on distributed
networks or clusters. Wouldn't this be something that a lot of people
would find useful? Or does everyone only use TeX for typesetting short
papers?

it all depends on what you process; for simple docs tex is rather fast:

\starttext

\setuplayout[page]

\dorecurse{1000}{\null\page}

\stoptext

such a run takes in mkiv:

5.944 seconds, 1000 processed pages, 1000 shipped pages, 168.237 pages/second

Sure, you can use manual tricks to speed up TeX processing.
You can "comment out" sections of a document, or select them via modes.
But then you have to remember where you did the commenting out, so you
can reverse it. And you have no guarantees as to whether the
inclusion/exclusion of section B will affect the layout of section C or not.

often it's inefficient font calls that slow down the job (or big graphics that one can skip including in a first pass)

Wouldn't it be nice if TeX (or a TeX wrapper, or macro package, or
"typesetting system") could take care of this for you?

mayne in the future we can do some parallization

also, i'm thinking of 'one run with prerolls' but it has no high priority (maybe i'll do it when i need it for a project)

What if you had a language -- or a few extensions to existing languages
-- to give your typesetting engine hints or commands about where to
split up your long document into fairly-independent chunks? What if you
designed your document specifically to be typeset in independent,
parallel pieces so that you could guarantee that you would get the same
result for section B whether or not you were typesetting the whole book
at the same time?

there are quite some dependencies of pages on each other (take cross refs and how they might influence a next run)

What if the typesetting system automated the stitching-back-together
process of the chunks, gathering page reference info from each chunk to
inform the next iteration of typesetting the other chunks?

this is an option when you have to reprocess parts of the documents often

Has anyone been working on this already? It seems like it must have been
discussed, but I don't know where to go to look for that discussion.

if i were you i'd first look into optimizing the style

Hans

-----------------------------------------------------------------
                                          Hans Hagen | PRAGMA ADE
              Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
     tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
                                             | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Reply via email to