Do named pipes have disk I/O ?? [Unix Programming]

Prev: Learn about proxy sites and how to use them to open blocked sites unlimited downloads from RapidShare and megaupload and increase the speed of the Internet with new sites for free
Next: Why can't I catch a SIGBUS on my Mac (when strlen(NULL) is used)?

From: Phil Carmody on 7 Apr 2010 17:57

"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
> The one thing that I know is that my fundamental process is
> about as memory intensive as a process can get.

It's quite possibly very badly designed, then.

> I also know
> in advance what the memory access patterns are much better
> than any cache algorithm could possibly infer.

What on earth does 'better' mean? If a cache algorithm cannot
infer them, then your memory access patterns are complete shite.

> Even if a
> cache algorithm could infer this pretty well it would
> necessarily waste a lot of time gaining this info.

And you're proud of this inefficiency? Why on earth didn't
you design your code to be efficient instead?

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

From: Phil Carmody on 7 Apr 2010 18:00

"Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
> "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote in
> message news:8739z7gdb6.fsf(a)kilospaz.fatphil.org...
>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>>> "Phil Carmody" <thefatphil_demunged(a)yahoo.co.uk> wrote:
>>>> "Peter Olcott" <NoSpam(a)OCR4Screen.com> writes:
>> ...
>>> The only issue is that the minimum
>>> sleep period seems to be one second, I could really use
>>> it
>>> to be 100 ms. I might have to build my own sleep system
>>> for
>>> this process.
>>
>> So you're attempting to optimising the system and reinvent
>> the
>> scheduler, and yet you've never heard of poll(2)? Why do I
>> feel
>> that's an unsurprising combination?
>
> I am working on providing a preemptive scheduling system
> whereby a process puts itself to sleep when another higher
> priority job becomes available.

Why do I find it unsurprising that you misuse the standard
terminology?

Why do you think that you, who doesn't even know about the
operating system you're working under, can implement its
features better than the OS itself?

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

From: David Schwartz on 7 Apr 2010 19:49

On Apr 7, 2:42 pm, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:

> The one thing that I know is that my fundamental process is
> about as memory intensive as a process can get. I also know
> in advance what the memory access patterns are much better
> than any cache algorithm could possibly infer. Even if a
> cache algorithm could infer this pretty well it would
> necessarily waste a lot of time gaining this info.

Bluntly, you have no idea what you're talking about.

> All that really needs to happen is to load my DFA recognizer
> directly into cache and not unload it from cache until
> recognition is complete.

That's sheer idiocy. If your recognizer hits, say, a page fault, how
does the page fault handler running ridiculously slow help your
recognizer run faster?

> This occurs naturally (reasonably
> well) if my process is the only one running. If another
> memory intensive process is time sliced in it screws up the
> cache resulting in a tenfold degradation to performance.

No, it doesn't. I already explained why.

> This analysis of the actual conditions would seem to
> indicate that the optimization that I propose might be
> better than the optimization that you propose.

You really are starting to seem uneducatable. You might be right 99%
of the time, but the system will be right 100% of the time. Just make
sure the system knows what you want, *not* how you think it should
give it to you.

DS

From: David Schwartz on 7 Apr 2010 19:52

On Apr 7, 8:40 am, "Peter Olcott" <NoS...(a)OCR4Screen.com> wrote:

> Here is a specific concrete example:
> I am assuming that all pwrite(), pread() and append()
> operations are atomic specifically because the kernel forces
> these to be executed sequentially. Is this the means that
> the kernel uses to make these operations atomic?

They are not atomic, and the kernel does not force them to be executed
sequentially.

It would be absolutely idiotic in the extreme for the kernel to delay
a process that attempted to 'pread' one byte from the beginning of a
file until a 'pwrite' to the end of that file from another process of
100MB from file 'mmap'ed from a slow NFS server finished.

DS

From: Ian Collins on 7 Apr 2010 19:57

On 04/ 8/10 11:49 AM, David Schwartz wrote:
>
> You really are starting to seem uneducatable.

That certainly applies to his quoting!

--
Ian Collins