From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)> wrote in
message news:ehcvq55h4l9lrobkpabb2m31ve22nvffd4(a)
>I had forgotten that! And I DID tell him about
> Denser than depleted uranium.
> What is amazing is his persistence in using technically
> incorrect terminology even after
> it has been carefully explained to him what is going on.
> For example, a desire to
> allocate contiguous physical memory should have been the
> first clue that he had no idea
> what virtual memory was. And his persistence in equating
> virtual memory (which, at its

If all that other stuff that is going on under the covers is
sufficiently analogous to the simpler case, then it is a
communication error to specify these extraneous and
essentially irrelevant details. These extra details impede
the communication process.

In other words the simpler less exactly precise terms are
more correct (within the goal of effective communication)
than the complex precisely correct terms because the
precisely correct terms impede the clarity and conciseness
of communication.

> essensce, is merely a mapping mechanism to physical
> memory) with paging activity (an
> add-on to virtual memory that allows oversubscription to
> physical memory). Because he
> once heard about it 25 years ago in an introductory course
> and misremembered what was
> going on! And his insistence on closed-form analytic
> solutions to problems for which this
> is impossible, and boiling things down to their essence,
> which he doens't do but claims to
> have done!
> It must be some form of OCD that keeps me coming back
> here. If I had one form, I'd keep
> washing my hands over and over, hoping I'll get them
> clean; my form is that I seem to
> believe that if I keep telling Peter the same thing over
> and over, perhaps he'll get it! I
> should go get treatment (all good programmers are
> obsessive in some way; that's how we get
> to be good; a friend one reported he was under treatment
> for his OCD, and when I told him
> that his obsession with detail made him one of the best
> programmers I'd ever known, he
> said "yes, but it was spilling over into my life outside
> programming". I should find out
> who his doctor is. Then maybe I could stop hanging out
> here anwering Peter's bizarre
> questions)
> (And what I was saying back then was RUN THE %&*ING
> joe
> On Sun, 28 Mar 2010 03:44:56 -0400, Hector Santos
> <sant9442(a)> wrote:
>>Peter Olcott wrote:
>>> Here is how you tell Windows not to ever swap this
>>> memory
>>> out.
>>Peter, people told you this many times. I know I did and
>>indicated AWE to you and guess what so did Joe. So please
>>act like
>>you discovered something new, when in in fact, this whole
>>thing seems
>>just another duplicate episode.
>>Folks, I'm surprise Joe doesn't remembers, but check out
>>incredible Peter O. vs the World thread back in December
>>and a more flatter version to read:
>>I see people provided test code, even JOE did testing for
>>him on
>>Same old stuff, same incompetence. Many of the same
>>characters too!
> Joseph M. Newcomer [MVP]
> email: newcomer(a)
> Web:
> MVP Tips:

From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)> wrote in
message news:59dvq5hm93akvsglotlbc9lejh94dcgqvf(a)
> See below...
> On Sat, 27 Mar 2010 22:55:14 -0500, "Peter Olcott"
> <NoSpam(a)> wrote:
>>"Joseph M. Newcomer" <newcomer(a)> wrote in
>>message news:e9jtq5pav683bb9qgcfrvmkg439nribmno(a)
>>> Seee below...
>>> On Thu, 25 Mar 2010 17:27:37 -0500, "Peter Olcott"
>>> <NoSpam(a)> wrote:
>>>>So I have been convinced for several days now that
>>>>multi-threads could be a good idea. I still see no
>>>>of adding memory mapped files to this mix. You have
>>>>explicitly failed to point out any incremental benefit
>>>>I get from memory mapped files over multiple threads
>>>>the same memory in the case where data remains resident
>>>>memory as my testing has shown that it does. (I will
>>>>test this on Linux).
>>> ***
>>> I believe I pointed out that it is likely to result in
>>> FEWER page faults, since parts of
>>As I have said over a dozen times; GIVEN the immutable
>>premise that there are no page faults, then within the
>>explicit context of this immutable premise ONLY, how can
>>memory mapped files help? AND apparently the answer is
>>can not help in this case.
> ****
> Why is this premise immutable? That's the difference
> between religion and science.

