Building PerlMagick, I noticed -MTUNE=core2. What a waste!
I fixed it by setting the CFLAGS to -MTUNE=native. OR did I?
Due to CFLAG clobbering, you need to use --with-gcc-arch=native.
The normal Perl (with libperl.a) won't link in PerlMagick.
You have to build it with a shared libperl.so. I have read
that there is roughly a 10%-30% performance penalty for
shared Perl vs static. There is a 4-year-old thread here
about "Building Perl with static and dynamic perllib libs"
but there is no building advice.
How many of today's building/sharing/linking conventions are
hangovers from dos days when a meg of memory was a lot? Is
performing the runtime fire drill of assembling myriad program
fragments, hoping they still fit, so you can have the illusion
of tiny executables an anachronistic sub-optimization?
There are the zillion configure options; threading, which type,
multiplicity, malloc perl/wrap, CFLAGS, CPPFLAGS, "-Ofast
-ffast-math -m64 -march=native -msse4.2 -mavx2 -funroll-loops
-fopenmp -flto", dyno-flags, alignment, dtrace, perlIO, VFork??
GCC vs Intel?
The PerlMagick README has spells to:
o -- create and install the dymamically-loaded version of PerlMagick
o -- replacing your PERL interpreter with PerlMagick statically linked
o -- install a new PERL interpreter with a different name
Can any project with hard-coded, Core2 code optimization place much
value on SPEED?
I would like to have 1 Perl which does it all rather than multiple
versions and it would be desirable to use as many of the slick
features of my new processor as possible. Trying with/without each
of the ~dozen independent variables above and profiling all 4096
possible Perls is beyond affordable.
What is the current Wisdom regarding Building an Efficient
Perl/PerlMagick for a modern system?
In reply to Wisdom for building an Efficient Perl/PerlMagick? by BrianP
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |