[Mesa-dev] Improving ralloc performance for the GLSL compiler

[Emil Velikov]

On 31 August 2016 at 14:37, Marek Olšák <maraeo at gmail.com> wrote:
> On Wed, Aug 31, 2016 at 3:02 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 31 August 2016 at 13:40, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Aug 31, 2016 5:02 AM, "Michel Dänzer" <michel at daenzer.net> wrote:
>>>>
>>>> On 30/08/16 06:51 PM, Marek Olšák wrote:
>>>> >
>>>> > If we don't care about memory usage, let's use my allocator. If we do,
>>>> > let's import jemalloc into the Mesa tree and use it for ralloc.
>>>>
>>>> Instead of importing jemalloc into Mesa, could we use the shared
>>>> libjemalloc.so.1?
>>>
>>> No idea. It exports malloc/free/etc, but "nm" says "there are no
>>> symbols". Perhaps they can only be dlsym'd.
>>>
>> If we opt for jemalloc I'm in favour of using the shared one.
>>
>> Re: symbols visibility - dlsym and (should) nm do the same thing. Here
>> is how I check things:
>>
>> $ nm -CD --defined-only /usr/lib/libjemalloc.so
>> 0000000000008470 T aligned_alloc
>> 00000000002402a1 B __bss_start
>> 00000000000084e0 T calloc
>> ...
>
> OK. I'm afraid malloc/calloc/realloc/free from libjemalloc.so will
> conflict with libc and Steam.
>
> When building jemalloc from source, there is an option to add a function prefix.
>
> There are basically two options at the moment:
> - my allocator: is faster, has much higher memory usage, but is simple
> to integrate.
> - jemalloc: should have reasonable memory usage, but it's not clear
> yet how to integrate it with Mesa.
>
Silly me should have said "If we opt for jemalloc I'm in favour of
reusing the system one - be that static or shared. Please consider
importing jemalloc sources into mesa as a 'last' resort".
On the steam front... I haven't really tested it but it should* be
fine, since the glibc symbols are weak explcitly for the purpose or
using custom allocator.

Above opting for either would be great to check with the example
cases/programs that others have mentioned.

Thanks
Emil