> 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 ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki! maillist : [email protected] / 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 ___________________________________________________________________________________
