Re: Which assembler can handle the BIG stuff ?
- From: "wolfgang kern" <nowhere@xxxxxxxxxxx>
- Date: Mon, 25 Jul 2005 06:38:36 +0200
"Frank Kotler" <fbkotler@xxxxxxxxxxx> schrieb im Newsbeitrag
news:UdydnUPkCrouoHnfRVn-3g@xxxxxxxxxxxxxx
| wolfgang kern wrote:
| > Thanks Annie,
| >
| > | > but I have no clue what 'X' you mean here.
| > | > Don't care ...
| > | > __ _____
| > | > wolfgang ((( `\
| > | _ _`\ )
| > | Frank is talking about the (^ ) )
| > | X-Window GUI on Linux, Wolfie. ~-( )
| > | _'((,,,)))
| > | As you know, the Linux GUI ,-' \_/ `\
| > | is not a part of the O.S. ( , |
| > | It's a separate application, `-.-'`-.-'/|_|
| > | somewhat like WinDoze 3.xx. \ / | |
| > | =()=: / ,' aa
| >
| > I see, it could be compared to my 2KB OS-core module
| > (native graphics/coloured text).
|
| You could say "compared" - unfavorably. "Contrasted" might be better. I
| expect your 2K has less functionallity than the full-blown "X windows
| system"... but not proportionally so.
|
| > But what I then not understand is the huge speed difference
| > for counting character occurence in a memory image... ?
|
| The problem is that with all the "graphics cruft" in memory, I'm
| swapping pages to disk. I've "only" got 128M of physical ram. Minimum
| requirement for X plus KDE (a fat "window manager") is 192M or something...
|
| > Let me estimate how long it would take on my old 500 Mhz AMD:
| >
| > 38 MB somewhere in RAM, lets point it by esi,
| > reserve a cleared result-field (table) for counts of interest
| > ie: 256*4 bytes and let edi point to
| >
| > mov esi,... ;source
| > mov edi,... ;result-array
| > mov ecx,... ;the size of it (non-zero)
| > loop:
| > movzx al,[esi]
|
| movzx ???
|
| > inc esi
| > ;cmp al,20h ;*only if a filtered range is desired
| > ;jc nocnt
| > ;cmp al,80h
| > ;jnc nocnt
| > inc dword[edi+eax*4]
|
| How's this compare to "add [...], 1"?
|
| > nocount: ;*
| > dec ecx
| > jnz loop ;or JNS/JNGE if endmark included in size
| > --- and that's it.
| > (* I doubt any filter will increase speed here,
| > so I'd just ignore unwanted results.)
|
| Right. This is our "inner loop", more or less. Anything we do here
| happens for each character, so "wasting" a bit of memory to count
| "ignored" characters is a speed increase, compared to any "special
| caseing", AFAICS.
|
| > 1024 bytes results (only a temporary needed buffer!)
| > plus just a handful code bytes.
| >
| > Takes (w/o filter) 8..10 cycles per iteration,
| > which I would count as 304..380 Mcycles,
| > which is less (~0.75) than a second on an 500 MHz machine.
|
| I'm only doing 300MHz, but - given some memory to work in - I'm seeing
| results in this ballpark.
|
| > I forgot to sort and display the result ?
|
| Yeah, but this is done once, not once per character, so it isn't going
| to add that much.
|
| > Ok, I'd use KESYS Fn50 to create a formatted, sorted table
| > which would take ~200 mS on an 1024*768, 8-bit color full screen.
|
| Well, I haven't got "Fn50", but I think I get the idea. I don't sort
| anything (yet). Sorting algorithms have "been done", but might be worth
| discussing. The "newer guys" (including myself) can learn something, and
| the "experts" can show off how smart they are... and *they* might learn
| something, too!
|
| > So all together is less than a second on my old 500 MHz.
|
| As I said, at 300MHz I'm not quite matching that, but getting close.
| I've got a reply to write to Alex, then maybe I'll post some more
| (crude) code. Probably in a brand new thread - as you observed, this
| one's getting cluttered.
|
| Best,
| Frank
.
- References:
- Re: Which assembler can handle the BIG stuff ?
- From: wolfgang kern
- Re: Which assembler can handle the BIG stuff ?
- From: Annie
- Re: Which assembler can handle the BIG stuff ?
- From: wolfgang kern
- Re: Which assembler can handle the BIG stuff ?
- From: Frank Kotler
- Re: Which assembler can handle the BIG stuff ?
- Prev by Date: Re: Introducing "f0dder.lib" and "f0dder.inc" for MASM.
- Next by Date: Re: Which assembler can handle the BIG stuff ?
- Previous by thread: Re: Which assembler can handle the BIG stuff ?
- Next by thread: Re: Which assembler can handle the BIG stuff ?
- Index(es):
Relevant Pages
|