Re^2: Minimizing PAR performance hit

Replies are listed 'Best First'.
Re^3: Minimizing PAR performance hit by fizbin (Chaplain) on Jan 08, 2007 at 16:32 UTC
Given that, it may also be worth posting a separate SOPW question about what you're doing that requires Math::Pari. There may be other ways to do it that would involve modules without nearly as much baggage. -- `@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/` [download]	[reply] [d/l]
Re^4: Minimizing PAR performance hit by gaal (Parson) on Jan 08, 2007 at 17:13 UTC
I use Net::SSH::Perl, which relies on Crypt::DSA, which in turn uses Math::Pari. This last isn't strictly required... so long as you don't mind 30-second-long login times to SSH servers. :-( Regardless, the RAM overhead of PAR seems to be about 8-9MB...	[reply]
Re^5: Minimizing PAR performance hit by fizbin (Chaplain) on Jan 08, 2007 at 18:48 UTC
Well, so long as you must use Net::SSH::Perl, yes, you're bound to PARI. I'll note though that from what hints you've provided about your execution environment, you aren't in a situation where you'd really be taking advantage of Net::SSH::Perl's main advantage, which is that you don't have to create an extra process in order to ssh - this is a boon in a long-running perl process that will ssh frequently, or on a system with a high per-process overhead (such as windows). You don't seem to be in such a situation. Could you also accomplish what you need to accomplish by using the ssh command-line client already there on the machine you're going to be running on and using Net::SSH, IPC::Open3, or possibly even Expect? (Note that Expect comes with its own shared-library baggage, but likely less than Pari's) -- `@/=map{[/./g]}qw/.h_nJ Xapou cets krht ele_ r_ra/; map{y/X_/\n /;print}map{pop@$_}@/for@/` [download]	[reply] [d/l]
Re^6: Minimizing PAR performance hit by gaal (Parson) on Jan 08, 2007 at 19:00 UTC
Re^3: Minimizing PAR performance hit by tsee (Curate) on Jan 08, 2007 at 12:35 UTC
Wow, 6MB is quite a shared object! By the way, what do you mean by "cannot be shared"? Can't be shared in the concept of shared memory? Does that work if the instances run in separate perl's? If so, I wonder why this doesn't happen if you run the same par'd binary twice because the cache area should be the same. Does it, perhaps, help to put Math::Pari into a separate .par and using that? Try fiddling with the $ENV{PAR_GLOBAL_TEMP} variable to force sharing of the cache directory. And please forgive me for hand-waving. :) On a related note: If you download the PAR-0.970.tar.gz distribution and look for the pare utility in the contrib/ subdirectory, you'll find a tool to remove all common modules from one executable and make it depend on the other. I'm not sure it works for the dependency on a .par. But perhaps pp -X foo.par works by skipping the stuff in foo.par during packaging! If you plan to deploy Math::Pari to the target system(s), you can use a .par as well - if you like. Here, I would advise a slightly different process: use PAR::Dist::FromCPAN's cpan2par tool to create a Math-Pari-VERSION-PLATFORM-PERLVERSION.par binary from Math::Pari Ship that to the clients Have them install that binary with `perl -MPAR::Dist -einstall_par` (assuming only one .par in the current directory. See PAR::Dist.) You can even embed PAR::Dist into a simple "install_par.pl" script since it's pure-perl without non-core dependencies. About your suggestion for the FAQ: Would you mind editing the wiki yourself? Just modify the existing answer or, if you like, create a new Q/A pair. Thanks! Steffen	[reply] [d/l]
Re^4: Minimizing PAR performance hit by gaal (Parson) on Jan 08, 2007 at 15:07 UTC
Yes, IIRC none of the running instances of my program had very large Shared parts in their memory usage. I won't be at this particular $client's till Wednesday but I'll double check then. (Thanks for the wiki tip; I will certainly update the FAQ there if my hypothesis is confirmed.) The system is CentOS, but that doesn't have RPMs for any of the PAR utils (including PAR::Dist). Since PAR is meant to help with the bootstrapping problem of weakling perl installs, it'd be awesome if all major distros got one -- I'll see if what I can do in a couple of days :-)	[reply]