On Wed, May 13, 2009 at 03:28:11AM +0200, Roland Mainz wrote: > Bob Friesenhahn wrote: > > On Tue, 12 May 2009, Roland Mainz wrote: > > > Can you check whether the memory allocator in libast performs better in > > > this case (e.g. compile with $ cc -I/usr/include/ast/ -last ... # (note: > > > libast uses a |_ast_|-prefix for all symbols and does (currently) not > > > act as |malloc()| interposer)). > > > > I assume that the 'libast' you are referring to different than > > libast-0.7 from http://www.eterm.org/download/, which is the one that > > OpenSolaris SFE points to. > > Right... I was thinking about /usr/lib/libast.so.1 + > /usr/lib/64/libast.so.1 shipped with Solaris 11 (which was added as part > of the ksh93-integration project (and now moves over to the POSIX > commands community)) ...
<...> > Uhm... yes... you could build it "manually" as described at > http://www.research.att.com/sw/download/ but that does not mangle the > symbol names as defined by PSARC/2006/550&co. ... > ... but there is a script we use to generate the includes for OS/Net > which does the task nearly 80% complete (still lacking all optimisations > done within OS/Net) - see > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype021/usr/src/lib/libshell/misc/buildksh93.sh > and > http://svn.genunix.org/repos/on/branches/ksh93/gisburn/prototype021/usr/src/lib/libshell/misc/buildksh93.readme > for a small description how to use it (for Solaris 10 you may need to > add "-lrt" to the link flags (and note that you shouldn't install > libcmd.so.1 generated by that build on a Solaris 10 machine)). This seems like a lot of work to put customers through. Have you, or anyone else on the ksh93 team, considered making the libast allocator available as a malloc interpositon library for libc? This, of course, would require that the library support malloc(), calloc(), free(), realloc(), valloc(), memalign() and alloca(), and be separable enough to interpose on libc without pulling in the rest of libast. However, if we're going to reccomend that customers try this approach for better performance, it's nice to have a supported allocator library available. -j _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
