28 Aug
2009
28 Aug
'09
8:34 a.m.
> You cannot start processing page 500 before you know where page 499 > wil end. TeX is not really a kind of application where you would gain > a lot by parallelization. And honestly, I don't remember seing many > applications using both cores. (Plus: I'm happy if other applications > continue to run smoothly instead of being blocked by TeX using 95% of > both processors.) Hm, not so sure. Think for example to a book with 3 chapters, and you know at priori that there are not relations among them (references etc). You can 1) typeset each of them in a concurrent way, 2) recompose the final document to correct pagenumbers and build indeces (this is a TeX concurrency ) > >> It could be useful for offering typesetting services. I'm thinking about >> having a computation service like alpha.wolfram but with ConTeXt. Like >> ConTeXt online but benefit from multiple processors.... > > If you would offer a service, you would get multiple requests at the > same time anyway, so there's no real need for that in this case It's another kind of concurrency, it's about servers and OS (apache - Linux vs IIE - Windows server etc) > You can try XeTeX if you want to put load on both processors. It does > offer a parallel process as far as I heard, but then you'll probably > want support for quad-core once you get a better computer :) Again, another kind of concurrency. it's about luatex or pdftext or xetex C programs -- luigi