because I recon eliminating the exception handler is more important than speeding up the actual malloc/free.
Hmm...
alright, here's some quick benchmarks using 4.08.1: 1e6 * "bracket" = 0.20 secs 1e6 * "bracket+malloc/free" = 0.69 secs 1e6 * "malloc/free" = 0.40 secs 1e6 * "allocate ByteArray" = 0.13 secs Ok, so the malloc/free is the most expensive part. I'm moderately surprised :) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required. Cheers, Simon
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Ok, so the malloc/free is the most expensive part. I'm moderately surprised:) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
BTW, withCString in my implementation which handles charsets does not use alloca but malloc. It's because we don't know the length of the resulting char[] until we convert it, so we cannot preallocate it. We must guess an initial size and realloc the array as needed. Hence unfortunately speeding up alloca won't speed my implementation of the common need of allocating C objects. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
On 04-Dec-2000, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Ok, so the malloc/free is the most expensive part. I'm moderately surprised:) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
BTW, withCString in my implementation which handles charsets does not use alloca but malloc. It's because we don't know the length of the resulting char[] until we convert it, so we cannot preallocate it. We must guess an initial size and realloc the array as needed.
I don't know the details of withCString, so this might not be applicable, but an alternative that is likely to be more efficient is to use a static or alloca()'ed buffer for the initial try, and if it doesn't fit then switch to using malloc()/realloc(). At the end, you can check whether the final buffer pointer is equal to the original fixed-size static or alloca()'ed buffer, and only free it if it is not. Or you can keep a separate boolean flag. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson <fjh@cs.mu.oz.au> wrote,
On 04-Dec-2000, Marcin 'Qrczak' Kowalczyk <qrczak@knm.org.pl> wrote:
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Ok, so the malloc/free is the most expensive part. I'm moderately surprised:) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
BTW, withCString in my implementation which handles charsets does not use alloca but malloc. It's because we don't know the length of the resulting char[] until we convert it, so we cannot preallocate it. We must guess an initial size and realloc the array as needed.
I don't know the details of withCString, so this might not be applicable, but an alternative that is likely to be more efficient is to use a static or alloca()'ed buffer for the initial try, and if it doesn't fit then switch to using malloc()/realloc(). At the end, you can check whether the final buffer pointer is equal to the original fixed-size static or alloca()'ed buffer, and only free it if it is not. Or you can keep a separate boolean flag.
Would have to be alloca'ed; otherwise, Concurrent would kill us. Manuel
qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote,
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Ok, so the malloc/free is the most expensive part. I'm moderately surprised:) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
BTW, withCString in my implementation which handles charsets does not use alloca but malloc. It's because we don't know the length of the resulting char[] until we convert it, so we cannot preallocate it. We must guess an initial size and realloc the array as needed.
Hence unfortunately speeding up alloca won't speed my implementation of the common need of allocating C objects.
Hmm, Unicode support seems to interact quite badly with the FFI... Manuel
Hello! On Mon, Dec 04, 2000 at 06:15:45PM +0000, Marcin 'Qrczak' Kowalczyk wrote:
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <simonmar@microsoft.com> pisze:
Ok, so the malloc/free is the most expensive part. I'm moderately surprised:) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
BTW, withCString in my implementation which handles charsets does not use alloca but malloc. It's because we don't know the length of the resulting char[] until we convert it, so we cannot preallocate it. We must guess an initial size and realloc the array as needed.
Hence unfortunately speeding up alloca won't speed my implementation of the common need of allocating C objects.
That's sad. In fact, I think it would not be too difficult to have some extensable allocation mechanism like: alloca_begin :: (Addr -> IO a) -> IO a -- or what is the currently en vogue pointer type Run an action in the context of an extensible allocation. Restrict memory allocations to only "normal heap" ones (to allow more efficient implementation) until either the action ends or an explicit alloca_end is executed. alloca_extend :: Int -> IO () -- or another appropriate integer type Extend the currently open allocation by a specified number of bytes alloca_end :: IO () finalize the currently open allocation. After that, you may use nested alloca_begin's. Kind regards, Hannah.
Simon Marlow <simonmar@microsoft.com> wrote,
because I recon eliminating the exception handler is more important than speeding up the actual malloc/free.
Hmm...
alright, here's some quick benchmarks using 4.08.1:
1e6 * "bracket" = 0.20 secs 1e6 * "bracket+malloc/free" = 0.69 secs 1e6 * "malloc/free" = 0.40 secs 1e6 * "allocate ByteArray" = 0.13 secs
Ok, so the malloc/free is the most expensive part. I'm moderately surprised :) Perhaps we could do a better job, but we'll never do better than ByteArrays as long as the bracket is required.
You also mentioned in an earlier message that you see scope for improving on the exception handling. If that is the case, I would aim for getting rid of malloc/free and leave the exception handler in. This way, we have some benfit now and more when exception handling is speeded up. I am inclined to go this route also, because the exception handling is under our control, but alloc/free isn't. Cheers, Manuel
participants (5)
-
Fergus Henderson -
Hannah Schroeter -
Manuel M. T. Chakravarty -
qrczak＠knm.org.pl -
Simon Marlow