Head games again.
Given as in Geometry.

> Religion assumes all premises are immutable, and science
> assumes that every premise is
> merely a temporary state subject to change based on
> observed data.
> I'm saying that if you abandon your bizarre model and
> start doing REAL engineering, you
> could end up with significantly improved performance!
> ****
>>If you don't answer this time I will give up on you as
>>playing head games with me.
> ****
> The only "head game" I'm trying to play with you is called
> "EDUCATION". I'm trying to
> teach you how to ENGINEER systems instead of just tossing
> them together, applying
> unreleasitic models of behavior, and getting bent out of
> shape when anyone questions your
> "immutable" premises.
> ****
>>> the DFA you don't access don't actually have to be
>>> brought
>>> in. And the initialization is
>>> going to be faster than several minutes, because there's
>>> nothing to "read in" and no
>>> storage allocation is going to be required!
>>> Is this not screamingly obvious? Just from basic
>>> principles?
>>> ****
>>It is screamingly utterly pointless when as I have said
>>initialization is a three minutes every three months
>>It is the 24/7/365 that needs to be optimized, NOT the
>>minutes every three months.
> *****
> Yet there are still unresolved issues about how the OS
> manages these instances, and the
> MMF model means that what the OS has to manage is much
> smaller, resulting in overall
> better throughput under particular scenarios (such as the
> multiprocess model that most Web
> servers assume). As such, it can simplify your
> engineering to have a model that allows a
> simpler Web service architecture which gives the
> performance leverage that a MMF will
> give. If you stopped to actually THINK about any of this
> instead of giving knee-jerk
> reactions when it violates your "immutable" premises,
> you'd realize what is going on here.
> ****
>>>>What you do instead is continue to insist that data does
>>>>remain resident in memory. I will test this in Linux
>>> ****
>>> Interesting that in a later post you reveal that it
>>> DOESN'T remain resident in memory,
>>I don't remember ever saying this.
> ****
> What was that post about linux slowing down after 500MB or
> so? Or did I misread that?
>>I am considering this now. I tested Linux again and was
>>somewhat surprised that my process only gets a little less
>>than 500MB of the 2 GB before paging kicks in.
> to which I replied "Working Set". Did I misread this?
> ****
>>Substantial testing has confirmed that ALL the data from
>>process does remain in RAM for both Windows and Linux. AND
>>if nothing else, in Linux I can issue a simple command to
>>forbid the OS from paging out my data. I can apply this
>>command to every aspect of the process including stack
> *****
> This seems to contradict your original post.
> ****
>>> proving that I was right; I stated that you have no
>>> guarantees. Or are those numbers
>>> about how linux slows down pure fiction? I think they
>>> prove what I said, and that it is
>>> true in linux (and it looks like a Working Set issue,
>>> which I pointed out somewhere in my
>>> first response to your post).
>>> joe
>>> ****
>>>>> Joseph M. Newcomer [MVP]
>>>>> email: newcomer(a)
>>>>> Web:
>>>>> MVP Tips:
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)
>>> Web:
>>> MVP Tips:
> Joseph M. Newcomer [MVP]
> email: newcomer(a)
> Web:
> MVP Tips:

From: Pete Delgado on

"Peter Olcott" <NoSpam(a)> wrote in message
>> And did you read the fine print in it? the part that says
> Its all far far less convoluted in the OS that I will be using.

I have to ask this... I really do...

If you plan on developing on some magical OS where none of this is a problem
(or is "far les convoluted"), why are you posting your questions in a
Microsoft newsgroup?


From: Peter Olcott on

"Joseph M. Newcomer" <newcomer(a)> wrote in
message news:p5qvq55g635gdk1cfck6ul3jq8hhtfflq4(a)
> You mean that after all these years you have never visited
> my site? I know I've given
> citations to it before, and it doesn't take a profoundly
> deep set of neural responses to
> go visit my Web site, that appears in my sig block on
> every messsage I post!
> joe

