Re: Why RosAsm Breaks on a large number of symbols

• Previous message: wolfgang kern: "Re: [OT] PID and windows xp"
• In reply to: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Next in thread: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Reply: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 14 Jul 2004 21:28:11 +0200

> With a work load in front of me the size of Mount Everest, I am not
> interested in wasting the time testing out your example code,
>
Too bad, wouldn't be more than ~5 minutes of work. Can you, then, post
the code snippet with CreateProcess+CloseHandle that causes crashing
on your box, including the steps taken to reproduce the bug? I would be
very interested if there's a problem with my technique on even a single
windows box (not caused by hardware problems, of course.)
I have code deployed running on NT4, 2k, xp and various 9x versions,
but I might have missed some 9x + upgrade versions.

> I have long ago had successful working code using WaitForSingleObject()
> so its not that I need your advice or coding style.
>
While my code snippet included WaitForSingleObject, this was not the
focus - the point of interest was whether you could duplicate windows
crashing caused by the CloseHandle's in the code snippet.

What causes the crash, anyway? ANY invocation of shell, or only
certain circumstances like missing executable, dos/win16/win32s
executables, etc?

> To satisfy a number of other people I benchmarked the two techniques
> and the one you have kept trying to inflict is no better in
> performance terms to the original design I continue to use, opinion is
> one thing, benchmarking is another and I go for the benchmarking over
> your opinion every time.
>
I'd say ~100% CPU usage with a lot of kernelmode time is a pretty good
indication that something is wrong. You might not be able to benchmark
this if you're just timing before and after the 'shell' call, but if you're
looking at general system performance when running multiple processes,
the performance difference _will_ be appearant - at least with the XP
scheduler. I believe that Jibz runs win2k though, and if you look at his
figures from task manager, he reports 100% CPU usage on your method, too:
http://www.masmforum.com/viewtopic.php?t=3323&start=0

I even took the time to run your shelltst... sure enough, leak test leaks
handles like mad (look at task manager, 'Performance' tab). It isn't THAT
bad if you're on NT, it would take a lot to bring down a box because of
handle leaking there (and at most you would get an application crash), but
still: as long as the handle isn't closed, you have a kernel-mode object
in memory, and kernel mode memory is something you don't want to waste too
much of. "shell" and "shell2" have 100% CPU usage, while "shell1" remains
at 0.

Now, if you actually want to benchmark WaitForSingleObject vs. the polling
loop, you should do some long and heavy work in the child process, and see
how long it takes before the child process terminates.

PS: child process should not set realtime priority class, as this prevents
other non-realtime threads from running, and thus isn't a very good
demonstration of how your shell() method affects performance under normal
multitasking conditions.

> There is the register preservation issue that you still parrot
> incorrectly by not properly understanding what is happening
>
Then tell me, please, where I am wrong? Let's try it this way:

1) By "register preservation", I mean "make sure that, on exit of your
   code, the register holds the same value as on entry." - this implies
   that you must save the contents of the register _IF_ you modify it.
   You must preserve ebx, esi, edi, esp, ebp, eflags.direction, fs - not
   sure about fp stack or SSE registers (I _think_ they are trashable,
   though.) Furthermore, ESP must remain 4-byte aligned.

2a) The only place, when dealing with regular ring3 usermode code,
    where windows _forces_ you to do register preservation, is in
    callbacks. Failing to do preservation will cause crashes depending
    on windows and service pack version.

2b) Because of the calling convention used, windows is free to trash
    the registers not mentioned in (1) across API calls. This means
    that, if you need their contents after an API call, you must save
    their contents.

3) In your own routines, you're free to use whatever calling convention(s)
   you want. Nothing in windows stops you from doing this. There's usually
   not much reason to use a custom calling convention, though, and sticking
   with STDCALL can make debugging easier and certainly makes it easier for
   other people to reuse your code.

...so, where's the error(s) in the above? The wording is probably different
than from the thread you're referring to, but the content is the same (well,
should be, I'm sorry for my inadequate English skills.) (and well, mostly
the
same - I'm not sure I mentioned fp, eflags and 4-aligned stack back then.)

> then there is the next recycle of your views on how one form of memory
allocation
> is better than the others
>
Which I still stand by. I also still say that the time differences will be
minimal (hell, even hardly detectable) under most circumstances. However,
one
of the things I preach is that you shouldn't use Memory-Mapped Files for
generic memory allocation, and there certainly are disadvantages by doing
this.
One of them is a "theoretical" issue wrt. additional pagefaults, the other
is
that MMF on 9x is allocated from the shared memory space, which is very
limited.
(This also shows that I still do care about 9x, as NT doesn't have this
defect.)

> and the list of blunders goes on and on with the same level of persistence
> that you keep dragging up your mistakes over running synchronous
processes.
>
Since I can, consistently, show 100% CPU usage and sluggish system behaviour
with your polling loop vs. the 0% CPU usage of WaitForSingleObject, I fail
to see how I am mistaken on this issue. Jibz backs me up, and I don't think
you can sprout any "virus-writing" libel about him. If you look at how
windows
works internally, like Inside Windows 2000 by Solomon & Russinovich (you
know,
the guy from www.sysinternals.com), it should be pretty clear _why_ the
WaitForSingleObject approach is optimal.

Now, if WaitForSingleObject would fail to work under some circumstances,
like
running DOS/win16/win32s/OS2/POSIX/Native executables, there _would_ be a
point
against using it.

PS: if you haven't done already, you should fix the bug in Ernie's
BitmapFrom*
routines, there's a double free - and yes, this does cause problems:
http://board.win32asmcommunity.net/showthread.php?s=&threadid=17448
The fix is easy:
http://board.win32asmcommunity.net/showthread.php?s=&threadid=18573

> I have told you that the Gospel according to f0dder does not sit on my
> bookshelf with Knuth, MASM, VC and the like and it never will, your
> repeated raising of so many issues where you have continued to be
> wrong has never been a technical issue, it is one of you trying to
> extend your influence at the expense of someone else where there is a
> simple solution to a person in your position who wants to become a
> guru in programming, actualy produce something useful instead of being
> a talking head and you will pick up the influence that you appear to
> need.
>
There we go, patronization and libel again. I've never claimed that I'm
a guru, and I don't particularly care for "influence" in a virtual realm
("influence" over _WHAT_?).

I do, however, care about code. I don't like inefficient code, and I
cringe when I see bugs. And when bugs don't get fixed... Oh well, with
Jibz' WCRT lib and donkey's various libraries, there's hardly much reason
to stick with the masm32 libraries. And Jibz & Donkey fix bugs and listen
to suggestions for improvements :-)

• Previous message: wolfgang kern: "Re: [OT] PID and windows xp"
• In reply to: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Next in thread: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Reply: hutch--: "Re: Why RosAsm Breaks on a large number of symbols"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]