Dan Sugalski wrote:
At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
Background: Pmc2c.pm emits code which references Parrot_PMC_typenum. This code is present in libparrot.so, which currently is not referenced as a library by the link step for dynclasses.
Options include:
1) eliminating this dependency, as it is the only one 2) directly including extend.o into each shared library 3) linking to libparrot.so
#3's the right thing here. PMC classes have access to enough of the internals that linking to libparrot's fine. If we're feeling paranoid we can define a PMC API and link against a shared library that exposes it, but that's a bit much for now.
I ran into both technical and performance issues, both of which are worth discussing. First the technical difficulties:
By adding "-L../blib/lib -lparrot" to the link step, I was able to produce a shared library. However, getting it to successfully load was a challenge. The problem is that library.c is hardcoded to look for dynamic libraries in runtime/parrot/dynext/, effectively requring parrot to be invoked from the parrot directory if any shared libraries are going to be loaded. That needs to be fixed, IMHO, but that is beside the point.
With option (3) above, the loading of python_group requires libparrot.so to be loaded. Unfortunately, nothing tells the OS that this library can be found in blib/lib, so it fails. There are a number of ways to address this, one of the simplest is to modify library.c to add a "" to dynext_paths, effectively enabling LD_LIBRARY_PATH to be used. This may not be the right long term solution, but it did enable me to get past this problem, and does provide a workaround to the issue of returing parrot to be run from a particular directory.
- - -
I have a simple unit test[1], one that was not intended to be a benchmark. Each run passed, and here are the results (in seconds, methodology = best of three runs):
3.437 Dynclass w/ dependency on libparrot.so 2.912 Dynclass w/o dependency on libparrot.so 1.221 enum class
Note: in the last run, the loadlib ops were removed, but the find_type ops remained in place. An additional run was made with the find_type ops removed, but the difference was not measurable.
On the plus side, the overhead is presumably all startup costs. However, the fact that the overhead is noticeable at all, let alone this significant, in a series of tests involving the compiling from source of a program is distressing.
One other thing to note, "make shared" does not reduce the size of the parrot executable. If the long term plan is to change the perl classes to be dynclasses, then the presumtion should be that everybody is running shared, and the parrot executable should contain only what is not in libparrot.so.
- Sam Ruby