I have visited your site. That's how I know so much about
Now that I know where to find the I/O Completion Port, I may
go look there sometime soon.

I am not quite at the point yet of needing this. If you
think that it makes are really good FIFO queue, it may be
the right way to go, and at least warrants further
examination. You did forget to tell me where to look.

> On Thu, 25 Mar 2010 09:50:45 -0500, "Peter Olcott"
> <NoSpam(a)> wrote:
>>"Joseph M. Newcomer" <newcomer(a)> wrote in
>>message news:r3pmq51rukj4j28ed9es0ob84ejblp7bpb(a)
>>> See below...
>>> On Wed, 24 Mar 2010 23:10:47 -0500, "Peter Olcott"
>>> <NoSpam(a)> wrote:
>>>>"Joseph M. Newcomer" <newcomer(a)> wrote in
>>>>>A multithreaded FIFO queue would make more sense; less
>>>>>chance of priority inversion
>>>>> effects. An I/O Completion Port makes a wonderful
>>>>> multithreaded FIFO queue with
>>>>> practically no effort!
>>>>> joe
>>>>How ?
>>> As I told you a few days ago, read my essay on the use
>>> of
>>> I/O Completion Ports on my MVP
>>> Tips site.
>>No you didn't. As you can see from what you said
>>above, you did not tell me where to find them.
>>> Of course, if I told you that GetQueuedCompletionStatus
>>> is
>>> the dequeue operation,
>>> PostQueuedCompletionStatus the enqueue operation, it
>>> should be completely obvious how to
>>> do it. Or you could have gone to I/O Completion Ports
>>> in
>>> the MSDN documentation and read
>>> about the API calls and derived this information because
>>> it is so triviial to see it.
>>> here's an enqueue operation, and a dequeue operation.
>>> What more do you need to see?
>>> joe
>>Fault tolerance.
>>> ****
>>> Joseph M. Newcomer [MVP]
>>> email: newcomer(a)
>>> Web:
>>> MVP Tips:
> Joseph M. Newcomer [MVP]
> email: newcomer(a)
> Web:
> MVP Tips:

From: Hector Santos on
Joseph M. Newcomer wrote:

> Do you know why IBM chose the Intel chip instead of the Motorola chip? It turns out they
> wanted the 68000 family, so IBM went to Motorola and said "We need K thousand chips per
> month, can we get them?" Motorola, who was busy supplying Apple, said "No way" and Intel,
> a little, barely viable chip company, said "Sure. Will that be enough or will you need
> more?" So they chose the company that said it could deliver product. It wasn't based on
> the architecture, it was based on the availability.

That could be. There was a mad rush too I'm sure there was plenty of
backroom, gulfing deals made.

Apple could of told Motorola - "Don't you dare."

But from my perspective in the corporate world, IBM was main stay and
so was Intel even before the PC even came along with its motherboard
slot frame hardware, iRMX OS and PL/M programming language for process
control. So if IBM wanted to get a 2nd foot into the corporate door,
Intel chips would be the logical choice. Honestly, it was because of
my early Intel x86 process control work at Westinghouse that I was so
easy for me to pick up on PC programming under DOS, OS/2 and then
Windows. I did Motorola programming work in college using Apple II
monitors and a few Robotics projects with motorola micro controllers -
pure C and ASM here :) (Side Irony, I just found my partner engineer
on these projects on FaceBook!)

Also, if you recall the story behind IBM PC, there was 1 year
deadline, it was the first time they wanted to do everything off the
shelf, and the two OS available, CP/M which began as PL/M both
developed by Kildall, and, QDOS that they looked at only worked for
intel chip. Kildall turned down IBM wanting higher royalties which
would be the first for IBM to lose control like this. IBM then turned
to Gates who got QDOS for $50,000 at the last moment of the project.