Quote:
Originally Posted by rkomar
That would be true for tasks that can use multiple cores at once, but as I said earlier, I kind of doubt that rendering PDF pages is such a task. PDFs are not just made up of data like an image or an HTML page is. The PDF contents are really programs meant for a state engine, i.e. each instruction is executed a certain way that depends on the current state of rendering at that moment. For example, the instruction may be to draw a line from point A to point B. How the line is drawn (thickness, foreground colour, background colour, line style, corner style,...) depends on the engine state. The bits of state can be changed at any time during the rendering of a page, so the only way to know that the state is correct when you get to a certain instruction is to start from one of the set points where the state is known (usually the beginning of a page) and work through all the instructions from there to the current point. There is also no way that CPU 1 can work on the first half of the page while CPU 2 works on the second half, because CPU2 won't know what state to start from until CPU1 is done. There might be instructions that can somehow be farmed out to multiple CPUs (I don't really know), but I don't expect there are that many of those.
That said, two CPUs can work on two separate pages without interfering with each other. That doubles the RAM requirements, though.
Perhaps modern PDF versions break up the pages into separate "programs" that can be individually rendered. It's been over a decade since I did any programming on PDF renderers, and things may have changed since then. If so, multiple CPUs could be used to render a PDF page, but it would depend on the version of PDF that the document is stored in. Older versions would still only work with one CPU per page, no matter how complex.
|
Different CPUs for different pages makes the most sense. RAM is cheap and is one of the specs that people would look at (even those that don't know what it represents).