ghostscript on dual processors in linux smp kernel 
Author Message
 ghostscript on dual processors in linux smp kernel

Is there a way to run ghostscript in linux utilizing both cpu's? when
its processing ps's into pdf's it only uses one processor. I can start
up a second ghostscript instance on another job and it will use the
other processor, but it wont use both cpus on one job. Anyone have any
ideas? Would it be multithreaded if I built the ghostscript from
source?

thanks!
Bob



Sun, 06 Feb 2005 05:30:34 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>Is there a way to run ghostscript in linux utilizing both cpu's? when
>its processing ps's into pdf's it only uses one processor. I can start
>up a second ghostscript instance on another job and it will use the
>other processor, but it wont use both cpus on one job. Anyone have any
>ideas? Would it be multithreaded if I built the ghostscript from
>source?

How would you envisage the process of postscript to PDF being split
over threads?  What part of the interpretation task lends itself to
multiprocessing?
----------------------------------------

Please support usenet! Post replies and follow-ups, don't e-mail them.


Sun, 06 Feb 2005 05:42:17 GMT  
 ghostscript on dual processors in linux smp kernel


Quote:
> Is there a way to run ghostscript in linux utilizing both cpu's? when
> its processing ps's into pdf's it only uses one processor. I can start
> up a second ghostscript instance on another job and it will use the
> other processor, but it wont use both cpus on one job. Anyone have any
> ideas? Would it be multithreaded if I built the ghostscript from
> source?

To your three questions, No, No, No.
Ghostscript normally runs single threaded.  It would only make use
of multiple CPUs if it was written to share tasks between threads.
This is not the case for the PDF writer.
The only use of threads in ghostscript is when printing
(rendering is on one thread, writing to the spooler is on another)
but this doesn't give you any speed gain, and there is also
some provision for asynchronous rendering which is
not used by default.  As far as I know, the pdf writer does not
use the async rendering.


Sun, 06 Feb 2005 06:00:09 GMT  
 ghostscript on dual processors in linux smp kernel
man, that's a bummer, I noticed that distiller only uses one processor
in nt4...

thanks for the reply! (and not talking down your nose like the guy
above)-lol

also, take a look at http://www.rrust.com/linuxpdfserver_howto.html

I have been using that process for 6 months in a few offices we have
and its been working great, I had to customize a ppd to get the colors
to come out right. Many people complain about the 60 seconds it waits
till processes the ps files. Any idea a better way of doing it?? I
wouldn't mind using watch folder or nnotify, but if it started on a
big job, it would do it before it will go back and start on any
others. Right now, it works great, because people can submit multiple
jobs and it will work on them concurrently in different processes.

thanks!
Robert

Quote:



> > Is there a way to run ghostscript in linux utilizing both cpu's? when
> > its processing ps's into pdf's it only uses one processor. I can start
> > up a second ghostscript instance on another job and it will use the
> > other processor, but it wont use both cpus on one job. Anyone have any
> > ideas? Would it be multithreaded if I built the ghostscript from
> > source?

> To your three questions, No, No, No.
> Ghostscript normally runs single threaded.  It would only make use
> of multiple CPUs if it was written to share tasks between threads.
> This is not the case for the PDF writer.
> The only use of threads in ghostscript is when printing
> (rendering is on one thread, writing to the spooler is on another)
> but this doesn't give you any speed gain, and there is also
> some provision for asynchronous rendering which is
> not used by default.  As far as I know, the pdf writer does not
> use the async rendering.



Sun, 06 Feb 2005 22:58:12 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>man, that's a bummer, I noticed that distiller only uses one processor
>in nt4...

>thanks for the reply! (and not talking down your nose like the guy
>above)-lol

Sorry you saw it that way.  I was (and am) mystified how anyone who
seems to understand enough about multiprocessors to ask this question
could think converting PostScript to PDF a good candidate for
splitting over processors.
----------------------------------------

Please support usenet! Post replies and follow-ups, don't e-mail them.


