On 7/22/20 3:55 PM, Bruno Haible wrote:
Of course this performance issue is mostly just for MS-Windows, as other major
current platforms already have aligned_alloc or rough equivalent.
No, it's not only Windows. It's
- macOS
- Minix
- native Windows
macOS has had posix_memalign sinc
On 7/22/20 4:04 PM, Bruno Haible wrote:
Probably most posix_memalign / memalign implementations will round up the
request to a 16-bytes allocation. But if some implementation can give me just
8 bytes, properly aligned, without wasting the next 8 bytes, why should I not
make use of it?
I suspec
On Wed, Jul 22, 2020 at 6:56 PM Bruno Haible wrote:
>
> Hi Paul,
>
> > Of course this performance issue is mostly just for MS-Windows, as other
> > major
> > current platforms already have aligned_alloc or rough equivalent.
>
> No, it's not only Windows. It's
> - macOS
> - Minix
> - native
Paul Eggert wrote:
> What uses of posix_memalign have a SIZE that is not a multiple of ALIGNMENT?
My current use-case is to generate machine code in memory (like a just-in-time
compiler). For x86, you can easily have a basic block of 7 bytes, which ought to
be aligned on a 16-bytes boundary.
Prob
Hi Paul,
> Of course this performance issue is mostly just for MS-Windows, as other
> major
> current platforms already have aligned_alloc or rough equivalent.
No, it's not only Windows. It's
- macOS
- Minix
- native Windows
Here's the complete matrix:
posix_memalig
On 7/21/20 9:21 AM, Bruno Haible wrote:
I prefer posix_memalign to aligned_alloc, because aligned_alloc requires
additionally that the SIZE is a multiple of the ALIGNMENT.
What uses of posix_memalign have a SIZE that is not a multiple of ALIGNMENT? I'm
asking partly because every time I've don
On 7/21/20 4:29 PM, Bruno Haible wrote:
However, the algorithm above would be _grossly_ inefficient - especially for
bigger alignments such as 128 or 512.
I don't think performance would be that bad, for many applications at least. I
suppose we could measure overall performance if the topic eve
On 7/22/20 12:13 AM, Florian Weimer wrote:
I don't think it will work. Try to get an allocation of 4096 bytes with
4096 bytes alignment using glibc malloc this way.
That's just a mental exercise since glibc malloc already has aligned_alloc, but
I took the challenge anyway and found that it's
On 7/21/20 2:43 PM, Jeffrey Walton wrote:
Eventually I hope even Microsoft will figure out how to do aligned allocation,
and even if my hope is dashed that's OK, our code will still work.
I believe Redmond has _aligned_malloc.
Unfortunately it requires that the storage be freed via _aligned_fr
Am Sa., 23. Mai 2020 um 19:19 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > > I was expecting that you write
> > >
> > > struct
> > > {
> > > void *base; ...
> > > }
> >
> > This removes type safety. The benefit of the current approach is that
> > stack types of differe
On Fri, Jul 17, 2020 at 4:16 PM Bruno Haible wrote:
>
> Hi Jeffrey,
>
> > I noticed my runpaths are re-ordered in libraries like
> > libgettextsrc.so, libtextstyle.so, libgettextpo.so, libgettextlib.so,
> > libgettextlib.so, libintl.so and libunistring.so. For example, I use
> > LDFLAGS of:
> >
>
* Paul Eggert:
> On 7/21/20 8:51 AM, Florian Weimer wrote:
>> The official aligned_alloc produces pointers compatible with free.
>> This module cannot do that.
>
> I don't see why not, at least on platforms of interest to Gnulib. On
> systems that provide no native way to do an aligned allocation,
12 matches
Mail list logo
