Andy Polyakov wrote:
>
> > BTW, although malloc() returns a pointer "suitable aligned", that
> > doesn't mean it is fast. The comment refers to the fact that some CPUs
> > don't like fetching a long (say) except off a 4-byte boundary.
> "Some CPUs"? It should say "all, but Intel", shouldn't it? And secondly
> define "like." Even latest Intel CPUs like data being aligned on natural
> boundaries. And when it comes to floating point data one should probably
> say "love" instead of "like" as performance penalties of 25%-30% are
> most common.
I meant that on some CPUs it is an _error_ to fetch unaligned data.
> > In fact
> > an x86 will fetch them on any alignment, so malloc() is not obliged to
> > align at all,
> I can't tell for all x86 OSes (especially Windows:-), but both Linux and
> Solaris malloc()s do return 64 bit aligned pointers. They aren't
> obliged, but they do.
> > whereas for performance on an x86 you want to align on a
> > paragraph boundary (16 bytes?).
> ??? Do you mean 80 bits floating point variables and SIMD (or whatever
> they call it) extensions? Because otherwise just natural alignment (i.e.
> short at 2 bytes, long at 4, double at 8, etc.) are as good as 16.
I mean that the x86 cache is divided into 16-byte chunks and they are
loaded using RAM burst mode starting at the beginning of the paragraph,
so access that is aligned on paragraph beginnings is very much faster. I
discovered this many years ago when doing cunning optimisations for the
486 (when it first came out).
Hmm... just checked my manual and the right term for this is "cache line
fill", in the Intel world, at least. I've also checked the size, and it
is 16 bytes.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