Sun, 06 Feb 2005 23:17:55 GMT  
 ghostscript on dual processors in linux smp kernel
you right, I am an idiot
Quote:


> >Is there a way to run ghostscript in linux utilizing both cpu's? when
> >its processing ps's into pdf's it only uses one processor. I can start
> >up a second ghostscript instance on another job and it will use the
> >other processor, but it wont use both cpus on one job. Anyone have any
> >ideas? Would it be multithreaded if I built the ghostscript from
> >source?

> How would you envisage the process of PostScript to PDF being split
> over threads?  What part of the interpretation task lends itself to
> multiprocessing?
> ----------------------------------------

> Please support usenet! Post replies and follow-ups, don't e-mail them.



Sun, 06 Feb 2005 23:23:32 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>you right, I am an idiot

(snip)

It seemed like quite a good question to me - it was possible that
you'd figured something out that we hadn't. It's best to only read
things into articles if somebody literally wrote them into them.

-- Mark



Mon, 07 Feb 2005 00:02:03 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>Is there a way to run ghostscript in linux utilizing both cpu's? when
>its processing ps's into pdf's it only uses one processor. I can start
>up a second ghostscript instance on another job and it will use the
>other processor, but it wont use both cpus on one job. Anyone have any
>ideas? Would it be multithreaded if I built the ghostscript from
>source?

gs does not support it. However, you could cut your jobs into halves
and let two gs processes convert each part individually. Of course,
the resulting pdf files have to be merged afterwards. PDF should be
easier to merge than PostScript.

73, Mario
--

PGP-Key available at http://www.klebsch.de/public.key
Fingerprint DSS: EE7C DBCC D9C8 5DC1 D4DB  1483 30CE 9FB2 A047 9CE0
 Diffie-Hellman: D447 4ED6 8A10 2C65 C5E5  8B98 9464 53FF 9382 F518



Mon, 07 Feb 2005 03:03:31 GMT  
 ghostscript on dual processors in linux smp kernel


Quote:
> man, that's a bummer, I noticed that distiller only uses one processor
> in nt4...

> thanks for the reply! (and not talking down your nose like the guy
> above)-lol

Aandi's replies are usually worth reading.
Sometimes the answers indicate he has answered the question too many
times :)
Sometimes people answer a question with another question.
In this case, I think Aandi was simply trying to let you know
that the PS -> PDF process didn't really lend itself to running
on multiple CPUs.  Other tasks like video encoding do lend
themselves to multiple CPUs, because there are tasks that can
be done in parallel, but I wouldn't try doing that task in PostScript.

Quote:
> also, take a look at http://www.rrust.com/linuxpdfserver_howto.html

I'll bookmark that.


Mon, 07 Feb 2005 05:57:50 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:


>>man, that's a bummer, I noticed that distiller only uses one processor
>>in nt4...

>>thanks for the reply! (and not talking down your nose like the guy
>>above)-lol
>Sorry you saw it that way.  I was (and am) mystified how anyone who
>seems to understand enough about multiprocessors to ask this question
>could think converting PostScript to PDF a good candidate for
>splitting over processors.

Well, there is

1.      PS-interpretation
2.      PDF-generation, with high-CPU tasks such as flate and dct-coding

Doesn't seem unreasonable to me.  Furthermore, a DSC-compliant
Postscript could do pages independently, etc.

Marcel



Mon, 07 Feb 2005 06:43:39 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:



>>>man, that's a bummer, I noticed that distiller only uses one processor
>>>in nt4...

>>>thanks for the reply! (and not talking down your nose like the guy
>>>above)-lol

>>Sorry you saw it that way.  I was (and am) mystified how anyone who
>>seems to understand enough about multiprocessors to ask this question
>>could think converting PostScript to PDF a good candidate for
>>splitting over processors.

>Well, there is

>1.  PS-interpretation
>2.  PDF-generation, with high-CPU tasks such as flate and dct-coding

