help-glpk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-glpk] Makefiles for 64 bit Windows - 16 byte alignment


From: Andrew Makhorin
Subject: Re: [Help-glpk] Makefiles for 64 bit Windows - 16 byte alignment
Date: Fri, 29 Aug 2008 14:13:28 +0400

Hi Xypron,

> in the Microsoft SDK for Windows 2003 setjmp.h contains the following
> lines:

> /*
>  * AMD64 setjmp definitions.
>  */

> typedef struct __declspec(align(16)) _SETJMP_FLOAT128 {
>     unsigned __int64 Part[2];
> } SETJMP_FLOAT128;
> typedef SETJMP_FLOAT128 _JBTYPE;
> typedef _JBTYPE jmp_buf[_JBLEN];

> glpmpl.h uses structure jmp_buf in the definition of struct MPL.

> glpmpl4.c contains the following line:
>       mpl = xmalloc(sizeof(MPL));

> The implementation of xmalloc is in glplib07.c. Xmalloc prepends
> align_datasize(sizeof(LIBMEM)) bytes to the structure MPL.

> If align_boundary != 16 the alignment of jmp_buf is destroyed.

Thank you very much for your investigation.

You are right. In fact, I forgot about jmp_buf, and probably it is the
only thing in glpk code which needs 16-byte alignment.

The reason I needed to understand that is following. It is normal to
use 16-byte boundary for blocks allocated with xmalloc and xcalloc.
However many glpk routines use another technique based on memory pools
to allocate short memory blocks used as elements of various linked
lists, in which case 16-byte alignment may lead to high memory expenses
(about 30%-50%) and therefore is undesirable. Now I think that it is
possible to use two alignment boundaries in both 32- and 64-bit
environments: 16 bytes for xmalloc, and 8 bytes for blocks stored in
memory pools.


Andrew Makhorin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]