On Tuesday, 3 January 2012 at 18:53:46 -0200, Carlos Eduardo G. Carvalho (Cartola) wrote: > 2012/1/3 Monkey <[email protected]> > >> -O3 causes a segfault on Linux in the same place - I wonder if it has >> something do with optimising out some instructions which don't appear >> to be used. In the mask section I make use of int* and float* pointing >> to the same address, and it seemed to be around this point that >> multiblend was failing. -O2, though, seems okay on Linux. >> >> By defining __APPLE__, this will make multiblend use malloc instead of >> memalign (_aligned_malloc on Windows). This is done for the SSE parts >> - is there any chance this could cause problems/slowdown on FreeBSD, >> or does it allows malloc to a 16-byte boundary like OSX? > > I have no idea :) I have heard that Mac OS X came from FreeBSD, so they > might be similar in some points, but this is a too generic information. > Maybe Greg or Yuv could know...
FreeBSD malloc() has been through many iterations and implementations. My guess is that the current version (phkmalloc) is vastly superior to Apple malloc(). From the man page, the minimum allocation is 8 or 16 bytes, dependent on the architecture, and aligned on the same size boundary. In the case of FreeBSD amd64, it would be 16 bytes. Any allocation greater than this is aligned on a cache line boundary, normally 64 bytes. Allocations above this size are aligned on at least 256 byte boundaries. I haven't looked at the multiblend code (though I'm planning to), but I assume that the allocations in question arer significantly more than 16 bytes, and thus that this means that there's no problem using malloc(). If there is, there's always the old trick of allocating 16 more bytes and aligning manually. Greg -- Sent from my desktop computer Finger [email protected] for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua
pgp5oDaXM1t5H.pgp
Description: PGP signature
