On Wed, 2004-06-30 at 00:14, Ion Alexandru Morega wrote: > ... there are advantages in including > the source code: > - We could trim down all the functionality we don't use (if there is > any)
On modern architectures, I don't think that this will actually buy very much. Shared libraries are mmaped, so only the portions that you use are actually loaded into memory. And that memory is shared by all processes linking against GMP. In my estimation, merging GMP into the Parrot code base only makes sense if you can manage to cut out the vast majority of GMP code (70% or more?). At first glance, this doesn't look like an easy task... On the other hand, on an embedded architecture, saving even 20% would probably be a win. I'm sure this can be solved if it ever proves to be a problem. But, for now, why solve problems that haven't been shown to exist? > - At first glange, GMP seems to handle its own memory allocation. It > would be much better if we did that ourselves. Perhaps this would help...? http://www.swox.com/gmp/manual/Custom-Allocation.html#Custom%20Allocation If these hooks don't provide everything that Parrot needs, I expect the GMP developers would be receptive to a patch. > - GMP's compilation process is aware of the machine's hardware, > making optimisations accordingly. It should be compiled along with > parrot, for better performance. That's a double-edged sword. GMP's compilation process is complex and includes a large quantity of platform-specific code. Merging this into the Parrot tree and then trying to maintain it (and continually merge new changes) sounds like a headache. As for performance, given the amount of indirection the Parrot interpreter already incurs, I'm not sure that calling via shared library would add much. I ran some performance tests to try to answer this. You can find the test code in funcptrs-0.2.tar.gz on http://www.rinspin.com/bronson/code/gcc/ (I posted more detailed results to the gcc list -- they should hit the archives soon) I discovered that shared libraries are about 15% slower than statically-compiled code (30% worst case). And my test calls a trivial 8-instruction function. If the shared library function were to execute 800 instructions (still pretty small), the performance hit would be about 0.15%. So I doubt that statically linking GMP will offer much of a speedup. There's an easy way to prove my hypothesis, of course... > Therefore I suggest we talk to the authors or the FSF and ask them to > allow us to include the (modified!) source code. Before doing that, I think it would be prudent to first prove that there actually exists a problem, and further that the problem can be solved by merging GMP code into the parrot source tree... > ... LGPL is, after all, "lesser" in the sense that it has more > limited protection of the end-user's rights (as opposed to GPL). Parrot > on the other hand is distributed under GPL, which is better. :) It's also licensed under the Artistic, which is worse! :) - Scott
