object references/memory access

[Karthik Gurusamy]

On Jul 2, 3:01 pm, Steve Holden <s... at holdenweb.com> wrote:
> Karthik Gurusamy wrote:
> > On Jul 1, 12:38 pm, dlomsak <dlom... at gmail.com> wrote:
> [...]
>
> > I have found the stop-and-go between two processes on the same machine
> > leads to very poor throughput. By stop-and-go, I mean the producer and
> > consumer are constantly getting on and off of the CPU since the pipe
> > gets full (or empty for consumer). Note that a producer can't run at
> > its top speed as the scheduler will pull it out since it's output pipe
> > got filled up.
>
> But when both processes are in the memory of the same machine and they
> communicate through an in-memory buffer, what's to stop them from
> keeping the CPU fully-loaded (assuming they are themselves compute-bound)?

If you are a producer and if your output goes thru' a pipe, when the
pipe gets full, you can no longer run. Someone must start draining the
pipe.
On a single core CPU when only one process can be running, the
producer must get off the CPU so that the consumer may start the
draining process.

>
> > When you increased the underlying buffer, you mitigated a bit this
> > shuffling. And hence saw a slight increase in performance.
>
> > My guess that you can transfer across machines at real high speed, is
> > because there are no process swapping as producer and consumer run on
> > different CPUs (machines, actually).
>
> As a concept that's attractive, but it's easy to demonstrate that (for
> example) two machines will get much better throughput using the
> TCP-based FTP to transfer a large file than they do with the UDP-based
> TFTP. This is because the latter protocol requires the sending unit to
> stop and wait for an acknowledgment for each block transferred. With
> FTP, if you use a large enough TCP sliding window and have enough
> content, you can saturate a link as ling as its bandwidth isn't greater
> than your output rate.
>
> This isn't a guess ...

What you say about a stop-n-wait protocol versus TCP's sliding window
is correct.
But I think it's totally orthogonal to the discussion here. The issue
I'm talking about is how to keep the end nodes chugging along, if they
are able to run simultaneously. They can't if they aren't on a multi-
core CPU or one different machines.


>
> > Since the two processes are on the same machine, try using a temporary
> > file for IPC. This is not as efficient as real shared memory -- but it
> > does avoid the IPC stop-n-go. The producer can generate the multi-mega
> > byte file at one go and inform the consumer. The file-systems have
> > gone thru' decades of performance tuning that this job is done really
> > efficiently.
>
> I'm afraid this comes across a bit like superstition. Do you have any
> evidence this would give superior performance?
>

I did some testing before when I worked on boosting a shell pipeline
performance and found using file-based IPC was very good.
(some details at http://kar1107.blogspot.com/2006/09/unix-shell-pipeline-part-2-using.html
)

Thanks,
Karthik

> >> Thanks for the replies so far, I really appreciate you guys
> >> considering my situation and helping out.
>
> regards
>   Steve
> --
> Steve Holden        +1 571 484 6266   +1 800 494 3119
> Holden Web LLC/Ltd          http://www.holdenweb.com
> Skype: holdenweb      http://del.icio.us/steve.holden
> --------------- Asciimercial ------------------
> Get on the web: Blog, lens and tag the Internet
> Many services currently offer free registration
> ----------- Thank You for Reading -------------