I had seem this as the only viable split. However, I had been thinking
of PDF generation as a very light CPU task.  You are right that
encoding is potentially high CPU.  Still, it is not on a par with
pixel rendering and halftoning.  Let's pull a figure from the air -
20% of the CPU used in PDF generation.  In that case, and assuming
that multi-threading added no overheads, and that all of the PDF
generation overlapped all the interpretation, this could yield a
saving of 25%.  Overlapping is the key, of course. In a one page PDF
the potential for overlapping may be none at all.

Nevertheless, if GhostScript already supports parallel rendering, this
may be a saving possible with access to the source code.

Quote:

>Doesn't seem unreasonable to me.  Furthermore, a DSC-compliant
>Postscript could do pages independently, etc.

That is an interesting idea. I have heard of printers that can do that
to achive very high throughput.  I see a problem, in that the
"typical" PostScript job now has very large prologues.  Could it be
that in a one page file, the prologue interpretation is now more time
consuming than the page itself?  If so, savings would require more
than two processors.  At least four, since one would be doing the
splitting, preferably more.

This would not of course be GhostScript's job, but some rather scary
interface sat on top of it.  Whether anyone has the kind of work
requiring it, and the kind of multiprocessor equipment that could
benefit from it, AND a guaranteed DSC workflow, is an interesting
question.

Thanks for your thoughts.
----------------------------------------

Please support usenet! Post replies and follow-ups, don't e-mail them.



Mon, 07 Feb 2005 16:40:24 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:


> > [...]  Furthermore, a DSC-compliant
> >Postscript could do pages independently, etc.

> That is an interesting idea. I have heard of printers that can do that
> to achive very high throughput.  I see a problem, in that the
> "typical" PostScript job now has very large prologues.  Could it be
> that in a one page file, the prologue interpretation is now more time
> consuming than the page itself?  If so, savings would require more
> than two processors.  At least four, since one would be doing the
> splitting, preferably more.

Ideally, the prologue could be interpreted once and the resulting graphics
context held in shared memory where the process/thread for each page would
use it, ideally in a way that allows each process/thread to keep changes
"private" so the prologue context isn't changed (otw each page would
need to make its own copy).  One approach to massively parallel
processing uses checkpoint/restart methods to migrate processes between
CPU's.  You could envison starting ghostscript, checkpointing
after the prologue has been interpreted and then restarting a
copy for each page of the document. In practice I suspect you might find
it useful to add a few new PS primitives to make this easier.

Quote:
> This would not of course be GhostScript's job, but some rather scary
> interface sat on top of it.  Whether anyone has the kind of work
> requiring it, and the kind of multiprocessor equipment that could
> benefit from it, AND a guaranteed DSC workflow, is an interesting
> question.

The language support needed to support efficient parallel PS rendering
sounds like something for PostScript 4.0 should have.  There are
enough roles for SMP hardware (web page serving, etc.) that practical
systems are becoming available at attractive prices.

--



Mon, 07 Feb 2005 20:33:01 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:
>The language support needed to support efficient parallel PS rendering
>sounds like something for PostScript 4.0 should have.  There are
>enough roles for SMP hardware (web page serving, etc.) that practical
>systems are becoming available at attractive prices.

An interesting idea. On the other hand, PDF already has all the
language support needed for that, and I don't see much take-up of the
idea. Perhaps I'm just not looking at the right market segment.
----------------------------------------

Please support usenet! Post replies and follow-ups, don't e-mail them.


Mon, 07 Feb 2005 20:46:22 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>>Well, there is

>>1.      PS-interpretation
>>2.      PDF-generation, with high-CPU tasks such as flate and dct-coding
>I had seem this as the only viable split. However, I had been thinking
>of PDF generation as a very light CPU task.  You are right that
>encoding is potentially high CPU.  Still, it is not on a par with
>pixel rendering and halftoning.

That depends.  Anyway, no pixel rendering or halftoning in PDF
generation.

