Re: HLA Lib

On Mar 19, 5:37 pm, "vid...@xxxxxxxxx" <vid...@xxxxxxxxx> wrote:
Actually, the "separate predicting number of digits before padding"
was researched quite well. Take a look at the threads over in CLAX for
the idea.

can you post links please?

Somewhere around here:

http://groups.google.com/group/comp.lang.asm.x86/browse_frm/thread/10d700ae72794f05/47cfd647cb8731c5?lnk=gst&q=Terje+Subtraction+ASCII+Decimal+AMD&rnum=1&hl=en#47cfd647cb8731c5


I tried a *lot* of different ways to do generic numeric
conversion. (actually, the "subtract" algorithm in the library still
needs to be replace by Terje's algorithm; "subtract" is faster on a P4
[where I developed the code], but Terje's algorithm is faster on most
other processors).

allright, i will do some comparison to FASMLIB speed. (and maybe steal
some faster HLAlib algos) We'll see, algos in FASMLIB are simple (not
optimized) and straightforward.

Don't steal mine at this point, grab Terje's. It's a little faster on
most processors except the P4 (which has a broken multiply
instruction).


The first memory-management call sets things up. There is no
"finishing code" required for heap management.

I looked at your heap manager a little. First of all - do you rely on
system to clean up all mappings after your app? That isn't very nice
way to do things, and shouldn't occur in professional code.

Aw, that's a myth. All modern OSes guarantee that they clean this sort
of stuff up. You don't want to get in the *habit* of not freeing up
resources and so on, but when done *on purpose*, as is the case here,
there's nothing wrong with it. The OS behavior is well-documented.
Closing all files with the process terminates is *guaranteed* by the
OS. Why waste the code in the application to redundantly do this?
Professionalism has nothing to do with it. It's the *intention* that
counts. And this example is intentional.


Personally i think aligning blocks to 8 bytes is not enough,

I probably could agree with this statement.

especially if you use dynamic strings often (i believe HLA does this).
I decided to set 64 byte aligning, wasting more memory if there are
lot of blocks, but making small consectutive enlargings of block much
faster.

I think 64 bytes is too much. 16 bytes is probably about right (so
that you're guaranteed 16-byte alignment for certain SSE operands).
OTOH, HLA's memory manager actually does align to 16 bytes + 8, so
getting 16-byte alignment is pretty easy -- just allocate 8 extra
bytes and bump the returned address up by 8.

The problem with a large granularity on the allocation is that typical
programs make a *lot* of small memory requests. In particular, the
average string length you'll find in a program is quite small. Another
example is an assembler. Consider FASM, for example. It makes *lots*
of small memory requests. You don't want to force the end user to wind
up writing their own heap manager because using the library one winds
up wasting a lot of space. As for enlarging blocks, I don't see that
happening all that often, and when it does a "power of two"
enlargement algorithm almost always works better than a linear
progression. For example, in HLA v1.89 when building the source files
in memory, I allocate something like 4MB for the main source file and
if I ever exceed that amount (unlikely), I reallocate to 8MB. After
that, I would reallocate to 16MB, etc. Reallocation can be a *very*
expensive process; if it's going to happen frequently, I argue that
the user should be able to control the reallocation algorithm rather
than leaving it hidden inside the memory manager.

BTW, reallocations are one area where the HLA memory manager *isn't*
all that great. To reduce fragmentation, the HLA memory manager
allocates blocks from the end of the heap on down. This makes it
unlikely that reallocation will simply consist of extending the size
of the current block. OTOH, it *does* make the first-fit algorithm
that HLA uses run incredibly fast because it almost always finds a
block large enough just below the active end of the heap.



Still, i cannot say i would be satisfied with such behavior. This
silently emulates end of line which is not there. You should AT LEAST
mention it in documentation,

Actually, I *do* mention it in the documentation. I've just not gotten
around to *posting* that documentation yet (that will come out with
HLA stdlib v2.1, which I'll get back to work on after I get around to
finishing HLA v1.90).


but i think this deserves more proper
solution than such workaround. Your readln routine should report EOF
(special exception?) instead of simulating EOL there.

I'm not sure I see the problem here. Unlike fileio, the stdin package
generally strips and ignores the end-of-line sequence. This is an
artifact of the buffering that stdin uses (versus the lack of
buffering in fileio). If a line does not contain an end-of-line
sequence, but butts right up against EOF, then the ReadLn function
will supply a phantom EOLN and the stdin functions will process that
last line properly. On the very next input operation, you *will* get
an EOF exception raised. The user's program never sees that phantom
newline; it exists solely for the correct operation of ReadLn.
Cheers,
Randy Hyde





.