🚀 go-pugleaf

On Thu, 4 Jan 1996 19:26:16 GMT in article <DKo8ns.8A9@midway.uchicago.edu>
    Michael Spertus<mps@geodesic.com> (Michael Spertus<mps@geodesic.com>) wrote:

> ... The problem is that Win32 GlobalAlloc(), which is
>what most allocators use to get their arenas, returns a 32-bit aligned
>pointer. ...  They may also be unaware
>that Pentium PCs use 64 bits data buses). This problem is magnified
>because the Pentium (apparently) drops into microcode on nonaligned
>loads, so that nonaligned floating point benchmarks are over 300%
>slower.

>Therefore, any code using floats must align all floating point malloc()
>to avoid running with abysmal efficiency on many of the most popular
>C/C++ compilers. I would like to believe that there should be an
>expectation that "malloc(float)" is a suitable or proper way to
>portably allocate a float ("suitable" and "proper" are the words used
>in the standard and reference documents to describe how malloc() should
>be aligned).
...

The problem here is, of course, that your idea of what is "suitable" and
"proper" is different from other people's.  A large program I am developing does
many malloc()'s, almost all of which are for character-oriented or
short-oriented data.  I do not want to pay the overhead for 64-bit alignment
that would just waste space.  (My program needs all the memory it can get its
hands on.)  So what's the vendor to do?  Compiler options can fix some things,
but it gets trickier at run time.  There are solutions, but the right answer is
a lot more complex than you are suggesting, I think.

--
Peter Curran                               pcurran@inforamp.net