Quote:
> Let's pull a figure from the air -
>20% of the CPU used in PDF generation.

Well, that number is the crucial factor, and we simply don't
know what it is.  Cannot know.  For example, many practically
relevant files consist primarily of large amounts of image
data.  Interpretation here takes essentially no time at all,
whereas encoding will be rather expensive.

Depending on the circumstances of the file, you could even
have several encoding/compression jobs running in parallel,
with the resulting PDF-streams appended to the PDF whenever
they're done (out-of-band images are a fine idea).

[..]

Quote:
>>Doesn't seem unreasonable to me.  Furthermore, a DSC-compliant
>>Postscript could do pages independently, etc.
>That is an interesting idea. I have heard of printers that can do that
>to achive very high throughput.  I see a problem, in that the
>"typical" PostScript job now has very large prologues.  Could it be
>that in a one page file, the prologue interpretation is now more time
>consuming than the page itself?

Yes, in a one page job.

Quote:
>If so, savings would require more than two processors.

Not necessarily.  It seems you are assuming one would process
Prologue + Page for each page.  This is not necessary, just feed
the prologue once for each thread and then pump pages.

Quote:
>This would not of course be GhostScript's job, but some rather scary
>interface sat on top of it.

Well, I wouldn't want to do any of this with Ghostscript, I find
the code rather a bit of a nightmare.

Quote:
> Whether anyone has the kind of work
>requiring it, and the kind of multiprocessor equipment that could
>benefit from it, AND a guaranteed DSC workflow, is an interesting
>question.

True.  Especially when you have jobs that claim to be DSC-compliant
but aren't.  Incidentally, PDF-Extreme actually uses a PS->PDF
pre-processing step to get guaranteed page-independence for
subsequent high-speed parallel ripping.

Marcel



Mon, 07 Feb 2005 21:28:31 GMT  
 ghostscript on dual processors in linux smp kernel

Quote:

>Well, there is

>1.      PS-interpretation
>2.      PDF-generation, with high-CPU tasks such as flate and dct-coding

>Doesn't seem unreasonable to me.  Furthermore, a DSC-compliant
>Postscript could do pages independently, etc.

Well, that would be reasonable if both a) the cycle split between the two
tasks was reasonably close to 50-50, which it very rarely is, and b) you didn't
get cache thrashing - since you'll presumably be wanting to compress large
images, it seems that thrashing is almost guaranteed.

High resolution PS rendering is a far better candidate for
fine-grained multi-threading than distillation.  However, it's probably
significant that Adobe never released any multi-threaded RIPs (apart from some
obscure hacks for Xerox printers that never got much exposure, I seem to
remember) until Extreme, which uses coarse-grained multi-threading to
distribute PDF to a render farm, splitting the job up at the page level.  Much
like Interpress did in the early '80s:-)

There were never any multi-threaded Jaws RIPs at all.  Hyphen developed one,
but doing so bankrupted the company.  Harlequin had one, but it only sold in
small numbers.

Listen to what the market is telling you;-)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ian Kemmish                   18 Durham Close, Biggleswade, Beds SG18 8HZ, UK

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
``Behind every successful organisation stands one person who knows the secret
  of how to keep the managers away from anything truly important.''



Tue, 08 Feb 2005 01:38:17 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. The One Page Processor, a PostScript word processor.

2. Will Math Co-processor help ??? (ghostscript)

3. Panic: Kernel Fault

4. Linux, Ghostscript and PDFs

5. Ghostscript w/o X windows on linux

6. WordPerfect 7 for Linux crashing Ghostscript

7. AutoCAD 2002 PS and Linux Ghostscript

8. Configuring ghostscript margins on Linux.

9. Ghostscript and ms font encodings (Linux/X)

10. Solved: Missing fonts, ghostscript and Linux

11. Linux GhostScript Troubles

12. Ghostscript Windows and Linux

 

 
Powered by phpBB® Forum Software