Am 19.11.2014 12:32, schrieb Karoly Balogh (Charlie/SGR):
Hi,
On Wed, 19 Nov 2014, Jonas Maebe wrote:
Since the RTL's allocator is documented to align to 16 bytes
Where?
Ok, that's actually a very good question. :) I didn't find it anywhere,
except some earlier ML/forum posts revealed
Karoly Balogh (Charlie/SGR) wrote:
Hi,
I think there are several issues with the cmem memory allocator. The main
issue that it breaks the underlying malloc() memory alignment, by adding
a four/eight byte size value to the start of each block for the sole
reason to be able to throw Runtime Error
Hi,
On Wed, 19 Nov 2014, Mark Morgan Lloyd wrote:
At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
to 4 bytes and 8 bytes, respectively.
Since cmem is intended for use by FPC, I don't see
On 19 Nov 2014, at 11:49, Karoly Balogh (Charlie/SGR) wrote:
Since the RTL's allocator is documented to align to 16 bytes
Where? At least http://www.freepascal.org/docs-html/prog/
progsu173.html only says that the size is rounded up to a multiple of
16/32 bytes; it doesn't say anything
In our previous episode, Karoly Balogh (Charlie/SGR) said:
At least on Linux, malloc() is documented to align to 64 bit on 32 bit and
128 bit on 64 bit platforms, while this way cmem's GetMem() reduces that
to 4 bytes and 8 bytes, respectively.
Since cmem is intended for use by FPC, I
Hi,
On Wed, 19 Nov 2014, Jonas Maebe wrote:
Since the RTL's allocator is documented to align to 16 bytes
Where?
Ok, that's actually a very good question. :) I didn't find it anywhere,
except some earlier ML/forum posts revealed by Google.
However, in practice it still seems to align to 16
Hi,
On Wed, 19 Nov 2014, Marco van de Voort wrote:
Since the RTL's allocator is documented to align to 16 bytes, it's
definitely an issue also with Pascal code. We do have code where also
Pascal side triggers the aligment issue, but indeed, the main issue is
with linked C libs, depending
Karoly Balogh (Charlie/SGR) wrote:
Perhaps the most serious scenario is where an architecture or particular
implementation requires alignment, but the kernel traps alignment errors and
fixes them silently. SPARC Solaris does this and my understanding is that it
introduces a very significant
In our previous episode, Karoly Balogh (Charlie/SGR) said:
Since the RTL's allocator is documented to align to 16 bytes, it's
definitely an issue also with Pascal code. We do have code where also
Pascal side triggers the aligment issue, but indeed, the main issue is
with linked C
In our previous episode, Mark Morgan Lloyd said:
introduces a very significant performance overhead;
Linux also does this.
On some but by no means all platforms. I'm specifically trying to
highlight the fact that on SPARC, Solaris can fix alignment issues (at a
price) but Linux
Marco van de Voort wrote:
Since cmem is documented to be used from the main program file (iow the
users code), that would nicely put the responsibility there.
That might be where it's imported, but it's heavily used by just about
everything when non-scalar types are being shared between a
19.11.2014 15:16, Marco van de Voort пишет:
In our previous episode, Mark Morgan Lloyd said:
introduces a very significant performance overhead;
Linux also does this.
On some but by no means all platforms. I'm specifically trying to
highlight the fact that on SPARC, Solaris can fix
Sergei Gorelkin wrote:
19.11.2014 15:16, Marco van de Voort ?: In our previous episode,
Mark Morgan Lloyd said: introduces a very significant performance
overhead; Linux also does this. On some but by no means all
platforms. I'm specifically trying to highlight the fact that on
SPARC,
Hi,
I think there are several issues with the cmem memory allocator. The main
issue that it breaks the underlying malloc() memory alignment, by adding
a four/eight byte size value to the start of each block for the sole
reason to be able to throw Runtime Error 204 in case someone tries to free
a
14 matches
Mail list logo
